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. :-)
On DBCS platforms, functions such as GetGlyphOutlineW
cause MSLU to convert the uChar parameter to call GetGlyphOutlineA
. Unfortunately, it does not properly pack the parameter to represent the multibyte character (as described in the MSKB in Q244046
). This bug also affects GetCharABCWidthsW
, and GetCharWidthFloatW
In the DrawTextW wrapper, MSLU is not recognizing that uiFlags might have other values combined with it and is checking for DST_TEXT and DST_PREFIXTEXT via simple equality. This will cause problems if any of the DSS_* state values are used.
In the GetMonitorInfoW wrapper, MSLU is not properly copying the dwFlags member, which will cause the API to fail if you do not have multiple monitors. A code workaround has been posted in the microsoft.public.platformsdk.mslayerforunicode newsgroup by our new MVP Ted W!
GetOutlineTextMetricsW is designed to return the size of the required buffer when lpOTM is NULL and a non-zero value when it is not and information is copied to it. MSLU, however, is assuming that it will return the size of the returned buffer in the latter case, and it is using that value to decide how much to copy. This causes it to copy nothing, even though the call with lpOTM == NULL succeeds and MSLU's GetOutlineTextMetricsA call when lpOTM != NULL succeeds, too.
When sndPlaySoundW is called with the SND_MEMORY parameter (which means the parameter specified by lpszSoundName points to an image of a waveform sound in memory rather than a filename), the function call fails due to an inappropriate attempt to convert. As a workaround, you can use sndPlaySoundA with no loss of functionality, since there are no Unicode parameters in this scenario anyway.
The GetMenuItemInfoW function sometimes returns ANSI strings rather than Unicode ones. The workaround is to either use the GetMenuItemInfoA function or to use the MSLU GetMenuStringW function, which will work properly here. An error affecting InsertMenuItemW and SetMenuItemW was fixed at the same time (the MENUITEMINFO.cch member was being used to get the string length even though setting it is not required in those APIs).
The WNetGetUniversalNameW API is having the lpLocalPath parameter converted on the way in but is not converting the lpBuffer parameter (containing a UNIVERSAL_NAME_INFOW or REMOTE_NAME_INFOW structure) on the way out.
If the GetProcAddress
function is called when all of the following is true:
- you are using the MSLU loader;
- are running on Win9x;
- UnicoWS.dll is not present;
- the second parameter is an ordinal rather than a string;
- this call happens before you exit due to UnicoWS.dll not being present.
then you will crash. The workaround is of course to make sure that any one of those points is not true (especially the last three!).
Several of the RAS APIs are returning failure erroneously. This is caused by improper structure size checks in different versions of Windows. Affected APIs include RasDialW, RasEnumConnectionsW, RasEnumEntriesW, RasGetEntryDialParamsW, RasGetEntryPropertiesW, and RasSetEntryDialParamsW.
The GetTabbedTextExtentW API is not properly adjusting the nSize parameter on DBCS platforms, which can lead to MSLU passing incorrect nSize value when it calls the GetTabbedTextExtentA API for double-byte strings.
The TabbedTextOutW API has a similar problem with its nCount parameter on DBCS platforms.
The resource updating functions (BeginUpdateResourceW, UpdateResourceW, and EndUpdateResourceW) have had problems with crashing reported in a few different (conflicting) circumstances, most commonly when the bDeleteExistingResources parameter is FALSE.
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.