English - United States  


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

Subject: If you are using MFC 6.0 or 7.0 and you want to use MSLU...
(Originally posted 01 May 2001, updated 03 Jan 2003)

If you are using the Microsoft Layer for Unicode on Windows 95/98/Me Systems (MSLU) and the Microsoft Foundation Classes (MFC), there are a few things you need to know about!

There are two bugs in MFC 6.0 that you will have to fix and rebuild (both bugs are fixed in MFC 7.0). One only applies to people compiling their own private MFC DLL, and the other applies to all MFC usage. In addition, there is a third problem if you are using the MFC DLLs that requires you to rebuild the C runtime (CRT) as well (applies to both 6.0 and 7.0).

  1. AFFECTS both STATIC MFC and private DLL: If you look in CEditView (inside of viewedit.cpp) there are three member functions that contain code that does an #ifndef _UNICODE in them: they are CEditView::ReadFromArchive, CEditView::LockBuffer, and CEditView::UnlockBuffer. You should remove the #ifndefs (but leave the code within them!). They were making an assumption that you could never be running a Unicode MFC on Win9x (but of course, it turns out they are wrong, given the existence of MSLU!).

  2. AFFECTS THE CUSTOM MFC DLL CASE ONLY: If you look in the RawDllMain function in dllinit.cpp, they have some more code, this time wrapped in #ifdef _UNICODE. It will cause the MFC DLL to fail anytime you try to use it on Win9x. You should remove this block of code too, and then rebuild the MFC DLL as per the info in TN033 (making sure you have it use MSLU when you build it, of course!).

  3. IF YOU ARE REBUILDING THE MFC DLL: Unfortunately, you will also have to rebuild the CRT dll (msvcrt.dll) as well, due to the use of several CRT functions that rely on Unicode APIs, when called by the Unicode MFC. This is true in both 6.0 and 7.0.

There is one additional problem that can occur if you are using AfxWndProc (MFC's main, shared window proc wrapper) as an actual wndproc in any of your windows. You see, MFC has code in it so that if AfxWndProc is called and is told that the wndproc to follow up with is AfxWndProc, it notices that it is being asked to call itself and forwards for DefWindowProc instead.

Unfortunately, MSLU breaks this code by having its own proc be the one that shows up. MFC has no way of detecting this case so it calls the MSLU proc which calls AfxWndProc which calls the MSLU proc, etc., until the stack overflows. By using either DefWindowProc or your own proc yourself, you avoid the stack overflow.


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