If you are using MFC 6.0 or 7.0 and you want to use MSLU...

by Michael S. Kaplan, published on 2004/11/13 17:28 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/11/13/257048.aspx

If you are using the Microsoft Layer for Unicode on Windows 95/98/Me Systems 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.

# Uwe Keim on 14 Nov 2004 12:03 AM:

What I asked me since a long time: If I DO use the MSLU, is CString then Unicode enabled?

I.e. if I enable MSLU for my project, do the CString functions all use MSLU functions only? Or should I use my own string class to be safe?

# Gregory Faer on 14 Nov 2004 11:13 AM:

Your blog doesn't work well in firefox - the comments disappear when you mouseover. Any chance of updating your style?

# michkap on 14 Nov 2004 11:20 AM:

Sure -- they do not give us many choices, and I do not run FireFox. But I'll try changing and you can let me know if it worked. :)

# michkap on 5 Dec 2004 5:43 AM:

To get unto Uwe's question -- yes. If you compile an application with UNICODE and _UNICODE, then you get a Uniocde CString. If you are running on Win9x then you pretty much must use MSLU in thst case....
Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2005/11/13 Happy Birthday to the blog

go to newer or older post, or back to index or month or day