English - United States  

Home




Usenet Posting #35 - Trigeminal Software, Inc. (English)


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)

Latest release: 1.1.3790.0

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. :-)



Show issues that have been investigated for fix in a future release



Show issues that have been reported and are currently under investigation


Hide issues that are known but are not currently being considered for fix

  • 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).

Show issues fixed by v. 1.1.3790.0


Show issues fixed by v. 1.0.4018.0


Show issues fixed by v. 1.0.4011.0


Show issues fixed by v. 1.0.3703.0


Show issues fixed by v. 1.0.3665.0


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.


Back to Usenet Musings


Problems with this site? Please contact the webmaster@trigeminal.com
with your comments, questions, or suggestions.