Loading ...
Sorry, an error occurred while loading the content.

Re: MSVC build option about default library MSVCRT

Expand Messages
  • Yongwei Wu
    Hi Doug, ... I do not understand what you mean by this. Vim does not support the single-threaded C run-time, but I never heard that Microsoft stopped
    Message 1 of 8 , May 19, 2007
      Hi Doug,

      On 18/05/07, Doug Cook <douglasevancook@...> wrote:
      > There is no such thing as a single-threaded Windows app. The programmer
      > might only start one thread, but other system components might start other
      > threads in the process, so the CRT needs to be aware of threads whether or
      > not the programmer does any threading. That's why Microsoft stopped creating
      > it -- they kept on running into bugs where the CRT screwed up because it
      > didn't correctly handle the multithreaded stuff in Windows.

      I do not understand what you mean by this. Vim does not support the
      single-threaded C run-time, but I never heard that Microsoft stopped
      supporting it. And I do not know a MSVC version that does not have a
      LIBC.LIB. Please clarify.

      > As far as using different CRTs, I'm talking about using them within the same
      > executable. An EXE and a DLL can use different CRTs and still work together
      > with no trouble (as long as they don't try to free each other's memory or
      > share complex data structures). You can have Vim.exe safely load perl58.dll
      > even though they use different CRTs because they are separate executable
      > files. The problem is when Vim.exe uses two CRTs or perl58.dll uses two
      > CRTs. If you link Vim.exe with both libcmt.lib and msvcrt.lib, you are in
      > trouble.

      I agree (mostly). And this is what I try to avoid with /nodefaultlib:msvcrt.

      > LIB files can contain many different kinds of records. One kind is the
      > "import" or "dynamic" record, which says "if you want to call this function,
      > you can find it in this DLL". Another kind is the "static" record, which
      > says "if you want to call this function, add this code to your executable".
      > If tcl84stub.lib contains any static records, it will add code to your
      > executable, and if that code was compiled for the wrong CRT, you might have
      > trouble. If perl58.lib contains only "import" records, then it won't put any
      > code in your executable. It will only tell the linker to load the perl58.dll
      > when necessary. This doesn't affect your executable's CRT.

      Tclstub84.lib is a 2106-byte file, and I do not expect it to contain
      significant code. However, I cannot gurantee that, without looking at
      its source code.

      > You're right - I got _dup and strdup mixed up.
      > Adding /nodefaultlib is probably better in your specific case. It forces
      > those functions to be resolved from libcmt.lib instead of msvcrt.lib.
      > However, you still have a problem because the code was compiled using the
      > header declarations for msvcrt.lib. The header declarations for msvcrt.lib
      > and libcmt.lib are mostly compatible (though with a tiny performance hit for
      > the thunk), but it is not always compatible.
      > Tcl84.dll can have a dependency on a different CRT with no trouble because
      > it is a different executable.

      Mostly. Unless somebody defines the interface foolishly. I suppose
      that does not occur in such famous programs.

      > I suppose that /nodefaultlib wouldn't hurt, in most cases. One thing is that
      > it makes your warnings go away. The warnings are valid, and adding
      > /nodefaultlib would make the warnings go away and you would have no idea
      > that there was a problem.

      It not only removes the warnings, but also removes the wrong
      dependency on msvcr* dlls.

      > In my experience, it is best to either avoid /nodefaultlib (and fix the
      > problems) or to use /nodefaultlib with no library specified, which turns off
      > all default libs.

      Why the latter? I think disabling specific libaries makes one clearer
      what he does.

      > For the other question from the other email --
      > Microsoft can't fix the interface or even some of the bugs for msvcrt.dll.
      > Microsoft does keep adding new methods to msvcrt.dll and fixing bugs. But
      > the Microsoft guys know that hundreds of thousands of programs depend on it
      > (sometimes they even depend on the bugs), so it can't change any behavior of
      > the old version. Some of the things it does are wrong (according to the
      > updated C standard or new security findings) since the interface was
      > designed back in 1995. Microsoft can add new functions, but it can't remove
      > old ones. It sometimes even has trouble fixing bugs because some programs
      > stop working when the bug gets fixed. You also can't use new compilers with
      > the old msvcrt.dll since the version on Windows 2000 or Windows XP doesn't
      > work with Visual C++ 8.0's compiler. (Actually, the Windows Device Driver
      > kit has a special set of libraries that lets you link against msvcrt.dll
      > using VC 8.0, but that is unsupported and really not a good idea in most
      > cases.)

      I agree with some of your points. But keep in mind the run-time
      behaviour of Microsoft run-time functions are not regarded as bugs
      nowadays. People having a cross-platform mind already know the
      limitations of these functions and always live within them when MSVC
      is encountered.

      Do we have any conclusions? It looks to me having /nodefaultlib:msvcrt
      is still better then not having it.

      Best regards,


      Wu Yongwei
      URL: http://wyw.dcweb.cn/
    Your message has been successfully submitted and would be delivered to recipients shortly.