On the fuzzier definition of a 'Unicode application' on Win9x....

by Michael S. Kaplan, published on 2006/03/17 03:21 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/03/17/553499.aspx

Riffing on Raymond here, and his post On the fuzzy definition of a "Unicode application"....

The points that his post raises are real ones. And they kind of came up in reverse a few years ago for me when I was explaining how the Microsoft Layer for Unicode on Win9x Systems works.

I was explaining how MSLU worked hard in messaging functions to try to make sure of two things, basically that:

This seemed terribly wasteful, especially for situations where it seemed like a Unicode application could avoid those extra conversions. But in the end, there is really no way to control:

And in the end the same sort of problem comes up, just in reverse.

In the MSLU case, the main point of Raymond's article (which many people missed) is answered easily -- it will always be 0x5c and U+005c for the separator, even in a Unicode application where U+00a5 is entered, due to the problems with the path separator that I have talked about before here.


This post brought to you by "¥" (U+00a5, a.k.a. YEN SIGN)

# Aidan Kehoe on 20 Mar 2006 8:45 AM:

Heh, was that the character of the day on purpose? I'm sure you know that it is unutterably hard to keep the yen sign distinct from the backslash on Japanese machines, since JIS X 0201 is identical to ASCII except for this, and since all the non-Unicode Japanese encodings use JIS X 0201 as their base, not ASCII.

# Michael S. Kaplan on 20 Mar 2006 10:16 AM:

Hi Aidan,

Yes, it definitely was! (See Raymond's post for more on why). :-)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day