Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Apr 1997 14:25:19 -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:  <199704271927.NAA17031@pluto.plutotech.com>
In-Reply-To: Your message of "Sun, 27 Apr 1997 11:49:36 PDT." <199704271849.LAA08885@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> Try almost any foobarW API and it will fail.
>
>Don't use the ones which aren't on both platforms.
>
>> 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.

>> 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);
}

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.

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

>					Regards,
>					Terry Lambert
>					terry@lambert.org
>---
>Any opinions in this posting are my own and not those of my present
>or previous employers.
>

--
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?199704271927.NAA17031>