In my previous post, I was talking about the feasibility of developing MFC 3.0 applications for deploying on WM 5.0. Though the Win CE operating system (and therefore the Windows Mobile 5.0 operating system) guarantees binary level compatibility, in reality, there will be breaking changes in the operating system especially for security issues which could cause applications to break. We will be exploring issues that could cause MFC 3.0 applications or upgraded MFC 8.0 applications not to work as expected and I want to focus on the operating system changes as well.

Dialog based MFC 3.0 applications with DS_MODALFRAME set do not work on WM 5.0.

There has been a security fix in the Windows CE operating system memory protection routines. The MFC 3.0 libraries assumed that this API would work fine for all conditions – changing a memory mapped page’s access protection from READ to READ_WRITE, but the fix in the operating system for WM 5.0 invalidates this assumption. This particular API is used when the dialog resources are loaded. The API is not used as part of the MFC 8.0 sources and dialog based applications work fine on WM 5.0.

You can see the code in dlgcore.cpp (as part of the MFC sources). Please note that this particular issue will only affect dialogs which have the DS_MODALFRAME bit set. You can take a look at the dialog definition in the resource file to verify that you are not getting affected by this issue. When you deploy the application you will see an access violation when the lpTemplate is accessed to change its state (the last line in the snippet below).

else if (mbiMemory.Protect == PAGE_READONLY)

{

// Mark the dialog template as read-write.

VirtualProtect(lpTemplate, sizeof(DLGTEMPLATE), PAGE_READWRITE, &dwResult);

lpTemplate->style &= ~DS_MODALFRAME;

}

You could remove the DS_MODALFRAME definition from the resource file and rebuild the binary.

If, for some reason, rebuilding the binary is not possible, you can use  

editbin.exe /section:.rsrc,rw <resource binary>

editbin.exe is a tool in VS 2005 which you can use from the VS 2005 Command Prompt. I had a lot of help from the support group and the Win CE team in getting to the root of the problem and the work-around.

That will make the problem go away. This could be used as a post-build step in eVC 4.0 or a pre-build step in the dummy VS 2005 application.