At 11:10 AM 11/14/2004, John Maddock wrote:
Damn! I always forget about Win 9x; I moved the NT at the first beta and never looked back.
So what happens in Win 9x when you use the wide API?
It probably won't load the executable, or else just return a failure code, however there is something called the Microsoft Layer for Unicode that adds limited Unicode support to Win95/98/ME, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winpro g/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp.
I've been assuming Microsoft's Layer for Unicode, and was assuming that Peter meant there were serious problems even if it was enabled. Maybe there are some serious problems but it looks to me that we only need WideCharToMultiByte, MultiByteToWideChar, AreFileApisANSI, and the wide file management functions to work as documented. We don't care about problems in the other portions of the API.
If we insist that programs use this when run on these platforms (which let's be honest are all legacy systems now), then we can use wchar_t as the internal native character type and let Microsoft's own libraries take care of code pages and translations. Presumably if they haven't got this code
correct then no one will :-)
I reread the Microsoft docs last night and came to the same conclusion you do. (As I have every time I've read them). I'm going to do a prototype implementation on the assumption that we can use wchar_t as the internal native character type for Windows, and char for POSIX. If someone can provide a breaking test case, we will look at it and see how serious it is. Thanks, --Beman