windows - how to link against API sets (*ms-win*) instead kernel32.dll, ntdll.dll etc.?

Question

How do I specify explicitly to MSVC compiler / linker to link against API sets (*ms-win* pattern matcing dlls) instead kernel32.dll, ntdll.dll etc.?

For example, I've created a simple dll, which just calls a few basic WinAPIs. When examining it's IAT (via CFF Explorer, python pefile library etc.) there's only kernel32.dll. What I'd like to happen, is to see *ms-win* dlls instead.

Answer 1

API sets are used internally, meaning even the 'legacy' system DLLs on Windows 7, 8 or 10 use them. Hence there's no reason you need to use them directly.

That said, there are a number of 'umbrella' libraries you can use instead of linking against classic KERNEL32.DLL, etc.:

• onecore.lib
• onecoreuap.lib
• onecore_apiset.lib

Keep in mind that these are intended to match the same Windows build as the Windows 10 SDK they ship in (i.e. they are forward compatible, not backward). There are *_downlevel.lib versions as well which support older builds of Windows. These are all mostly intended for consumption by driver developers per Microsoft Docs

UWP apps use their own umbrella library WindowsApps.lib / WindowsApps_downlevel.lib.

See Microsoft Docs for more on umbrella libraries.

Note that you should not link with more than one umbrella library, and you shouldn't mix kernel32.lib with umbrella libraries in the same link. This is actually a bit challenging to do with MSBuild default rules for scenarios other than WindowsApps.lib. There's an improvement coming in VS 2022 17.2 that addresses this. See this VS feedback issue.

Also due to a quirk of the Microsoft Visual C/C++ Runtime, if you are linking with onecore_apiset.lib, you should use /IGNOREDEFAULTLIB:onecore.lib /IGNOREDEFAULTLIB:kernel32.lib as well. It's also a good idea to use /SUBSYSTEM:WINDOWS,10.0 or /SUBSYSTEM:CONSOLE,10.0. See this VS feedback issue.