MSLU: reported bugs and known issues
(The Microsoft Layer for Unicode on Windows 95, 98, and Me Systems)
(Originally posted 27 April 2002; last updated 10 December 2004)
By popular request, this page is going to list known issues that are either under investigation or fixed for a future release. Most issues start life being reported
in the microsoft.public.platformsdk.mslayerforunicode newsgroup on the msnews.microsoft.com news server and you can often see discussion about the issues there while
they are under investigation.
If you have any questions about or problems with MSLU, whether or not they are related to issues listed below, you should feel free to ask them in the
mslayerforunicode newsgroup (available via both NNTP and
HTML). You can also come by with
good news, if you want to. :-)
GetLogicalDriveStringsW not properly handling nBufferLength==0 -- this API should support the ability to pass an nBufferLength of 0 in order to get the full size to call the API with. As a workaround, you can simply call it with nBufferLength==1 (which would obviously be too small) and use that to get the size.
FindResourceW and FindResourceExW not accepting string parameters -- the lpName and lpType parameters do not work when they are strings. As a workaround, you can use numeric parameters for them, instead (and use the MAKEINTRESOURCE macro).
CompareStringW is not properly handling when either string is of zero length (an error is returned rather than doing a comparison, an overeager "out of memory" bug fix).
GetOpenFileNameW and GetSaveFileNameW are not updating the nFilterIndex member unless the lpstrCustomFilter member points to a valid string. To workaround, put a valid string in that member.
ModifyMenuW's lpNewItem member is always being treated as a string, even though it may not be one.
OemToCharW and CharToOemW are not null-terminating the converted strings, something that the OS does (although this is not explicitly documented).
SetWindowTextW is not treating a NULL lpString the same way as it treats TEXT(""). As a workaround, you can either use TEXT("") or you can call WM_SETTEXT directly.
SearchPathW randomly fails on CJK platforms.
Several problems have been reported with IMEs not properly allowing characters to be entered -- not on all IMEs, though.
Char[Lower|Upper][Buff] crashing when called several thousand times (exact number varies).
On Windows Me, GetOpenFileNameW and GetSaveFileNameW do not support the Places Bar even if the caller uses the new (5.0) version of the structure.
The Platform SDK mistakenly claimed that the following APIs supported Unicode on all platforms: CryptAcquireContext, CryptSignHash, CryptVerifySignature, CryptSetProvider, CryptSetProviderEx, CryptGetDefaultProvider, CryptEnumProviderTypes, and CryptEnumProviders. In truth, There is no support for the Unicode versions of these functions on Win9x. Stubs will be added to MSLU for the next release, so that people who want to call these APIs can use MSLU and implement these functions as overrides (the Platform SDK documentation bug has also been reported and will also be resolved).
WriteProfileSectionW and WritePrivateProfileSectionW are only using the first string passed in to lpString.
GetPrivateProfileSectionW, GetProfileSectionW, and GetPrivateProfileSectionNamesW are all documented as returning the number of characters copied to the specified buffer, not including the terminating NULL character, but currently the NULL character is being included in the return value.
CreateEnhMetaFileW is not properly handling the lpDescription parameter unless it is NULL.
When dealing with DBCS strings, the GetTextExtentExPointW API will return the lpnFit parameter in bytes rather than charactrers.
This page is obviously not on the Microsoft web site, but it is maintained by an employee of Microsoft who is the principal developer for MSLU. Certain factors
beyond normal control can cause there to be a difference between what you see here and what is eventually released. As they say, this posting is provided "AS IS"
with no warranties, and confers no rights. With that said, best efforts to keep this page accurate will be made any time such a difference does, in fact, exist.
Problems with this site? Please contact the
with your comments, questions, or suggestions.