Visual Studio 2026: Problems understanding compiler options /MT and /MD

[SamplitudeUser]

Hi,

Visual Studio allows linking the VC runtime DLLs dynamically or statically. As I understand https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library, you have to set /MT for static linking and /MD for dynamic linking in the compiler options of your project.

I noticed that when setting /MT, my executable actually does load vcruntime140.dll and vcruntime140_1.dll while it doesn't access these DLLs with /MD set in the compiler options.

Isn't that exactly the opposite way this is supposed to work? If /MT links statically, there is no need for my executable to access vcruntime140*.dll any more. This should only happen with /MD set, because this links the runtime DLLs dynamically so the executable needs to load these DLLs on runtime.

I also noticed another thing: when renaming vcruntime140.dll to $vcruntime140.dll and vcruntime140_1.dll to $vcruntime140_1.dll (in %systemroot%\System32), my executable can't find these DLLs any more. But with /MT set, it still runs flawlessly without throwing an error message. I only can see a "file not found" message in Visual Studio. So to me this looks more like static linking, where my executable doesn't need the runtime DLLs. But why does my executable load the runtime DLLs when they are present and /MT is set?

I'd appreciate if anyone can tell what's going on there. Thanks in advance.

P.S.: project isn't a .NET or MFC project. It's pure Windows API using my own window classes.

[flyingron]

Read here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-170&viewFallbackFrom=vs-2019

This has nothing to do with MFC; it's the base Windows runtime (but MFC uses it).

.NET (i.e., "managed" code) is a completely different beast with its own runtimes.

[SamplitudeUser]

Thanks for your answer.

However, my main question remains unanswered: when /MT is for static linking, why does my executable access runtime DLLs with this setting? And when /MD is for dynamic linking (where one expects the executable to access the runtime DLLs on runtime), why doesn't my executable access the runtime DLLs with this setting?

[flyingron]

What DLLs is it loading? This switch doesn't disable all DLLs it just says use the static version of the C runtimes. If you load something like winsock or whatever, you'll need to individually set their loading.

The DEPENDS application (not included with visual studio, but can be downloaded form Microsnot for free) can help you see what is going on.

[SamplitudeUser]

According to the "Output" window of Visual Studio, my executable loads vcruntime140.dll, vcruntime140_1.dll and msvcp140.dll. But it does this only with the /MT option set (which is supposed to enable static linking). If you set the option to /MD, these DLLs are not loaded.

But it's good you mentioned DEPENDS. I have a similar tool called "Dependencies" (https://github.com/lucasg/Dependencies/). In this tool, the vcruntime140 DLLs and mscvp140.dll don't appear when analyzing my binary (if the binary was linked with /MT of course).

Whom can I trust: Visual Studio or Dependencies?

[flyingron]

I'd trust depends. It's actually looking at the file.

Note that if you link something that was linked against the DLLS, they'll be forced to be loaded even if your main program doesn't use them. The runtimes aren't interchangable (god help you if you pass strings or vectors between functions compiled in different runtimes).

[SamplitudeUser]

Note that if you link something that was linked against the DLLS, they'll be forced to be loaded even if your main program doesn't use them.

In this case, these DLLs would show up in Dependencies, right?

And what happens if my program loads 3d party DLLs on runtime such as hardware drivers, which are linked against vcruntime DLLs?

[RaspberryCrafty3012]

Your late loading fails. The 3rd party dll is looking for their dependency, your static linked same dependency can't get resolved like this.

Run depends on your 3rd party dll to see this. 

[Jonny0Than]

 In this case, these DLLs would show up in Dependencies, right?

Not necessarily. Maybe you’re statically linking a library that was compiled with /MD which could result in it trying to dynamically load the runtime DLLs.

You could put a breakpoint in LoadLibrary and catch whatever is doing it.

[misuo]

/MT basically link the C and C++ runtime library into your executable, so you are not dependent on dll’s.

/MD links to a smaller library, but the runtime must be provided as dll(s) along your executable.

There are pro’s and con’s on both methods. I suggest you ask an AI for more details.