Why is CRT preferred to be dynamic in Windows?

[stevefan1999-personal]

It is noticed that CRT builds seems to be preferring to use ucrt.lib (and maybe vcruntime.lib) instead of their static counterpart

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Windows.targets

Lines 99 to 103 in 283a2de

	<ItemGroup Condition="!Exists('$(IlcSdkPath)debugucrt.txt')">
	<!-- Force ucrt to be dynamically linked for release runtime -->
	<LinkerArg Include="/NODEFAULTLIB:libucrt.lib" />
	<LinkerArg Include="/DEFAULTLIB:ucrt.lib" />
	</ItemGroup>

Which is easily countered with:

  <ItemGroup>
    <SdkNativeLibrary Include="libucrt.lib" />
    <SdkNativeLibrary Include="libvcruntime.lib" />
    <LinkerArg Include="/NODEFAULTLIB:ucrt.lib" />
    <LinkerArg Include="/NODEFAULTLIB:vcruntime.lib" />
  </ItemGroup>

So that my final NativeAOT executable is free of CRT. While a workaround is already available, I'm just curious on why?

[MichalStrehovsky]

UCRT is part of all Windows versions that are supported in .NET. It makes little sense to link it statically. We do link the VCRuntime part statically because that one is not part of Windows.

[MichalPetryka]

UCRT is part of all Windows versions that are supported in .NET. It makes little sense to link it statically. We do link the VCRuntime part statically because that one is not part of Windows.

Technically this is not fully correct, Windows Server 2012 is still supported by .NET 8 and that doesn't contain UCRT out of the box, only after updates are installed.

[huoyaoyuan]

only after updates are installed.

I believe only installations with recent updates are considered supported, while fresh RTM installations are not.

[MichalStrehovsky]

only after updates are installed.

I believe only installations with recent updates are considered supported, while fresh RTM installations are not.

Yep, the underlying operating system needs to be in a supported state as well. The docs spell that out under special circumstances only (like when they said .NET 6 is only supported on Windows 7 with Extended Security Updates) but it shouldn't be a surprise.

[DeafMan1983]

Just use libucrt.lib

	  ...
	  <!-- Make statical Universal CRT -->
	  <SdkNativeLibrary Include="libs\libucrt.lib" />
	  <LinkerArg Include="/NODEFAULTLIB:libs/libucrt.lib" />
	  ...

Result with dumpbin:

Microsoft (R) COFF/PE Dumper Version 14.38.33134.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file 01_HelloSDL.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    ADVAPI32.dll
    bcrypt.dll
    ole32.dll
    KERNEL32.dll
    OLEAUT32.dll
    USER32.dll
    VERSION.dll
    GDI32.dll
    IMM32.dll
    WINMM.dll
    SETUPAPI.dll
    SHELL32.dll

...

nor any api-win-*.dll It seems working fine.
Why do you need libvcruntime.lib? It doesn't need to add in your dotnet project.

[MichalStrehovsky]

You shouldn't need to pass any /nodefaultlib for any of the supported operating systems. If you want to do something unsupported, feel free to do so, but I'm not the support channel anymore.

Why do you need libvcruntime.lib? It doesn't need to add in your dotnet project.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170.

[DeafMan1983]

Thank you for supporting me! @MichalStrehovsky,
Result with dumpbin.exe:

dumpbin /DEPENDENTS 01_HelloSDL.exe
Microsoft (R) COFF/PE Dumper Version 14.38.33134.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file 01_HelloSDL.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    ADVAPI32.dll
    bcrypt.dll
    ole32.dll
    KERNEL32.dll
    OLEAUT32.dll
    USER32.dll
    VERSION.dll
    GDI32.dll
    IMM32.dll
    WINMM.dll
    SETUPAPI.dll
    SHELL32.dll

  Summary

       2B000 .data
       69000 .managed
       1C000 .pdata
       BE000 .rdata
        2000 .reloc
        1000 .rsrc
      19B000 .text
        1000 _RDATA
       32000 hydrated

It looks fine. But what does ldd of Msys2 say?
But why does library msvcrt.dll require to load cause it is not free of crt:

ldd ./01_HelloSDL.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff84ba70000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff84a470000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff848b60000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ff84b970000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff84a1e0000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ff84a530000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ff84b840000)
        bcrypt.dll => /c/WINDOWS/System32/bcrypt.dll (0x7ff848800000)
        ole32.dll => /c/WINDOWS/System32/ole32.dll (0x7ff849b10000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff848eb0000)
        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ff84b200000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff849ad0000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff848980000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff848a40000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff8488b0000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff849ff0000)
        OLEAUT32.dll => /c/WINDOWS/System32/OLEAUT32.dll (0x7ff849c40000)
        IMM32.dll => /c/WINDOWS/System32/IMM32.dll (0x7ff84a190000)
        VERSION.dll => /c/WINDOWS/SYSTEM32/VERSION.dll (0x7ff842060000)
        SETUPAPI.dll => /c/WINDOWS/System32/SETUPAPI.dll (0x7ff84ad90000)
        WINMM.dll => /c/WINDOWS/SYSTEM32/WINMM.dll (0x7ff8366a0000)
        cfgmgr32.dll => /c/WINDOWS/System32/cfgmgr32.dll (0x7ff848e60000)
        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ff849260000)

That is really funny if you don't have msvcrt.dll in \Windows\System32 Example Windows 7 or Windows 8.1?

[MichalStrehovsky]

As documented, ldd is too clever by half and actually executes the program. Using the debugger interface to spy on loaded DLLs, attempting to stop the program before its entrypoint is reached.

You're seeing things like ADVAPI32.dll depending on msvcrt.dll. On a different version of Windows the Windows DLL can be built differently. Don't use ldd on Windows.

C:\Windows\System32>dumpbin /DEPENDENTS advapi32.dll
Microsoft (R) COFF/PE Dumper Version 14.38.33134.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file advapi32.dll

File Type: DLL

  Image has the following dependencies:

    msvcrt.dll
    ntdll.dll

... rest omitted for brevity

[DeafMan1983]

Thanks for explanation!

ldd from Msys2:

ldd advapi32.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff84ba70000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff84a470000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff848b60000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff84a1e0000)
        advapi32.dll => /c/WINDOWS/System32/advapi32.dll (0x7ff84b970000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ff84a530000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ff84b840000)
        bcrypt.dll => /c/WINDOWS/System32/bcrypt.dll (0x7ff848800000)

Why I shouldn't use ldd?

But Linux checks for Wine if you use Wine Runtime.

[AustinWise]

dumpbin answers the question "what DLLs does this binary directly depend on". ldd answers the question "what DLLs are loaded into a process when the OS loader loads the this binary". ldd will include transitive dependencies. ldd's answer will vary depending on what operating system you run it on and other environmental factors.

[DeafMan1983]

I am a Linux User. That's why I always use ldd and know executable of Windows and executable of Windows loads dlls. But why are dumpbin and ldd very differently? Imagine about sections if you see in dumpbin's result and you can use upx than you expect in dumpbin's result. Why does executable of Windows loose 6 sections?

[AustinWise]

On Linux, readelf is similar to dumpbin. When I run this on my linux computer, it shows that gnome-terminal directly depends on 8 shared libraries:

readelf -d `which gnome-terminal`

The readelf program determined by reading the headers in the gnome-termal file.

When I run this:

ldd `which gnome-terminal`

It shows 85 shared libraries are loaded by gnome-terminal. Behind the scenes, the ldd script is just running this:

LD_TRACE_LOADED_OBJECTS=1 gnome-terminal

When a program is started with the LD_TRACE_LOADED_OBJECTS environmental variable set, it runs until the dynamic linker has loaded all libraries, prints the list of libraries, and exits.

When to use ldd or readelf

• Since ldd runs the program to figure out what libraries are loaded, you should only run it on programs you trust. Malcisious applications may run arbitrary code.
• readelf can help you figure out what libraries an executable depends on. You can use this information to install the required libraries using a package manager like apt. You can also use this information to make sure you are not depending on something you don't want to.
• ldd is helpful when trying to figure out why a program won't start, because it will print which libraries are missing.
• You could conceivably use ldd to figure out all the libraries a program depends. You could then create a smaller Docker container image by excluding unneeded libraries. This is probably error prone, so something like Chiselled Ubuntu would be easier.

Lastly, check out libtree. It is like ldd, but it displays the information in a tree. Also, it works by reading the binaries, not executing them.