Date: Sun, 27 Apr 1997 13:05:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: terry@lambert.org, gibbs@plutotech.com, michaelh@cet.co.jp, joa@kuebart.stuttgart.netsurf.de, sysop@mixcom.com, hackers@freebsd.org Subject: Re: VFAT 32 support in msdosfs Message-ID: <199704272005.NAA09155@phaeton.artisoft.com> In-Reply-To: <199704271927.NAA17031@pluto.plutotech.com> from "Justin T. Gibbs" at Apr 27, 97 02:25:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Win95 will also not
> >> automatically convert between UNICODE and ANSI strings when a message
> >> passes between windows that use different string types.
> >
> >Well, neither will NT. It seems to not have the problem because
> >there's very little ANSI in NT.
>
> 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.
FYI: The conversion is done at the INT emulation on the way into the
IFS, at least for path names, etc.. They are cannonized to Unicode,
and something like the LanMan SMB client IFS must convert them again
for the old non-Unicode wire representation of the data.
Conversion sucks. Everyone should go to 16 bit Unicode.
> >> 95% of Office97 uses UNICODE internally, but serious hoops were jumped
> >> through in order to convert strings to DB or ANSI so that it could run
> >> without too many features "losing" after internationalization under
> >> Win95. Why do I know this? Because I had to implement some of these
> >> hoops while working on the PowerPoint97 project.
> >
> >That just the stupid "code page" backward compatability crap, may it
> >rot in hell. If they didn't come out with code that could run on win32s
> >on win 3.1, they wouldn't have to jump through the DB/ANSI hoops.
>
> This has absolutly nothing to do with the problem. You can't talk to
> Win95 in terms of 'W' APIs, so you are either forced to lose UNICODE
> fidelity on both platforms or write code like:
>
> if (underNT) {
> fooBarW(string)
> } else {
> translate string to ANSI using your own routines since the
> routines provided by the system blow
> fooBar(string);
> }
or provide your own fooBarW():
fooBarW(wchar_t *pwstr)
{
translate string to ANSI
fooBar( pstr);
}
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.
If you are smart, you inline it so you don't take the call hit.
> The problem is that the Win32 API does not hide the fact that there
> are non UNICODE apps running in the system which NT makes a good attempt
> of doing. So long as you are unwilling to throw away all non-UNICODE
> apps in a single shot, you must deal with code pages someplace, it
> just shouldn't be done on an app by app basis.
I'm willing. 8-).
At least I'm willing to have them not communicate directly between
themselves, knowing that they aren't interoperable, without some form
of glue server. Yeah, NT provides the glue-serving for you. I guess
you should take Microsoft's hint and develop for NT instead of 95...
at least that's what they seem to be saying.
> >> Win95 is the bane of everyone's existance, including the developers
> >> at Microsoft.
> >
> >Backward compatability is just a fact of Microsoft's life. If they
> >were not married to their bane, they wouldn't have to carry it around.
> >There's no accounting for management stupidity in any company.
>
> It's hard to blaim management for anything when the company they manage
> continually produces record earnings.
It's a financial decision, not a technical one. That was my point.
And I can blame anyone I chose when they engage in intentional
inelegance, then complain about the resulting problems it produces.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704272005.NAA09155>