News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Relevance of libcmt.lib?

Started by jamespetts, May 07, 2012, 05:34:23 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Following from some of the discussion on this thread about bugs in Experimental that seem to occur only on Windows XP in a build that is dynamically linked, may I ask what the reason for building Simutrans dynamically rather than statically is, and why libcmt.lib, which I understand is necessary for a realease build to be statically linked without using the debug libraries, is ignored in the MSVC++ project? (I assume that this is still so in Standard, incidentally - these settings are settings that Experimental inherited from Standard).

Also, if anyone has any idea why a bug might arise only when Simutrans is linked dynamically, and then only in Windows XP, I should be very grateful for any insight.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

I think the main advantage with dynamic linking these days, is that the libraries can be updated separately. Especially the Microsoft C and C++ runtime libraries are updated through Windows Update. The principle of only having shared code once is also still as valid as always, for easy updating at least, even if the practical benefit of less space used isn't as important anymore.

As for why it only fails on XP: There might be a bug in the C or C++ runtime DLL for Windows XP. But it is also possible that some other implementation differences in the OS trigger it, though it's usually the newer operating systems that cause bad code to begin crashing.

jamespetts

Thank you for your reply. If I want to link statically to work around this bug, will re-enabling libcmt.dll cause any problems?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

The settings are needed for Dr. Memory. As I never release (with one exception) the MSVC build, I kept them this way. The problem is most likely, that the DLL in XP are from ancient MSVC 6.x. Since XP does not have a version management for DLLs yet, the executable uses probably indeed the wrong libraries.

That said, standards builds and run on XP in a short test using MSVC 2008. (MS2010 does not work on my XP; since the old installation has a broken .NET capabiliy.)

However, for releases you can safely use static linking. Thus make the release build static and the debug build (which will be used with Dr. Memory likely) with DLL.

HeinBloed

Prissi, I made sure with the Process Explorer from Sysinternals that the Simutrans executable loaded the runtime libraries I was expecting it to load, i.e. msvcr100.dll and msvcp100.dll in three different versions each, which made no difference. However, the process also loads msvcrt.dll, which according to this documentation is a system component. The version of that DLL is quite old in XP compared to Vista/7 indeed, but in theory it shouldn't really be used (?). I was hoping that someone had an idea along the lines of what is described in the next paragraph in that documentation ("What problems exist if an application uses both msvcrt.dll and msvcr100.dll?") and here ..
(previously known as "tttron")

jamespetts

Prissi,

thank you for your assistance with that - that is most helpful. Am I to presume that I need to re-enable libcmt.lib, and that doing so will not cause difficulties?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: prissi on May 07, 2012, 07:20:51 PM
The problem is most likely, that the DLL in XP are from ancient MSVC 6.x. Since XP does not have a version management for DLLs yet, the executable uses probably indeed the wrong libraries.

Since the DLLs for MSVC 6, 7, 8, 9 and 10 have different names, even XP should be able to tell then apart.

Quote from: HeinBloed on May 07, 2012, 08:27:20 PM
Prissi, I made sure with the Process Explorer from Sysinternals that the Simutrans executable loaded the runtime libraries I was expecting it to load, i.e. msvcr100.dll and msvcp100.dll in three different versions each, which made no difference. However, the process also loads msvcrt.dll, which according to this documentation is a system component. The version of that DLL is quite old in XP compared to Vista/7 indeed, but in theory it shouldn't really be used (?). I was hoping that someone had an idea along the lines of what is described in the next paragraph in that documentation ("What problems exist if an application uses both msvcrt.dll and msvcr100.dll?") and here ..

Simutrans itself should not be able to load both msvcr100.dll and msvcrt.dll, but some of the other DLLs Simutrans loads might be linked against msvcrt.dll. In fact, core system DLLs such as shell32.dll does links against msvcrt.dll on my Windows 7 system.

Having different C runtimes in the same process should not be a problem as long as the C runtime implementation is not exposed through the API, such as returning a string (char*) that the caller is supposed to free() itself. I expect Microsoft to get this right in system DLLs. With C++ it's different, as a C++ API can't help but expose on the C++ implementation behind it, however AFAIK Microsoft doesn't use C++ APIs for system components. Using C++ to implement a C API is fine.

prissi

Well, I built simutrans standard with default settings on my XP system at work without any problem or DLL clashes. Maybe the bug reported is something peculiar to a certain system or to some actions in the experimental code.