When compiling with /MD the dlls are not included with the .exe, that's why you have to distribute vcruntime140.dll with the exe (unless the user has Visual C++ Redistributable for Visual Studio 2015 installed)
- The executable will be smaller. (only 1-2 MB)
- The code segment of a DLL is shared amongst all processes that are actively using it (reducing the total amount of RAM consumed). (Only a few MB, needs to be measured)
- Will allow to modify/delete/create memory from dll in exe, exe in dll and dll in dll.
- You need to distribute the dll with the exe or tell the user to install vcredist2015.
- If you make users install vcredist2015 then the dll will be exposed to system updates. This sounds great but at the same time it can break your software. Depending on the complexity of your software and the chances of a breaking update on the .dll you are better off distributing the .dll yourself. When a new dll version is released then you can update your software accordingly and distribute it alongside the new version of the dll. Is up to you to decide if not being exposed to updates is good or bad.
When compiling with /MT it means that the dlls are included with the .exe.
- You don't need to distribute the dll with the exe.
- The executable is bigger. (Only 1-2MB)
- It will use more RAM. (Only a few more MB, needs to be measured)
- It is very likely to cause memory leaks and crash your exe. (CriticalObject, VirtualAlloc, HeapAlloc, etc.)
- The dll is not exposed to system updates: some might prefer to use the latest version but this is not always the best idea on software development. When the software is small it's easy to adapt if a new dll version requires it but when you have a software with 20-30k lines of code it becomes extremely hard to maintain.
Sometimes the update is not worth it, sometimes it is. These updates can vary from something simple like a typo fix to something important like a security patch or a change on a function's parameters. Is up to you to decide if not being exposed to updates is good or bad.
ANSI vs Unicode
- Both are character encodings (actually Unicode refers to the character set), ANSI is very old while Unicode is the current standard we use today.
- ANSI programs are slower than Unicode.
- Unicode programs won't work on old computers.
- With your ANSI exe you won't be able to use characters like "Ç" or "Ñ"