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
ssing 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: Bra
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
ssage-
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
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.
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
