Hi Doug, On 18/05/07, Doug Cook <[EMAIL PROTECTED]> 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, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
