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
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
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
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
: 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
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
