RE: MSVC build option about default library MSVCRT
If the lib is added explicitly, you're right -- it probably won't break anything. However, there are actually three CRTs. libc (single-threaded static), libcmt (multi-threaded static), and msvcrt (multi-threaded DLL). libc is no longer supported (there is no longer any such thing as a single-threaded Windows app because things like signals can come in on separate threads). So adding a nodefaultlib for msvcrt is not just like the nodefaultlib for libc. It would be like a nodefaultlib for libcmt. Lib conflicts are scary. They work only because you are lucky and because the Microsoft CRT developers worked very hard to make things work ok most of the time. However, there are some functions that don't work ok, and the list of functions that don't work ok is subject to change at any time. And sometimes you might be using a function that mostly works ok except for some strange edge cases. Better to just avoid the whole issue if possible. As for allowing multiple CRTs, I was referring to the warning. It warns when you link with multiple CRTs at the same time. In your case, the conflict looks scary because you have linked with _dup but not with free... You should only use one CRT in an EXE or DLL. Any time you use more than one within the same executable, you're in undefined territory and while things may work, things could go wrong at any time. There's nothing wrong with msvcr71.dll or msvcr80.dll. In fact, they have many bug fixes and performance improvements over msvcrt.dll. However, if you link against one of them, it has to be installed on the target machine or the EXE/DLL won't load, while msvcrt.dll is always present on every copy of Windows. That said, you might run into an old versions of msvcrt.dll that is missing functions you need (each new version of Windows has added new functions to msvcrt.dll), while you pretty much know what you are getting when you use msvcr71 or msvcr80. -Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: Thursday, May 17, 2007 7:15 AM To: Doug Cook Cc: Bram Moolenaar; Vim-dev mailing list Subject: Re: MSVC build option about default library MSVCRT Hi Doug, On 17/05/07, Doug Cook [EMAIL PROTECTED] wrote: Bram is wise. No objection here ;-). Adding a nodefaultlib:msvcrt could potentially break things if you set USE_MSVCRT=1 to use the CRT DLL instead of statically linking the CRT. The problem is that you're linking a static-CRT version of Vim with DLL-CRT versions of ActiveState components. The problem is not with Vim's makefile. Adding /nodefaultlib:msvcrt does not affect USE_MSVCRT=1, which will add the NON-default library msvcrt.lib explicitly. In fact, I think /nodefaultlib:msvcrt is really symmetrical with the current setting. We already have /nodefaultlib:libc, which disables the default static libc. Why should we allow default dynamic libc while disabling default static libc? Generally, if you have lib conflicts, it means you've done something wrong. In this case, you have one OBJ that was compiled for use with the static CRT, and another OBJ that was compiled for use with the dynamically-linked CRT. Each of them tell the linker you should probably link me with this particular CRT. Luckily, the linker is smart enough to only allow one CRT at a time. Lib conflicts are something wrong, but not necessarily serious. It is a serious problem only if one does some foolish things like malloc in one CRT and free in another. Also, the linker does allow two CRTs at the same time, and which occurred to me, if I did not add /nodefaultlib:msvcrt. LibcMT will be linked, but the following five functions are imported from MSVCR71.dll: _fileno _chdir _fdopen _dup _putenv _stat _dup2 For a standalone program, statically linking with the CRT is generally the way to go, so Vim defaults to doing this. Using the CRT DLL saves about 150k in disk space, but the CRT DLL is 400-800k, depending on which version of Visual C++ you're using. The CRT is potentially already in memory in another process, so this may or may not save memory at runtime. For a program that interacts with other DLLs (such as loading Perl, Python, Ruby, etc. DLLs at runtime), the CRT DLL starts to make more sense. In addition to saving disk space (one CRT DLL instead of 150k of static CRT in each executable), you save memory (one CRT DLL loaded, and all modules share the same heap) and in some cases you avoid bugs (only one CRT so you don't have conflicting CRT settings like locale). However, you now have to redistribute the CRT with your product, and starting with VC 8.0, you have to get the CRT's manifest correctly embedded into your EXE and DLLs. Another problem with CRT DLL is that different MSVC versions will make the resulting executable dependent on different CRT DLLs. Linking with MSVCRT.LIB in MSVC 7.1 results in the dependency on MSVCR71.DLL instead of MSVCRT.DLL. This is not something we like, I suppose. Best regards, Yongwei -- Wu Yongwei
RE: MSVC build option about default library MSVCRT
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. 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. 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. 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. 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. 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. 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.) -Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: Thursday, May 17, 2007 7:03 PM To: Doug Cook Cc: Bram Moolenaar; Vim-dev mailing list Subject: Re: MSVC build option about default library MSVCRT Hi Doug, On 18/05/07, Doug Cook [EMAIL PROTECTED] wrote: If the lib is added explicitly, you're right -- it probably won't break anything. However, there are actually three CRTs. libc (single-threaded static), libcmt (multi-threaded static), and msvcrt (multi-threaded DLL). libc is no longer supported (there is no longer any such thing as a single-threaded Windows app because things like signals can come in on separate threads). So adding a nodefaultlib for msvcrt is not just like the nodefaultlib for libc. It would be like a nodefaultlib for libcmt. Points taken. (Though I think LIBC.lib and single-threaded Windows apps still make sense in some cases: not Vim.) Lib conflicts are scary. They work only because you are lucky and because the Microsoft CRT developers worked very hard to make things work ok most of the time. However, there are some functions that don't work ok, and the list of functions that don't work ok is subject to change at any time. And sometimes you might be using a function that mostly works ok except for some strange edge cases. Better to just avoid the whole issue if possible. How? I mean, perl58
RE: MSVC build option about default library MSVCRT
Bram is wise. Adding a nodefaultlib:msvcrt could potentially break things if you set USE_MSVCRT=1 to use the CRT DLL instead of statically linking the CRT. The problem is that you're linking a static-CRT version of Vim with DLL-CRT versions of ActiveState components. The problem is not with Vim's makefile. Generally, if you have lib conflicts, it means you've done something wrong. In this case, you have one OBJ that was compiled for use with the static CRT, and another OBJ that was compiled for use with the dynamically-linked CRT. Each of them tell the linker you should probably link me with this particular CRT. Luckily, the linker is smart enough to only allow one CRT at a time. For a standalone program, statically linking with the CRT is generally the way to go, so Vim defaults to doing this. Using the CRT DLL saves about 150k in disk space, but the CRT DLL is 400-800k, depending on which version of Visual C++ you're using. The CRT is potentially already in memory in another process, so this may or may not save memory at runtime. For a program that interacts with other DLLs (such as loading Perl, Python, Ruby, etc. DLLs at runtime), the CRT DLL starts to make more sense. In addition to saving disk space (one CRT DLL instead of 150k of static CRT in each executable), you save memory (one CRT DLL loaded, and all modules share the same heap) and in some cases you avoid bugs (only one CRT so you don't have conflicting CRT settings like locale). However, you now have to redistribute the CRT with your product, and starting with VC 8.0, you have to get the CRT's manifest correctly embedded into your EXE and DLLs. -Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 7:54 PM To: Bram Moolenaar Cc: Vim-dev mailing list Subject: Re: MSVC build option about default library MSVCRT Hi Bram, On 15/05/07, Bram Moolenaar [EMAIL PROTECTED] wrote: [redirecting to vim-dev] I am wondering whether l. 705 of Make_mvc.mak in vim-7.1-extra.tar.gz should be change from LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc to LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc /nodefaultlib:msvcrt I have been using it for maybe half a year and not found a single problem yet. It will eliminate this message when building vim.exe: libcmt.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library Without /nodefaultlib:msvcrt vim.exe will have a dependency on MSVCR71.DLL (I use MSVC 7.1). This added flag will not affect gvim.exe. The command lines I used are: nmake -f Make_mvc.mak GUI=yes OLE=yes MBYTE=yes IME=yes GIME=yes CSCOPE=yes PERL=C:\Perl DYNAMIC_PERL=yes PERL_VER=58 PYTHON=C:\Python24 DYNAMIC_PYTHON=yes PYTHON_VER=24 RUBY=C:\ruby DYNAMIC_RUBY=yes RUBY_VER=18 RUBY_VER_LONG=1.8 TCL=C:\Tcl DYNAMIC_TCL=yes TCL_VER=84 TCL_VER_LONG=8.4 XPM=C:\xpm %* nmake -f Make_mvc.mak MBYTE=yes CSCOPE=yes PERL=C:\Perl DYNAMIC_PERL=yes PERL_VER=58 PYTHON=C:\Python24 DYNAMIC_PYTHON=yes PYTHON_VER=24 RUBY=C:\ruby DYNAMIC_RUBY=yes RUBY_VER=18 RUBY_VER_LONG=1.8 TCL=C:\Tcl DYNAMIC_TCL=yes TCL_VER=84 TCL_VER_LONG=8.4 XPM=C:\xpm %* I'm very careful with these things. Make_mvc.mak is used for several versions of MSVC, starting at 4.1. You need to check all versions to make sure it doesn't cause any problems. Er ... I do not have access to such old versions. I work on 7.1, and can do so on 6.0 too. However, I believe MSVC versions are not significant here. See below. I suppose the error message you get is from some of the languages Ruby/Python/Tcl/ I don't get it, thus you can probably solve it by checking your included libraries. Perhaps one has not been build by MSVC? That usually causes trouble (not just an error message, but a crash at runtime). Try actually using all the languages. I noticed that you did not build vim.exe with the languages, which should be the reason you do not see the warning message. I have verified that removing ActiveTcl 8.4 from my build makes /nodefaultlib:msvcrt not necessary: in fact, then the option does not have any effect at all. I did actually try executing simple commands in Perl, Python, Tcl, and Ruby, and they all succeeded. I use the popular ActiveState builds for Perl, Python, and Tcl, and ruby185-21 from the Ruby web site. I believe they are all MSVC compatible. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
RE: bug: gvim 7.0.205 on xp can not display ucs-2
What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
RE: bug: gvim 7.0.205 on xp can not display ucs-2
Using gVim, if I load your file normally, I do get ASCII instead of Unicode. But if I then type: :e ++enc=ucs-2 it appears to work. I don't have a Chinese font, so I get a box, but it is a single character and it is double-width, so it appears to be interpreted correctly by Vim. The same thing happens automatically if I insert the UCS-2 byte order mark fe ff at the start of the file. The console version is a bit more tricky, and correct behavior from Vim might depend on various system settings. In my case, the console version reports a conversion error. -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 1:53 AM To: Doug Cook Cc: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
RE: vim and 64bit xp
Shell extensions are very specific to a particular bitness of Windows. -- 32-bit DLLs can only load into 32-bit processes. -- 64-bit DLLs can only load into 64-bit processes. The default shell for Win64 is the 64-bit version of explorer.exe (this is configurable), and it will NOT load the 32-bit gvimext.dll for two reasons: 1. The 32-bit gvimext.dll is a 32-bit DLL. 2. The 32-bit gvimext.dll is registered in the 32-bit registry. To make this work, you would have to rebuild gvimext.dll in a 64-bit version and register it in the 64-bit section of the registry. Note that you may find gvimext working in such places as the File-Save and File-Load dialogs of 32-bit processes, since they DO load the 32-bit shell extensions. You can also run the 32-bit shell instead of the 64-bit shell, and this will get your shell extensions back in most cases. As an alternative, you can get Open with gVim in your right-click menu WITHOUT gvimext.dll. This works on ALL versions of Windows. Open RegEdit and: 1. Navigate to HKEY_CLASSES_ROOT\* 2. Create or open a subkey named shell. 3. Create a subkey named vim. 4. (Optional.) Set the default value of the vim key to whatever you want to appear in the right-click menu (i.e. Edit with gVim). If you don't do this, the name of the subkey (vim) will be used. 5. Create a subkey named command. 6. Set the default value of the command key to the command you want to run. Mine is: C:\Tools\vim\vim70\gvim.exe %1 -Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 4:46 PM To: Brian Krusic Cc: vim-dev Subject: Re: vim and 64bit xp Brian Krusic wrote: Thanks fo rthe reply. Still no shell extension. I did the regedit approach. Any ideas? Is Gvimext.dll in a directory in your PATH? Check it at the dos-box prompt: echo %PATH% or in Vim: :echo $PATH If it isn't, you can set it in (IIRC) Control Panel - System - Advanced - Environment variables The Dos/Windows PATH is a semicolon-separated list of directories; the directory containing that DLL may be either the same as for gvim.exe (usually something like C:\Program Files\Vim\vim70) or a gvimext subdirectory of that (I'm not on Windows at the moment and can't check). Best regards, Tony.
