Dmd sc.ini and VS do not work well together!

[Brad Anderson via Digitalmars-d]

On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote:
> I feel like I am in the cave man times.  I installed Dmd2 from 
> scratch. VisualD x64 project would not compile due to 
> libucrt.lib not being found.

Sorry you are having trouble. The Universal CRT and Visual Studio 
2015 are very new and I'm sure there are still some bugs to work 
out.

> Using Process Monitor, it seems that dmd is looking all over 
> the place for libucrt.lib but can't find it. Check out sci.ini 
> has some weird results.
>
> I have installed some windows kits and sdk's for win 8.1 and 
> win 10 but I do not remember all the details.
>
> What I do know is that I have about 20 libucrt's in on my 
> harddrive(global search).
>
>
> 1. The archaic sc.ini file gets things backwards. It uses 
> VCINSTALLDIR before it is defined!
>

Well spotted but this case you are missing some details. 
VCINSTALLDIR is used at that point so dmd linking will still work 
for people who install using the zip file but run DMD through 
Visual Studio Command Prompts (which define VCINSTALLDIR). You'll 
notice LINKCMD is than replaced with a different value further 
along by the installer. The comments could be better to explain 
why it is this way.

It actually shouldn't matter if it's defined later though. My 
understanding is the environment variables aren't expanded as the 
config file is read. They all get read and set verbatim as 
environment variables. Windows expands them once they are used 
meaning VCINSTALLDIR would be set.

> [snip]
>
>
> Um, So, first off VCINSTALLDIR is used before defined!! Pretty 
> basic bug here, should never have happened. Second, UCRTVersion 
> is just wrong. I have no winv6.3 subdir. Windows 10 and VS2015 
> use some folder names like
>
> C:\PF\Windows\Kits\10\Lib\10.0.10150.0
> and
> C:\PF\Windows\Kits\10\Lib\10.0.10240.0

We are using:

HKLM "Software\Microsoft\Windows Kits\Installed Roots" 
"KitsRoot10"

Then searching for the latest UCRT version in a subdirectory. 
That's probably where the bug is. This is brand new detection 
however so it might be buggy.

You can see how it works here: 
https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379

Would you happen to know a better way to do this?

> [snip]
>
> The installer should be modernized and provide path information 
> and resolve dependencies properly before installing. It is 
> clear that dmd was not designed for windows use.

We make updates to it pretty much every release cycle. We'd love 
some help making it bulletproof. Rock solid VS/Platform SDK 
detection is what we want but it's proved a bit trickier than 
expected (Microsoft has changed a few things up with different VS 
releases so there is not just one way to do it).