Reputation: 61
I have MSVC 141 / VS2017 and two Windows toolkits installed (10.0.17763.0 and 10.0.18362.0). However, do I get to really choose which ucrtbase.dll is being used? VS automatically uses my system DLL's despite there being several variants in the Microsoft SDKs / Windows Kits part of the file system. It also uses these system DLL's regardles of building my program with Windows SDK Version 10.0.17763.0 or 10.0.18362.0.
'Demo.exe' (Win32): Loaded 'C:\Users\business\source\repos\YZ\x64\Release\AEC_Demo.exe'. Symbols loaded.
'Demo.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Symbols loaded.
'Demo.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Symbols loaded.
'Demo.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Symbols loaded.
'Demo.exe' (Win32): Loaded 'C:\Users\business\source\repos\YZ\x64\Release\AEC_DLL.dll'. Symbols loaded.
'Demo.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'.
:
Here is the dll.intermediate.manifest (I also build a DLL that Demo.exe uses):
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Here is Demo.exe's manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Upvotes: 0
Views: 349
Reputation: 179961
You might be discovering a critical difference between Windows and Linux.
On Linux, the usual approach is that you compile software to run on your local machine, and just there. It's generally a miracle if that binary runs somewhere else. Therefore, you link your program against the system libraries. The flip side of this is that Linux crosscompiles are an utter nightmare.
Windows builds on the other hand are effectively always cross-compiles. You compile against a Windows SDK, not the system libraries on which happen to live on your particular build machine. Those SDK's in turn support a number of Windows versions, up to the indicated version, but usually also for older versions. The UCRT goes back to Windows 8.1 IIRC, even if you use the 10.0.18362.0 SDK.
Now if you then test your executable, you now use your PC as a runtime environment. It doesn't matter that the same PC has one or more Windows SDK installed. You can't expect end users to have SDK's installed, after all. It's Windows, the typical user is not an engineer. Therefore your executable uses the system DLL's. And if you need Visual C++ DLL's, you'll need to include the VC++ redistributable in your installer.
Upvotes: 1
Reputation: 43308
When you run on Win32; you have to load the Win32 dlls into your process or nothing works. Unlike certain other operating systems, on Windows, the syscalls are not the ABI surface, but rather the shared libraries (dlls) provided by Windows such as kernel32.dll, user32.dll, gdi32.dll, and advapi32.dll. kernelbase.dll and ntdll.dll are dependencies of kernel32.dll.
ucrtbase.dll is another OS component with similar rules, just not a mandatory component. If you use this component you link against the OS version of that compoment, and and a version from one OS won't work on another OS.
For these dlls, setting the SDK version lower changes the version you link against (by linking against older .lib files) but not the version you run against. Trying to use functions that aren't in the older version of Windows won't work unless you call them dynamically.
Upvotes: 3