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


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


Show issues fixed by v. 1.1.3790.0


Hide issues fixed by v. 1.0.4018.0

  1. When MSLU's SHFileOperationW API is called with lpFileOp->wFunc set to FO_DELETE, the lpFileOp->pTo parameter is usually NULL. However, if it is NULL then MSLU will crash. As a workaround, you can set the parameter to L"\0\0" instead.


  2. When MSLU's CompareStringW API is called with the cchCount1 or cchCount2 parameters set to -1, the comparison will only be based on the first character. The workaround is to pass the actual length for comparison. Note that this bug will also affect functions that rely on CompareStringW (such as lstrcmpW and lstrmpiW) but there is no workaround for those functions. This bug is serious enough that there will likely be an update to the DLL in the very near future.


  3. After being properly called with a Unicode FINDMSGSTRING message, the parent window of an MSLU FindTextW or ReplaceTextW call will be called with a non-Unicode FINDMSGSTRING message. You can ignore this second 'shadow' message as it is only a non-Unicode duplicate of the message that the parent was sent just before.

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.