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

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:

• When calling a user's Unicode WNDPROC/DLGPROC functions that it would convert strings to Unicode, and
• When calling any of the OS functions that it would convert strings out of Unicode.

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:

• when the Win9x would not be expecting Unicode
• when any other component or application that is subclassing or communicating with the app would not be expecting Unicode
• when another application supporting MSLU would be expecting Unicode

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)