May 22
On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:
[snip]
>
> You should not add these library paths, these are automatic fallback for dmd if it doesn't find a VS installation.
>
OK, original state of sc.ini restored.

> Instead you should install any Windows SDK (e.g. the one that comes with the VS installer). I've recently updated the installation documentation to that respect.
>

I do in fact have multiple Windows SDKs installed - probably from earlier versions of VS + SDKs I had installed. Under 'c:\Program Files (x86)\Windows Kits\' I still have folders for:
- 8.0
- 8.1
- 10
- NETFXSDK

The VS uninstall feature does not uninstall the SDKs, so I still have a number of previous SDK versions.

If I revert the original state of sc.ini I still have the issue that it cannot find 'user32.lib' and fails with a linking error.

As mentioned in my previous post there are 'user32.lib' versions under 'c:\D\dmd2\windows\lib64\mingw\' and  'c:\D\dmd2\windows\lib32mscoff\mingw\', but ok, as you indicated, these are for VS2010 and I should link to the versions under my Windows SDK if I have a later version of VS installed.

My *current* set of Library search paths (Tools -> Options -> VisualD Settings -> DMD -> x64) shows:
$(VCINSTALLDIR)lib\amd64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
$(DMDInstallDir)windows\bin

There is no 'user32.lib' present under $(VCINSTALLDIR)lib\amd64 and the
"$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64" resolve to...
$(UniversalCRTSdkDir) = C:\Program Files (x86)\Windows Kits\10\
$(UCRTVersion)= 10.0.10240.0
 .... eg. the latest Windows SDK installed (v10).

There is no 'user32.lib' present here either (c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64\).

OTOH, there is a 'user32.lib' present in c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ i.e. under Windows SDK 8.1. If I add this path to the Library search paths the app now successfully links - and my very trivial test program runs fine.

Interestingly, I found I only have 'user32.lib' present in Windows SDK 8.1, but in neither of 8.0 or 10.0.

The exact same story also applies to x32 COFF libs. At this point I can easily add the SDK 8.1 to the Library search seach paths for x64 and x32COFF, but is it a good idea to mix SDK 10 and 8.1 like this? The search order will link to libs from 10 if they are present in SDK 10, and only use libs from SDK 8.1 if they are not present in SDK 10.

I am rather going to change my Lib search paths to only use the SDK 8.1, but are these known restrictions with SDK 8.0. and 10.0? Or is there something wrong with my SDK 10 installation? (I have 2 versions of SDK 10, and both show very few libs compared to 8.1)

May 22
On Friday, 17 May 2019 at 01:00:38 UTC, Alex wrote:
> On Thursday, 16 May 2019 at 21:06:02 UTC, ShadoLight wrote:
[snip]
> You can use something like process monitor to figure out what files it is looking for. Usually this is a path issue. I had it once.
>
Yep, it seems to be a path issue... and an issue with my y Windows SDK version.

May 22
On Wednesday, 22 May 2019 at 08:42:21 UTC, ShadoLight wrote:
> On Thursday, 16 May 2019 at 06:31:10 UTC, Rainer Schuetze wrote:
> [snip]
>>
>> You should not add these library paths, these are automatic fallback for dmd if it doesn't find a VS installation.
>>
> OK, original state of sc.ini restored.
>
>> Instead you should install any Windows SDK (e.g. the one that comes with the VS installer). I've recently updated the installation documentation to that respect.
>>
>
> I do in fact have multiple Windows SDKs installed - probably from earlier versions of VS + SDKs I had installed. Under 'c:\Program Files (x86)\Windows Kits\' I still have folders for:
> - 8.0
> - 8.1
> - 10
> - NETFXSDK
>
> The VS uninstall feature does not uninstall the SDKs, so I still have a number of previous SDK versions.
>
> If I revert the original state of sc.ini I still have the issue that it cannot find 'user32.lib' and fails with a linking error.
>
> As mentioned in my previous post there are 'user32.lib' versions under 'c:\D\dmd2\windows\lib64\mingw\' and  'c:\D\dmd2\windows\lib32mscoff\mingw\', but ok, as you indicated, these are for VS2010 and I should link to the versions under my Windows SDK if I have a later version of VS installed.
>
> My *current* set of Library search paths (Tools -> Options -> VisualD Settings -> DMD -> x64) shows:
> $(VCINSTALLDIR)lib\amd64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
> $(DMDInstallDir)windows\bin
>
> There is no 'user32.lib' present under $(VCINSTALLDIR)lib\amd64 and the
> "$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64" resolve to...
> $(UniversalCRTSdkDir) = C:\Program Files (x86)\Windows Kits\10\
> $(UCRTVersion)= 10.0.10240.0
>  .... eg. the latest Windows SDK installed (v10).
>
> There is no 'user32.lib' present here either (c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64\).
>
> OTOH, there is a 'user32.lib' present in c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\ i.e. under Windows SDK 8.1. If I add this path to the Library search paths the app now successfully links - and my very trivial test program runs fine.
>
> Interestingly, I found I only have 'user32.lib' present in Windows SDK 8.1, but in neither of 8.0 or 10.0.
>
> The exact same story also applies to x32 COFF libs. At this point I can easily add the SDK 8.1 to the Library search seach paths for x64 and x32COFF, but is it a good idea to mix SDK 10 and 8.1 like this? The search order will link to libs from 10 if they are present in SDK 10, and only use libs from SDK 8.1 if they are not present in SDK 10.
>
> I am rather going to change my Lib search paths to only use the SDK 8.1, but are these known restrictions with SDK 8.0. and 10.0? Or is there something wrong with my SDK 10 installation? (I have 2 versions of SDK 10, and both show very few libs compared to 8.1)

Wow... have now found I cannot fix this linking issue by sticking just with libs from SDK 8.1.

If I remove the search path to libs from SDK 10.0, a basic D app now fails to link because of a missing 'libucrtd.lib', which I can only find under SDK 10. And likewise can only find 'user32.lib' under SDK 8.1.

This is becoming really strange now... do I really need 2 versions of the Windows SDK to be able to build using VisualD under VS 2015? Or are one (or both) of my SDKs broken?

To make linking succeed my lib search paths for x64 now looks like this:

$(VCINSTALLDIR)lib\amd64
"c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64"  <-SDK 8.1 path hard-coded
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64  <-'Default' SDK; v10.0 in this case
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
$(DMDInstallDir)windows\bin

I also don't understand (even thought this is not an issue for me at the moment since I am not targeting ARM), how the 'default' global search paths here for both ARM and x32/x64 can co-exist...
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
$(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64

... the above search order will always cause an ARM target to find the corresponding x32/x64 lib first - and try to link to that (since the basic ARM/x32/x86 lib names (like user32.lib) are all identical). Or are there some trick to this that I am missing?

In fact, why even have ARM lib search paths under the DMD compiler settings? AFAIK you cannot target ARM anyway with DMD, no? ARM paths may be valid paths for LDC or GDC, but VisualD has separate forms for those paths - I am just referring to the  DMD case here.

I know you can specify the lib search paths at a local project level too, but these DMD 'global' search paths (with the exception of the SDK 8.1 one I added) were created by the VisualD installer, so this was actually my 'default' installation.

I would like to seamlessly switch from building with dub to debugging with VS+VisualD (after generating VisualD project using dub) if required - this should actually be pretty much the standard work-flow for users of VS+VisualD and allows to leverage the strength of both. But I have also found some issues on the dub side as well with generating VisualD projects. I'll have a stab at fixing them but I want to use VS+VisualD to debug dub for this so, even though I can successfully compile+link at the moment in VS+VisualD, I'm suspicious of having to link against libs from 2 SDKs...?
May 22

On 22/05/2019 10:42, ShadoLight wrote:
> My *current* set of Library search paths (Tools -> Options -> VisualD
> Settings -> DMD -> x64) shows:
> $(VCINSTALLDIR)lib\amd64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
> $(DMDInstallDir)windows\bin

This looks pretty broken, you should not try to link ARM libraries.

The VS2015 default for x64 is:

$(VCINSTALLDIR)lib\amd64
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64

and for Win32-COFF:

$(VCINSTALLDIR)lib
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86

Starting with VS2015, the VC runtime requires the universal runtime (UCRT).

You can see the resulting paths in the build logs in the output directory. The are passed to the linker with the /LIBPATH option.
May 22
On 22/05/2019 19:32, Rainer Schuetze wrote:
> 
> The VS2015 default for x64 is:
> 
> $(VCINSTALLDIR)lib\amd64
> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64

Argh, sorry, this is what you get without any Windows SDK installed. If the Win10 SDK is detected, this gets added, too:

$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64

> 
> and for Win32-COFF:
> 
> $(VCINSTALLDIR)lib
> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86

$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86

> 
> Starting with VS2015, the VC runtime requires the universal runtime (UCRT).
> 
> You can see the resulting paths in the build logs in the output directory. The are passed to the linker with the /LIBPATH option.
> 
May 23

On 22/05/2019 18:35, ShadoLight wrote:
> Wow... have now found I cannot fix this linking issue by sticking just with libs from SDK 8.1.
> 
> If I remove the search path to libs from SDK 10.0, a basic D app now fails to link because of a missing 'libucrtd.lib', which I can only find under SDK 10. And likewise can only find 'user32.lib' under SDK 8.1.
> 
> This is becoming really strange now... do I really need 2 versions of the Windows SDK to be able to build using VisualD under VS 2015? Or are one (or both) of my SDKs broken?
> 
> To make linking succeed my lib search paths for x64 now looks like this:
> 
> $(VCINSTALLDIR)lib\amd64
> "c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64"  <-SDK 8.1
> path hard-coded
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64  <-'Default' SDK; v10.0
> in this case
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64
> $(DMDInstallDir)windows\bin

I suspect that you have the UCRT libraries in the Win10 folder (where they usually are), but no Win10 SDK installed. It can also happen that both exist, but with different versions.

So your patch to add the Win8.1 SDK looks good. Visual D should also set it to "$(WindowsSdkDir)Lib\winv6.3\um\x64" as the default at first start (but doesn't change the values once they have been edited).


> I also don't understand (even thought this is not an issue for me at the
> moment since I am not targeting ARM), how the 'default' global search
> paths here for both ARM and x32/x64 can co-exist...
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
> $(UniversalCRTSdkDir)Lib\$(UCRTVersion)\ucrt\arm64

Yes, the arm library should be removed, aswell as the dmd bin directory.
November 29
On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze wrote:
> On 22/05/2019 19:32, Rainer Schuetze wrote:
>> 
>> The VS2015 default for x64 is:
>> 
>> $(VCINSTALLDIR)lib\amd64
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>
> Argh, sorry, this is what you get without any Windows SDK installed. If the Win10 SDK is detected, this gets added, too:
>
> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>
>> 
>> and for Win32-COFF:
>> 
>> $(VCINSTALLDIR)lib
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>
> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>
>> 
>> Starting with VS2015, the VC runtime requires the universal runtime (UCRT).
>> 
>> You can see the resulting paths in the build logs in the output directory. The are passed to the linker with the /LIBPATH option.

Many moons later... on a new clean Win7 x64 laptop with VS2015 Pro I had a chance to start from scratch and see what happens with the above SDK scenario:

After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), I got the following VD Library Paths:
Win32:
(empty)
x64:
$(VCINSTALLDIR)lib\amd64
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
Win32-COFF:
$(VCINSTALLDIR)lib
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86

I did not get the following 2 paths (you mentioned above) added:
x64:
$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
Win32-COFF:
$(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86

So neither the paths for the Win10 SDK nor Wn8.1 SDK were added.

Creating a Win32 app in VS then fails with "LNK1181: cannot open input file 'user32.lib'".

Adding the above 2 paths for Win10 SDK does not solve the above Link error - it still cannot link to 'user32.lib'. From the calc2.buildlog.html I can see:

/LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib;
	C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86;
	C:\Program Files (x86)\Windows Kits\10\lib\\um\x86

This gives the following values:
$(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
$(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
$(UCRTVersion): 10.0.10240.0
$(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
$(WindowsSdkVersion):

This seems to indicate VD thinks Win10 SDK is installed. However, even though there is a "c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\" folder, there is no Lib folder in it neither any *.lib files.

Searching for 'user32.lib' in C:\Program Files (x86) I get:
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\User32.Lib
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\User32.Lib
c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\User32.Lib

Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with a hardcoded "c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking issue - app is build and runs successfully.

But this indicates to me that the required SDK on my machine is actually Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program Files (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should be "winv6.3".

I cross-checked in VC++ whether these enviro variables are defined and what their values are in VC++ and get:
$(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
$(WindowsSdkVersion): Not defined at all.

So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. I'm actually surprised by this... surely  $(WindowsSdkDir) should be the same for both...?

IS it possible to set/change these enviro variables for VD to their proper values?


November 30

On 30/11/2019 00:59, ShadoLight wrote:
> On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze wrote:
>> On 22/05/2019 19:32, Rainer Schuetze wrote:
>>>
>>> The VS2015 default for x64 is:
>>>
>>> $(VCINSTALLDIR)lib\amd64
>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>>
>> Argh, sorry, this is what you get without any Windows SDK installed. If the Win10 SDK is detected, this gets added, too:
>>
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>>
>>>
>>> and for Win32-COFF:
>>>
>>> $(VCINSTALLDIR)lib
>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>>
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>>
>>>
>>> Starting with VS2015, the VC runtime requires the universal runtime
>>> (UCRT).
>>>
>>> You can see the resulting paths in the build logs in the output directory. The are passed to the linker with the /LIBPATH option.
> 
> Many moons later... on a new clean Win7 x64 laptop with VS2015 Pro I had a chance to start from scratch and see what happens with the above SDK scenario:
> 
> After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), I got the
> following VD Library Paths:
> Win32:
> (empty)
> x64:
> $(VCINSTALLDIR)lib\amd64
> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
> Win32-COFF:
> $(VCINSTALLDIR)lib
> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
> 
> I did not get the following 2 paths (you mentioned above) added:
> x64:
> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
> Win32-COFF:
> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
> 
> So neither the paths for the Win10 SDK nor Wn8.1 SDK were added.
> 
> Creating a Win32 app in VS then fails with "LNK1181: cannot open input file 'user32.lib'".
> 
> Adding the above 2 paths for Win10 SDK does not solve the above Link error - it still cannot link to 'user32.lib'. From the calc2.buildlog.html I can see:
> 
> /LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib;
>     C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86;
>     C:\Program Files (x86)\Windows Kits\10\lib\\um\x86
> 
> This gives the following values:
> $(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
> $(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
> $(UCRTVersion): 10.0.10240.0
> $(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
> $(WindowsSdkVersion):
> 
> This seems to indicate VD thinks Win10 SDK is installed. However, even though there is a "c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\" folder, there is no Lib folder in it neither any *.lib files.
> 
> Searching for 'user32.lib' in C:\Program Files (x86) I get:
> c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\User32.Lib
> c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\User32.Lib
> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\User32.Lib
> 
> Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with a
> hardcoded "c:\Program Files (x86)\Windows
> Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking issue - app
> is build and runs successfully.
> 
> But this indicates to me that the required SDK on my machine is actually
> Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program Files
> (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should be "winv6.3".
> 
> I cross-checked in VC++ whether these enviro variables are defined and
> what their values are in VC++ and get:
> $(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
> $(WindowsSdkVersion): Not defined at all.
> 
> So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. I'm actually surprised by this... surely  $(WindowsSdkDir) should be the same for both...?
> 
> IS it possible to set/change these enviro variables for VD to their proper values?
> 
> 

As the Windows SDK environment variable is usually not set in the system environment, Visual D mimicks vcvarsall.bat from the VC installation to determine it and uses the first hit:

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder

- read registry entry SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder

- environment variable WindowsSdkDir

Could you please check where it gets the "C:\Program Files (x86)\Windows
Kits\10" folder from?

Usually, the library search path are set once, and they are not altered automatically later. You can reevaluate the default settings with the "Reset Settings..." button.
December 01
On Saturday, 30 November 2019 at 08:53:32 UTC, Rainer Schuetze wrote:
>
>
> On 30/11/2019 00:59, ShadoLight wrote:
>> On Wednesday, 22 May 2019 at 20:12:49 UTC, Rainer Schuetze wrote:
>>> On 22/05/2019 19:32, Rainer Schuetze wrote:
>>>>
>>>> The VS2015 default for x64 is:
>>>>
>>>> $(VCINSTALLDIR)lib\amd64
>>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>>>
>>> Argh, sorry, this is what you get without any Windows SDK installed. If the Win10 SDK is detected, this gets added, too:
>>>
>>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>>>
>>>>
>>>> and for Win32-COFF:
>>>>
>>>> $(VCINSTALLDIR)lib
>>>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>>>
>>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>>>
>>>>
>>>> Starting with VS2015, the VC runtime requires the universal runtime
>>>> (UCRT).
>>>>
>>>> You can see the resulting paths in the build logs in the output directory. The are passed to the linker with the /LIBPATH option.
>> 
>> Many moons later... on a new clean Win7 x64 laptop with VS2015 Pro I had a chance to start from scratch and see what happens with the above SDK scenario:
>> 
>> After a "clean" install of DMD (2.089.0) and VisualD (0.50.1), I got the
>> following VD Library Paths:
>> Win32:
>> (empty)
>> x64:
>> $(VCINSTALLDIR)lib\amd64
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64
>> Win32-COFF:
>> $(VCINSTALLDIR)lib
>> $(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x86
>> 
>> I did not get the following 2 paths (you mentioned above) added:
>> x64:
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x64
>> Win32-COFF:
>> $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86
>> 
>> So neither the paths for the Win10 SDK nor Wn8.1 SDK were added.
>> 
>> Creating a Win32 app in VS then fails with "LNK1181: cannot open input file 'user32.lib'".
>> 
>> Adding the above 2 paths for Win10 SDK does not solve the above Link error - it still cannot link to 'user32.lib'. From the calc2.buildlog.html I can see:
>> 
>> /LIBPATHs: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib;
>>     C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86;
>>     C:\Program Files (x86)\Windows Kits\10\lib\\um\x86
>> 
>> This gives the following values:
>> $(VCINSTALLDIR): C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
>> $(UCRTSdkDir): C:\Program Files (x86)\Windows Kits\10
>> $(UCRTVersion): 10.0.10240.0
>> $(WindowsSdkDir): C:\Program Files (x86)\Windows Kits\10
>> $(WindowsSdkVersion):
>> 
>> This seems to indicate VD thinks Win10 SDK is installed. However, even though there is a "c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\" folder, there is no Lib folder in it neither any *.lib files.
>> 
>> Searching for 'user32.lib' in C:\Program Files (x86) I get:
>> c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\User32.Lib
>> c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\User32.Lib
>> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm\User32.Lib
>> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\User32.Lib
>> c:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\User32.Lib
>> 
>> Replacing $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86 with a
>> hardcoded "c:\Program Files (x86)\Windows
>> Kits\8.1\Lib\winv6.3\um\x86\User32.Lib" solves the Linking issue - app
>> is build and runs successfully.
>> 
>> But this indicates to me that the required SDK on my machine is actually
>> Win8.1 SDK. And for $(WindowsSdkDir) should be "c:\Program Files
>> (x86)\Windows Kits\8.1\" and for $(WindowsSdkVersion) should be "winv6.3".
>> 
>> I cross-checked in VC++ whether these enviro variables are defined and
>> what their values are in VC++ and get:
>> $(WindowsSdkDir): "c:\Program Files (x86)\Windows Kits\8.1\"
>> $(WindowsSdkVersion): Not defined at all.
>> 
>> So it seems VC++ correctly maps to the Win8.1 SDK, but not VD. I'm actually surprised by this... surely  $(WindowsSdkDir) should be the same for both...?
>> 
>> IS it possible to set/change these enviro variables for VD to their proper values?
>> 
>> 
>
> As the Windows SDK environment variable is usually not set in the system environment, Visual D mimicks vcvarsall.bat from the VC installation to determine it and uses the first hit:
>
Hi Rainer,

Thanks for the very prompt reply!

Ok, checking this...

> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder
--> No KitsRoot10 present.
--> Only KitsRoots present under HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\:
        ..\\KitsRoot: C:\Program Files (x86)\Windows Kits\8.0\
        ..\\KitsRoot81: C:\Program Files (x86)\Windows Kits\8.1\
>
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder
--> This is close, but no banana! There are 3 SDKs listed under KLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\... namely v7.1A, v8.0A and v8.1A. But note that it is *v8.1A*, not *v8.1*. But there are anyway no lib folder at the registry entry for v8.1A.

>
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder
--> Same story as previous check.. it has *v8.0A*, not *v8.0*. Also, no lib folder present at registry entry for v8.0A.

>
> - read registry entry SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder
--> The registry entry is 'C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\', which has no 'lib' folder.

>
> - environment variable WindowsSdkDir
--> Set to 'C:\Program Files (x86)\Windows Kits\10'according to buildlog.html.
>
> Could you please check where it gets the "C:\Program Files (x86)\Windows
> Kits\10" folder from?
--> I really have no idea, since it does not look like there is any 'hit' from the above.
>
> Usually, the library search path are set once, and they are not altered automatically later. You can reevaluate the default settings with the "Reset Settings..." button.

OK, thanks - I will try this.

On my system it looks like the valid entries were all under HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\.., so the following sequence would have been preferable (still taking the 1st hit):

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot81 and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot80 and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder

- read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder

- read registry entry SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder

- environment variable WindowsSdkDir
December 03

On 01/12/2019 23:49, ShadoLight wrote:
> On Saturday, 30 November 2019 at 08:53:32 UTC, Rainer Schuetze wrote:
[...]
>> As the Windows SDK environment variable is usually not set in the system environment, Visual D mimicks vcvarsall.bat from the VC installation to determine it and uses the first hit:
>>
> Hi Rainer,
> 
> Thanks for the very prompt reply!
> 
> Ok, checking this...
> 
>> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder
> --> No KitsRoot10 present.
> --> Only KitsRoots present under HKLM\\SOFTWARE\\Microsoft\\Windows
> Kits\\Installed Roots\\:
>         ..\\KitsRoot: C:\Program Files (x86)\Windows Kits\8.0\
>         ..\\KitsRoot81: C:\Program Files (x86)\Windows Kits\8.1\
>>
>> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder
> --> This is close, but no banana! There are 3 SDKs listed under KLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\... namely v7.1A, v8.0A and v8.1A. But note that it is *v8.1A*, not *v8.1*. But there are anyway no lib folder at the registry entry for v8.1A.
> 
>>
>> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder
> --> Same story as previous check.. it has *v8.0A*, not *v8.0*. Also, no lib folder present at registry entry for v8.0A.
> 
>>
>> - read registry entry SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder
> --> The registry entry is 'C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\', which has no 'lib' folder.
> 
>>
>> - environment variable WindowsSdkDir
> --> Set to 'C:\Program Files (x86)\Windows Kits\10'according to
> buildlog.html.
>>
>> Could you please check where it gets the "C:\Program Files (x86)\Windows
>> Kits\10" folder from?
> --> I really have no idea, since it does not look like there is any 'hit' from the above.
>>
>> Usually, the library search path are set once, and they are not altered automatically later. You can reevaluate the default settings with the "Reset Settings..." button.
> 
> OK, thanks - I will try this.
> 
> On my system it looks like the valid entries were all under HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\.., so the following sequence would have been preferable (still taking the 1st hit):
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot10 and checks if it has a lib folder
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot81 and checks if it has a lib folder
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot80 and checks if it has a lib folder
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots\\KitsRoot and checks if it has a lib folder
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.1\\InstallationFolder and checks if it has a lib folder
> 
> - read registry entry HKLM\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v8.0\\InstallationFolder and checks if it has a lib folder
> 
> - read registry entry SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\CurrentInstallFolder and checks if it has a lib folder
> 
> - environment variable WindowsSdkDir

Thanks for digging through this. I've now added checking all the legacy
SDKs 7/8.0/1(A).

For now, you should be fine with manually setting the library search path to the respective lib folders of the 7.1A/8.1 SDK.
1 2 3