Windows 98 and Unicode

[Previous] [Next]

Windows 98 is not a completely new operating system. It has a 16-bit Windows heritage that was not designed to handle Unicode. Adding Unicode support would have been too large a task and was dropped from the product's feature list. For this reason, Windows 98—like its predecessors—does almost everything internally using ANSI strings.

You can still write a Windows application that processes Unicode characters and strings, but it is much harder to use the Windows functions. For example, if you want to call CreateWindowEx and pass it ANSI strings, the call is very fast; no buffers need to be allocated from your process's default heap, and no string conversions need to be done. However, if you want to call CreateWindowEx and pass it Unicode strings, you must explicitly allocate buffers and call functions to perform the conversion from Unicode to ANSI. You can then call CreateWindowEx, passing the ANSI strings. When CreateWindowEx returns, you can free the temporary buffers. This is far less convenient than using Unicode on Windows 2000. I will describe how you can perform these conversions under Windows 98 later in this chapter.

Although it is true that most implementations of Unicode functions do nothing in Windows 98, a few Unicode functions do have useful implementations. These functions are

EnumResourceLanguagesW	GetTextExtentPoint32W
EnumResourceNamesW	GetTextExtentPointW
EnumResourceTypesW	lstrlenW
ExtTextOutW	MessageBoxExW
FindResourceW	MessageBoxW
FindResourceExW	TextOutW
GetCharWidthW	WideCharToMultiByte
GetCommandLineW	MultiByteToWideChar

Unfortunately, many of these functions exhibit all kinds of bugs in Windows 98. Some of them don't work with certain fonts, some of them corrupt the heap, some of them crash printer drivers, and so on. You're going to have to do a lot of testing if you use these. Even then you might not be able to fix the problems—you'll just have to tell your users about them.