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