Date: Sun, 27 Apr 1997 16:18:01 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Terry Lambert <terry@lambert.org> Cc: gibbs@plutotech.com (Justin T. Gibbs), michaelh@cet.co.jp, joa@kuebart.stuttgart.netsurf.de, sysop@mixcom.com, hackers@freebsd.org Subject: Re: VFAT 32 support in msdosfs Message-ID: <199704272119.PAA18708@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 27 Apr 1997 13:05:24 PDT." <199704272005.NAA09155@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Not true. This works just fine. If App A does a CreateWindowW and
>> App B does a CreateWindow, and they exchange messages, the transition
>> is seemless so long as the system code page is setup correctly and
>> both apps are consistent in their usages of 'W' or non 'W' APIs. Otherwise,
>> the UNICODE->ANSI conversion will lose.
>
>Ugh. This is horrifically high overhead. And you wonder why your
>NT programs seem slower. I think doing the conversion in any case
>loses.
Where is the overhead if you are a UNICODE NT app? NT is internally
UNICODE, so if you write your NT app as you're supposed to, there is
no conversion necessary. Office97 runs much faster on an NT system
then on a Win95 one and this is one of the reasons.
>or provide your own fooBarW():
>
>fooBarW(wchar_t *pwstr)
>{
> translate string to ANSI
> fooBar( pstr);
>}
This is a broken implementation as it converts to ANSI on an NT system.
>The nifty thing about doing it this way is that you can then requse the
>code for your next project instead of screwing around again.
PowerPoint isolated all of this crap in it's class implementations.
>I'm willing. 8-).
But you're not a Fortune 500 company that doesn't want to retrain
umpteen thousand employees to use a new application.
--
Justin T. Gibbs
===========================================
FreeBSD: Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704272119.PAA18708>