Results 1 to 5 of 5

Thread: Multithreaded vs. Multithreaded DLL

  1. #1
    Peasant pTymN's Avatar
    Join Date
    Oct 2006
    Location
    Durham, NC
    Posts
    9

    Default Multithreaded vs. Multithreaded DLL

    Hello,

    I was trying to integrate Clanlib and another library into my project and noticed that there were problems because Clanlib is configured to use the "multithreaded" version of C runtime, but the other library was compiled against "multithreaded DLL". Microsoft recommends that developers avoid using the static version of the runtime, because executables that use the statically linked version of the C runtime cannot receive security updates. It is pure stupidity that we have to worry about these kinds of issues on Windows, and I applaud your efforts to maintain a Win32 port of Clanlib. Would you guys fix this pretty please? I already fixed my copy of 0.8.0.

    -Tim K.
    Screenshot of my project. Converted from Lisp to C++ and piled on even more optimizations. I can perform sorted collision testing between 20 objects at ~800 fps. Dynamic line-circle collision test source.

  2. #2
    Lesser Knight
    Join Date
    Sep 2006
    Posts
    41

    Default

    The problem is already fixed. When you use the batch compilation tool in VC++, you are able to select which configurations to use.

    If you want to use the multithreaded DLL version, then use... wait for it... "MTDLL".

    In fact, if you use the batch compilation, you can compile *all* versions, and select for each program which one you'd like to use. (ClanLib might be already configured to automatically select the library that matches what your current project uses, but I'm not certain about that).

  3. #3
    Peasant pTymN's Avatar
    Join Date
    Oct 2006
    Location
    Durham, NC
    Posts
    9

    Default

    As of 0.8.0, the header files all still use

    #pragma comment(lib,

    and refer to the MT not MTDLL versions of the libraries, so they are chosen as the default. I didn't see any preprocessor defines that I could use to disable Clanlib's automatic including of input libraries, so I hacked the header files. What would be the best solution?
    Screenshot of my project. Converted from Lisp to C++ and piled on even more optimizations. I can perform sorted collision testing between 20 objects at ~800 fps. Dynamic line-circle collision test source.

  4. #4
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Oh don't get me started on the so-called security measures implemented by a guy that just got a new position at Microsoft. But since you got me started, you might as well get the entire story

    -- RANT BEGIN --

    The C/C++ runtime libraries exist in two versions: a static library version and a DLL version. The DLL version of the runtime allows multiple DLLs in a process to share the same global variables, memory heaps and the general state of the runtime (such as the current locale being used), while the static version links the state into each module.

    Then one day Microsoft apparently had (or imagined, not sure if they ever had one) a security related bug in their runtime and someone said 'OMG! The applications using this runtime would have to be updated'. Realizing they had no system set up to inform software developers using Visual Studio that their software needs a rebuild, a guy decided that it would be better to make the runtime DLL a system side-by-side assembly DLL. The same guy decided that the static runtime was 'dangerous' because if you had abandonware software, you would not be able to obtain a new executable with the bug fixed. Of course this ignores the fact that any other bug in the application would also not get fixed, so with abandonware you are generally not really that safe from bugs that were never fixed when it was alive.

    Anyway, to get to the point, when MS decided to use their side-by-side assembly system as their method to share the DLL between all applications, ignoring the known past of why earlier MS developers moved it away from DLL hell, they forgot one important thing: the C/C++ runtime is not designed to work side-by-side. In fact, the entire point of MSVCRT80.DLL is to have one shared runtime state.

    When a DLL is installed in the SxS system cache, it is stored as a specific version with information about what other versions it is compatible with. For example, if MSVCRT80.DLL that came with first VS80 is 8.0.0.1000, and the MSVCRT80.DLL that come with VS80 SP1 is 8.0.0.2000, then a system with SP1 installed will be able to load a program that was compiled with VS80, but a system without the SP1 DLL will not be able to load a program compiled with SP1.

    The effect of the above means that if I compile a DLL with VS80 SP 1, and you link it on your VS80 (without SP 1), then it will link fine, but will fail to run. It gives you the most cryptic error ever conceived by mankind, and you need to guess that you need SP 1. Furthermore, you can no longer just download a program with all its DLLs and run it. You now MUST include an installer, which then installs the runtime DLLs in your system SxS assembly cache.

    Theoretically the side-by-side assembly system allows an application to define private assemblies, but unfortunately that system does not allow you to specify a range of versions the DLL covers. In other words, a MSVCRT80.DLL that is included in your application directory can only say it is version 8.0.0.1000 or 8.0.0.2000 - never both. So those DLLs you built without SP 1 installed, well yes, you guessed, go on and recompile them. Oh did you install that Vista update? Yep, you have to recompile them again. What? You can't recompile that 3rd party DLL you bought online? Aww, too bad. Say good bye to private assemblies.

    Uhm, to conclude my rant, if you truely want to experience the HELL that makes Visual Studio 8.0 one of the worst C++ compilers from Microsoft in a decade, start using MTDLLs. Personally I'm staying to static libs whenever I can.

    (I miss good old Visual Studio 6 - it was fast, it compiled just as good code and the IDE never made my computer swap like a pig)

    -- RANT END --

    To answer your question about the pragmas, you can define CL_STATIC_MTDLL to make it link with the MTDLL version of the runtime - at least it works with 0.9.

    Note: If you do use the MTDLL build, you cannot use the binaries made available on clanlib.org, since they are all built for MT. You may be able to use them anyway, if you specify it should ignore the MT runtime libs, but I haven't experimented with that stuff much.

  5. #5

    Default

    Thanks for your rant. Really cleared things up for me, as I've spent the last couple of days pulling my hair out over why it couldn't find the bloody MSVCR90.dll

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •