Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Topic started by: Flashy on July 10, 2011, 03:38:05 PM

Title: Code Generator- Runtime Libraries
Post by: Flashy on July 10, 2011, 03:38:05 PM
When I started a new project today, I realized for the first time that the default setting for runtime libraries is at /MT. Is this not intended, or why shouldn't we use /MD?
Title: Code Generator- Runtime Libraries
Post by: Hooman on July 10, 2011, 05:40:19 PM
I'm not aware of a conscious decision to change that setting, but there may have been one. I think MT might actually be the default though.

/MT - statically link runtime files.
/MD - dynamically link runtime files.


Here's why: If the Microsoft Visual C++ Runtime DLL is not installed on the target system, anything compiled with the /MD option will not run. This DLL is, I believe, installed with Visual Studio, and so /MD compiled programs will work on the developers machines, but often fail when deployed to client machines. Hence, the MT option is less likely to cause obscure and hard to debug problems. (How do you get good debugging information when the problem only occurs on the client's machine?)

The MD option should produce slightly smaller executables. But unless you're packaging your software with an installer that ensures the runtime library is installed, it might not run on the end user system. Also, considering the size of the DLL is about equal (or probably slightly greater) than who much would be stripped out of the exe, this doesn't exactly help packaging and distribution, unless you can ensure those DLLs are already present and don't need to be included in an installer.

Also, using MD requires runtime linking, which add slightly to the startup time.

Edit: One space saving for the MD options, is if you're distributing multiple EXEs in one package, all compiled with /MD, and an installer than ensures the DLL exists. Then you save space from each executable, at the cost of only a single extra DLL.

Mind you, as most packages are compressed, and the runtime code in each executable is the same, you might expect a solid archive to compress that code quite well anyway. I don't know if installers typically use solid archives, but it would make sense if they did. Solid archives compress all their files together in one big clump, rather than compressing each file individually. This allows for better compression, but to extract any given file, all files stored before it must be processed first. This makes individual file access slow, but is irrelevant if all files are being extracted anyway (such as what an installer would typically do).

MD does have slight disk space savings when lots of EXEs are installed and share a single runtime library, but with today's harddrive sizes, this is fairly irrelevant and I would be more concerned with the performance impact, and ease of distribution/installation.
 
Title: Code Generator- Runtime Libraries
Post by: Flashy on July 11, 2011, 06:44:20 AM
Thanks for your answer. I just thought about reducing the dlls sizes, as there are a lot mission dlls using the same runtime, while being statically linked. After all, it can make the difference between a 120 KB DLL and 17 KB.
Title: Code Generator- Runtime Libraries
Post by: TH300 on July 11, 2011, 10:56:51 AM
Using LibCTiny keeps dll sizes small, although we are statically linking. As far as I know the old mission sdk uses LibCTiny by default. But there is an incompatiblity with newer versions of MSVC++, so I don't know about those.

One more advantage of static linking (which doesn't apply here) is that you  aren't effected by api changes, i.e. the library that you use can change its interface (which would normally force you to adept your exe/dll to that interface and recompile) and your exe/dll continues to work, because it has a specific version of the library included.