Cleaning out the suggestion box a bit

by Michael S. Kaplan, published on 2005/04/28 08:40 -07:00, original URI:

The theme for this post is going to be disappointing people's hopes.... picking out suggestions that do not go along with the probable desires of those asking the questions.

The first question comes from marius mihalca:

Sorry to bother you with this but I found no other way to send you a message. I fallowed all the stept from this article (How to build the 7.1 MFC and the CRT DLLs with MSLU) but my simple VC71 generated application can't display unicode on Windows98 SE.

Everything sims OK except the fact that instead of bulgarin (or greek) language my application displays ? and _ (or other characters). I am positive that unicows.dll is loaded.

I tried to make an simple editbox and tried to paste some unicode text. The editbox shows incorect text.

How can I be sure that my applicatin is using unicows.dll correctly?

Please help.

MSLU is actually behaving as designed here. The Microsoft Layer for Unicode is not, as some people seem to think, a library that provides Unicode support for Win9x. It is, rather, a thin layer over the non-Unicode Win9x that allows one to write a Unicode application. It will still convert those Unicode string parameters from the various Win32 API functions out of Unicode in order to call the underlying operating system. The key is that the Unicode application, when run on an operating system that supports Unicode, will allow one to get full Unicode support.

This design is the very one that Julie Bennett originally envisioned and that Cathy Wissink and I wrote about for MSDN Magazine.

Now there are components that provide a degree of actual Unicode support on Win9x, such as Uniscribe, RichEdit, the Shell Common Controls (version 5.80 and later), and others. But those items do not include MSLU, which is not a rewrite of those 550+ APIs but a wrapper around them. I know this may be disappointing to those who were hoping that it was indeed a Unicode solution of Win9x, but it has never been documented anywhere as such a solution....

On April 13, I heard from AC:

I'm receiving this question from the developers who'd like to have the possibility to make the language customization for the users of Windows 9x/ME which would allow them to later more gracefully upgrade to NT/2K/XP:

- how can they add the additional code page to the Windows 9x/ME?

The goal is to be able to enter unicode characters by typing them. Good enough MS KLC equivalents for Win 9x/ME already exist.

I know that once was probably considered not so good idea to open the specs of Windows 9x/ME .NLS files. But I guess now it shouldn't be such a problem?

Well, the answer to this will also not thrill. There is not going to be any kind of opening up of code pages or other .NLS files on Win9x or elsewhere. In practice, this would not help graceful upgrades but it would delay the time before people did upgrade to a NT/2K/XP by offering an incomplete solution for other languages today, in a way that hurts interoperability.

In the beginning of February, Richard Caruana asked:

Do you know if the following can or will be instituted :

  1. To be able to have a core fontlet/character in the centre which can have overlay accents or diacritics which can be added/overlaid/plyed at run-time in a unicode text editor.
  2. A section for developers in the UNICODE font (~ 1000 character spaces or less if the above idea can be instituted )

Also, do you know where I can download a unicode character search program which if you paste in the character (chinese) it gives you the character code (eg 5CFO) and a definition.

Well, #1 is sort of there now, although it only works well when the font author does the hard work of having all the appropriate code points and attachment points defined.

#2 is sort of there with now, although the private use area of Unicode is only for private use and not for interchange, and I honestly don't see how it could help this situation anyway.

As for the place to get info about Unicode characters, check out the Unicode Character Search (by that will accept both characters and code points. I do not know offhand about downloadable tools, but if you could reach my blog then you can reach that site, I suppose. Right? :-)

Then, back in the end of January, G* asked:

Care to take a break from the wonders of Unicode and elaborate on the pain that is the console codepage 437?

Sorry, no. :-)

I am all about the Unicode thing.

Unless you have something particular in mind beyond what I have talked about in prior posts about encoding issues, like this one?

Ok, that is enough disapointment for one day. I'll try to work harder to meet people's expectations/wishes next time....


This post brought to you by "峰" (U+5cf0, an ideograph meaning "peak, summit; hump of camel" according to the Unihan database)

# Jonathan Payne on Thursday, April 28, 2005 9:33 AM:

Would you be interested in having a go at the question described here:

Basically the MSDN Channel 9 people show a mock Microsoft interview question where they ask the candidate to write a function to detect if a given string is a palindrome. What answer would you have given to this question given your background in Unicode and internationalization?

I suspect the “perfect” solution would be very hard to implement as it would have to take into account so many of the things you have covered (case insensitive comparisons, multiple representations of the same character, ignoring certain character cases and so on).

# Michael S. Kaplan on Thursday, April 28, 2005 10:32 AM:

The thing I would definitely note is that the solutions do not seem to handle combining chars. But I would do something like this for it:

using System;
using System.Text;
using System.Globalization;

namespace Testing
class Palindrome
static void Main(string[] args)
StringInfo si = new StringInfo(args[0]);
int count = si.LengthInTextElements;

if (count == 0)

for (int i = 0; i < ((count % 2 != 0) ? count - 1 : count) / 2; i++)
string st1 = si.SubstringByTextElements(i, 1);
string st2 = si.SubstringByTextElements(count - i - 1, 1);

if (CultureInfo.CurrentCulture.CompareInfo.Compare(st1, st2) != 0)



# Michael S. Kaplan on Thursday, April 28, 2005 11:37 AM:

See for my answer, with formatting that works a little better.

referenced by

2005/04/28 Looking for that internationally savvy palindrome checker....

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