... From: Antoine J. Mechelynck ... feature, ... According to
Message 1 of 24
, May 30, 2004
----- Original Message -----
From: "Antoine J. Mechelynck" <antoine.mechelynck@...>
> > I proposed Bram to use unicows.dll a couple of months ago, and the
> > issue
> > came up again last week. The main concern is the ability to do dynamic
> > loading of the same kind done for libintl.dll and iconv.dll. Do you
> > think
> > it is possible?
> (I might be wrong, but) I suppose it is, by adding a new compiling
> let's say +unicows/dyn or something like that; but IMHO it should remain
> possible (as it is now) to edit Unicode data even with -unicows (and
> +multi_byte of course).
homepage for unicows):
Does not slow down applications on WinNT/2K/XP - The custom loader
for unicows.dll is built into unicows.lib and compiled with your
application. It does not even load MSLU unless you are on a Win95/98/ME
machine! The technology is similar to the VC++ delayload mechanism, but is
an independent solution that does not rely on any particular compiler.
Clearly, there's some smarts built into the unicows.lib stub that you link
into your application (vim or gvim), which bypasses a direct dependency on
unicows.dll. Vim should run just fine even if there's no unicows.dll in the
path on WinNT/2K/XP. Presumably it also runs, somewhat degraded, on
95/98/Me. This whole paragraph is surmise, and I don't have time to
experiment for myself in the next few days. I'll try to reach someone at
Microsoft who should be able to answer this authoritatively.
Every bride has to learn it's not her wedding but her mother's.
(Get Witty Auto-Generated Signatures from http://SmartBee.org)
George V. Reilly george@...
Your message has been successfully submitted and would be delivered to recipients shortly.