Why use MFC on Windows CE?

Last week at MEDC in Las Vegas I presented a lab on application development for Windows CE using the Microsoft Foundation Classes (MFC). The common theme of questions after the session were around support for MFC and end of life for MFC, many people attending the session believed that MFC is a dead technology and has been replaced with .NET and managed application development - I can certainly see why that may appear to be the case given the amount of marketing effort around .NET technologies. The reality is that MFC is alive and well and has been completely overhauled for the Visual Studio 2005 release (MFC is now shipping as MFC version 8 in VS 2005 for the desktop and for Windows CE).

So why might you use MFC for application development? Perhaps there are a number of reasons.

1. Size - The MFC runtimes are smaller than the .NET Framework/Compact Framework libraries, about 800kb for the MFC80U.DLL compared with approximately 10MB for the .NET Compact Framework

2. Real-Time - It's possible to write real-time application code in MFC - Since MFC based applications are written in "native code" (C/C++) you are responsible for the lifetime of objects (and handles) you create in your application - Note that this may also be a down side to native/MFC application development since it's easier to leak memory/handles/objects in a native code application.

3. Abstraction - Programming against the Win32 API can be difficult, some APIs take parameters and return a value, some take structures, some return HRESULTS - MFC hides much of this from you, and also (interestingly) has some useful classes such as CString which hide the complexities of Unicode/ASCII programming.

4. Tools Support - Programming using Win32 means that your applications typically have a large switch statement which has a number of WM_ message handlers, adding support for handlers is a manual process, MFC has some useful tools support in Visual Studio for adding Windows Message handlers, and MFC function handlers.

Some time ago I wrote a sample for a conference I was presenting at, this was a "Scribble" application, this is a simple application that tracks mouse down, mouse move, and mouse up - while the mouse is down the application captures the mouse movements into some kind of array and then draws the points when the client area needs to be refreshed.

Writing the application in Win32 means that you need to do everything for yourself, there's no direct support for linked lists or arrays, serialization of content to/from file isn't straight forward - when I first wrote the Win32 application it took about two hours to get working (I had a bug in my linked list code that took a while to figure out).

Writing the same application in MFC took about 20 minutes - and writing the same application in managed code took about 10 minutes.

It would appear that there is still a place for MFC application development in the embedded devices world.

I'd be interested in your comments/feedback.

- Mike

Comments

• Anonymous
  May 08, 2007

1. While 800 KB is certainly significantly smaller than 10 MB, 800 KB is often too large for embedded devices. Thus, I generally need to work at the Win32 API level.
2. Nothing to add.
3. That abstraction is often realized in very noticeable bloat. Also, wasn't CString merged with ATL? You should be able to import it without incurring a hit on the MFC libraries. Note that C++ includes standard libraries for strings and various data structures. Unless required, you should not reinvent the wheel.
4. Use the HANDLE_MSG macro. While I love VS, it is a crutch. Most of that tool support is not available outside of VS. When possible, I will happily go for .Net, but when necessary I will target Win32 API. While I have tried MFC many times, the advantages generally do not overcome the disadvantages. In my experience, MFC has almost no place in either desktop or embedded development.

• Anonymous
  May 08, 2007
  Is MFC support SOAP feature? (in windows mobile 5) When I was doing my project with MFC, I couldn't use SOAP in MFC. (vs2005 printed out "do not support DCOM" in warning messages). But .NET managed code can do that.

• Anonymous
  May 08, 2007
  Why not use WTL on Window CE?Actully it was smaller than MFC based application, and WTL almost has same class interfoce.

• Anonymous
  May 08, 2007
  Though many developer use MFC to write their applications,but the "MFC" was moved out of the CE 6.0 Catalog-View. Does it mean that we shouldn't use MFC for the CE 6.0 ?

• Anonymous
  May 09, 2007
  hitting some of the questions/comments above... MFC source/DLLs don't ship with the CE 6.0 product, they ship with VS 2005, you can find the binaries for MFC (for each processor) here - C:Program FilesMicrosoft Visual Studio 8VCceDll You absolutely could use WTL - the point of this post is to show that MFC is still an option for Windows CE developers - the feedback I got at MEDC was that MFC was dead, and that really isn't the case. MFC is just a thin wrapper over the Win32 APIs, you are not constrained to only use the MFC classes/APIs - if an API (such as SOAP) is supported on the underlying platform then you simply add the appropriate library to your project and call the APIs. I agree that even 800kb could be too large for some projects, but MFC is an option that you can use for your projects if you think its appropriate.

• Mike

• Anonymous
  May 09, 2007
  I prefer WTL, for MFC does not support Windows Smart Phone Edition at least before WM2003.

• Anonymous
  May 09, 2007
  Have developed a number of embedded industrial applications and find that MFC gives a good compromise between the WIN32 API and .NET Compact when developing screen based applications on smaller footprint environments.  .NET introduces a number of issues that MFC addresses readily such as message posting and driver interfacing. The availability of the raw WIN32 API with MFC is a big bonus in these situations.  Our platforms are heavily customised to the hardware peripheral set and as such efficient driver access including IOCTL access is very important.

• Anonymous
  May 10, 2007
  For what it is worth, we see 20% of the embedded applications currently going .NET, the rest Win32 and MFC.  From my POV that is VERY rapid uptake for a API in the embedded space.   Embedded systems are where software typicaly goes to die- DOS, ADA, Smalltalk, OS-2, POSIX are all active in the embedded space. POSIX, is of course, the API of the future, has been for twenty years, and will be for twenty years more;-) Lawrence Ricci www.EmbeddedINsider.com

• Anonymous
  May 10, 2007
  I just finished a VoIP project based on MFC. I have to interface tons of native code and thus have no intention using .NET. Generally, I think .NET or other virtual machine for that matter is a bad choice for embedded. I have already rewritten a few application from C# to MFC due to performance issues. The only reason to use .NET CF is when your server side is a web service and you want SOAP interface.

• Anonymous
  May 11, 2007
  When I do training to developers here in Italy I usually say that MFC is like FIAT Multipla (a link to the new model http://www.yousee2.net/multipla/images/20040809_0.jpg and to the one of the 50' http://images.google.it/imgres?imgurl=http://www.supanet.com/media/00/09/44/multipla_430.jpg&imgrefurl=http://www.supanet.com/access/index/motoring/car_gallery/gallery/304/1/&h=300&w=430&sz=18&hl=oc&start=5&tbnid=dgVhdxLOIeAnXM:&tbnh=88&tbnw=126&prev=/images%3Fq%3DFIAT%2Bmultipla%26gbv%3D2%26svnum%3D10%26hl%3Doc%26sa%3DG). For non Italian/European people, the multipla is a minivan with a very strange but functional design. Usually people love the multipla (as I do) or hate it for it's goofy look. There's no way in between :) It's more or less the same with MFC, IMHO. Some people (and I'm one of them) don't like its architecture (the document/view model), don't like the fact that sometime it "hides" some aspects of the API, don't like it's limited use of C++ language advanced features like templates and consider its "monolithic" approach a bit to heavvy for small applications (800Kb aren't a huge footprint for a complex application but are a very bad thing when you discover that someone inside a development team decided to use MFC for a small utility, forcing you to add 800Kb to your image). Other people like its architecture, like its integration with the IDE and its wizards, like its way of hiding some of the complexity of the APIs and its respect for backward compatibility that allows and easy porting of old legacy code (even win 3.11!) to new platforms. I prefer to use ATL/WTL and, after CF 2.0, developing COM objects (another technology that in someone opinion is dying quickly...) to handle the real-time part or performance critical parts of the application and using c# for the UI. I think that MFC has a large community supporting it and even if ms will drop it in the future it will be mantained as an open source/collaborative project.

• Anonymous
  May 12, 2007
  The comment has been removed

• Anonymous
  May 13, 2007
  I agree about the risks of the double approach. I think that to use MFC (or ATL/WTL and even the framework) you should still have a basic knowledge of the underlying OS. I mean that you should understand, at least, how a message loop works, synchronization and multi-threading and other low-level stuff. Sometimes i found people surprised when they put a 1 zillion iterations loop inside their OnButton function and their application windows does not refresh (and "that silly Windows XP pretends that my application is not responding!"). Sometimes here i Italy I found some books (most of the times badly translated from English) about "Visual C" that explain only MFC and wizards-based development without wasting even a paragraph for those boring APIs. The time you save by skipping that part will be wasted in hours and hours of clueless debugging, IMHO.

• Anonymous
  May 15, 2007

1. MFC has a smaller runtime library, but .net does a lot more.
2. You can use C# for the UI and C++ for the core functionality
3. Except for messages routing, the wrappers are just thin layers See http://home.pacbell.net/ouster/scriptextra.html to know what is available for Tcl (there is a version of Tcl running on CE)
4. .net have a much better tools support C++ is a great language for the backend, but a terrible one for the UI. This applies also to almost all C++ UI libraries: MFC, WTL, wxWidgets, ...

• Anonymous
  May 15, 2007
  The comment has been removed

• Anonymous
  May 16, 2007
  What can you say about the Forms implementation in Delphi? I'm talking more about Delphi 6/7. You get an EXE with very easy to write code and you can go to Win32 at any time. No libraries required. Mike: i'd love to hear your opinion on that. I know they don't have support for embedded, but when will we see that in Visual Studio? Then i'll be sold for it.

• Anonymous
  May 17, 2007
  MFC development does support forms based development similar to the forms based development in .NET, take a look at CFormView - This gives you a dialog 'canvas' for you to drop controls onto and then you "code behind" the controls. The application is still based on MFC, so you still need to either statically link or dynamically link into MFC.

• Mike

• Anonymous
  May 25, 2007
  ---------- Forwarded message ----------From: Checko <checko@gmail.com>Date: May 18, 2007 11:29 PMSubject: [Real Checko's Blog] MFC in CE 6.0To: checko@gmail.com在CE 6.0 的Catalog-View中已經看不到 MFC 了。在 Windows Embedded Blog 中，卻還有人提倡在 6.0 中使用 MFC。..