|
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. :-)
The latest Platform SDK contains a UnicoWS.lib file that was build using the VC++ 7.0 compiler, and the format is not 100% compatible with the linker in VC++ 6.0. In order to use the .LIB file, you need to either not use the /DEBUG flag or use VC++ 7.0. This problem will be addressed in the next PSDK update.
On a Windows 95 system with no net installed, no mpr.dll is on the system. This will cause a LoadLibrary() of unicows.dll to fail since it cannot bind to any of the WNet* functions that MSLU needs. The easy workaround is to just install the net on the target Win95 machine -- I have not seen such a machine in years and can't imagine that such machines are installing new software....
If you have a RichEdit control supporting Unicode (using the RichEd20W class name) and you attempt to use the GetWindowTextW API or the WM_GETTEXT message to retrieve the text it contains, the text will be garbled. A fix is not currently under consideration because the EM_GETTEXTEX message is available and will work properly, and it will not convert the text via the default system codepage the way that MSLU would for WM_GETTEXT or GetWindowTextW.
When MSLU's BeginUpdateResourceW and BeginUpdateResourceA APIs are called on binaries with no resources with the bDeleteExistingResources parameter set to FALSE, MSLU's call to LoadLibraryExA with the LOAD_LIBRARY_AS_DATAFILE flag to enumerate existing resources will fail and GetLastError() will return ERROR_BAD_FORMAT. This is a limitation of the Win9x function and there is no workaround for this, other than to simply pass TRUE when there are no resources in the binary upon which you plan to call the resource updating functions (since MSLU cannot afford to risk calling without LOAD_LIBRARY_AS_DATAFILE and causing code to run).
MSLU's RegEnumValueW and RegEnumKeyExW APIs are documented as returning the size of the value/key names without the trailing NULL, but they are including the trailing NULL in the count. As a workaround, you can take advantage of the fact these strings are NULL-terminated to get the actual length.
There is a typo in the spelling of a function name in the MSLU loader which causes the loader to be unable to find the mmioOpenW function. The code in the DLL is fine, so as a workaround you can use GetProcAddress(GetModuleHandleA("unicows.dll"), "mmioOpenW") to get a function pointer to call. MSLU will properly forward the call to the OS when you are not on a Win9x platform.
MSLU's RealGetWindowClassW is erroneously trying to call the RealGetWindowClassA API on Win9x platforms; it should be looking for RealGetWindowClass (without the 'A' suffix, the only function that is exported on Win9x platforms). As a workaround, you can temporarily use a loader override for MSLU's function.
There are several reported problems with the FindTextW/ReplaceTextW APIs, the causes of which are understood and are now being addressed.
MSLU's GetOpenFileNameW and GetSaveFileNameW are not copying the lpstrFilter member of the OPENFILENAME struct in the two notifications ( OFNHookProc and OFNHookProcOldStyle). The value is set properly on return, though. As a workaround, you can simply remember what the lpstrFilter was when the dialog was initialized. There are problems with both ChangeDisplaySettingsW and ChangeDisplaySettingsExW related to NULL parameters being passed. The workaround is to not pass NULL.
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
webmaster@trigeminal.com
with your comments, questions, or suggestions.
|
|
