Re: MSVC build option about default library MSVCRT
- 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
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
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
Do we have any conclusions? It looks to me having /nodefaultlib:msvcrt
is still better then not having it.