Unicows.dll Removes Unicode

UnicoWS.dll does not Unicode enable your program in Win9x. It does not add Unicode to Win9x (it works by converting Unicode to ANSI, i.e. removing Unicode). However, what unicows.dll does is an extremely useful thing: it allows your new Unicode (wide char) program to "work" on old Win9X/ME machines that don't support the Unicode APIs.

Because of the fog of trepidation surrounding Unicode/charset issues, I think the Microsoft announcement of MSLU made the right choice in not overemphasizing what MSLU, the "Microsoft Layer for Unicode on Windows" (unicows lib and dll), does not do. They let the discerning reader figure it out somewhere down in the article where they say it is "not a panacea" and vaguely spell it out under the second point made there. Hey, you can't start out by shouting what your product does not do just because people might think so.

I have never used unicows, but every time I hear about it people seem to suggest that it gives you Unicode on Win9x, so I take the bait and research into it only to be reminded again of what it actually is. What set me off to write this article was a response to a post on JoS as follows:

Does it make sense to *not* compile for Unicode these days? The old excuse was "Unicode doesn't work on Win9x", but now it does as long as you link in the MSLU library. So why not compile for unicode right off, and just forget that ANSI/MBCS exists? Chris Tavares

If you slightly reworded it 'The old excuse was "Unicode builds don't run on Win9x"' then I would agree, and to be fair that may be what the poster meant. But wherever I hear about unicows it often seems to come across as adding Unicode to Win9x.

On old Win95, 98 and ME boxes, your unicows linked (wide char _UNICODE) program will generally operate in the ANSI locale code page with anything involving Windows messaging and APIs. That means all the filename and directory APIs, text on Windows controls etc. Characters not supported in the system ANSI code page will be lost when they are passed into or retrieved from APIs.

But this is not as bad as it sounds because users generally don't have multilingual expectations on those old machines (not to mention fonts were limited). So MSLU answers the main concern of having a single executable that works on all Win32 platforms.

I can't write an article about unicows and not mention one of my 3 favorite bloggers, Michael Kaplan, who as far as I can tell is the guy behind MSLU (though he gives credit to others) and is a great presence on newsgroups, always humble and helpful (and his site has a section on MSLU). He was also mentioned by Joel Spolsky recently as the guy who helped Joel figure this Unicode thing out (some time ago).

The reason I am sensitive to this unicows issue is that I have worked with Unicode on Win9x. There are a couple of Wide Char APIs that have been available since Windows 95, namely GetTextExtentPoint32W and TextOutW, and I built an edit control that works internally in UTF-8 using these APIs, but that is another story.