How to port an MFC application to Mac OS X
Posted on:June 19 2009
Most of the software I write is Windows only, but there are a lot of people who want it to run on MacOS as well. I ported irrKlang to Mac OS X some time ago, but it's only a software library and not an application, so I didn't have that much experience when I thought it would be a good idea to port the irrfuscator frontend to Mac. Unfortunately, that program was written in MFC, basically a set of classes wrapped around the Win32 API. The irrFuscator frontend looked like this:
And if you know a bit of the internals of the MFC, Microsoft made it really hard to port code using this framework to another operating system. But after some few days, irrFuscator looked like this:
It finally ran and worked on Apple's operating system, yay! So, how did I do that?
Basically, I didn't port the MFC application at all. I stripped out every MFC dependency and replaced it with wxWidgets, a free and open source cross platform UI library. The API of wxWidgets is very similar to the MFC, so this was quite easy, and I was able to port every feature of the frontend to wxWidgets surprisingly without much effort. The result was a code based on wxWidgets which compiles both with gcc/XCode and with Microsofts VisualStudio, which is great: Only one codebase to maintain for bug fixes, new features, etc.
So I can really recommend wxWidgets for crossplatform application development. You can try out both versions of irrfuscator here, if you are interested.
And if you know a bit of the internals of the MFC, Microsoft made it really hard to port code using this framework to another operating system. But after some few days, irrFuscator looked like this:
It finally ran and worked on Apple's operating system, yay! So, how did I do that?
Basically, I didn't port the MFC application at all. I stripped out every MFC dependency and replaced it with wxWidgets, a free and open source cross platform UI library. The API of wxWidgets is very similar to the MFC, so this was quite easy, and I was able to port every feature of the frontend to wxWidgets surprisingly without much effort. The result was a code based on wxWidgets which compiles both with gcc/XCode and with Microsofts VisualStudio, which is great: Only one codebase to maintain for bug fixes, new features, etc.
So I can really recommend wxWidgets for crossplatform application development. You can try out both versions of irrfuscator here, if you are interested.
Comments:
I used to love WxWidgets for cross-platform development, until recently the QT libraries have become LGPL - they have quickly become my favourite framework...
Sickbyte
Quote2009-06-19 19:02:00
Agreed. I've used wxWidgets and Qt, and while wx is nice, Qt is more powerful. While Qt was a choice between GPL or 2K per platform/seat commercial, wxWidgets was my preferred choice (unless a customer was paying for the Qt license :), but now Qt is LGPL I would definitely choose that first.
steve
Quote2009-06-19 20:27:00
I agree 100% with steve, wxWidgets was used because of Qt license. Now QT is the best cross platform and it's free.
The only downside is that it's not a light framework, but who cares those days.
The only downside is that it's not a light framework, but who cares those days.
ASpanishGuy
Quote2009-06-19 23:02:00
Yes, but the wxWidgets license still is a lot better than LGPL, especially if you want to link statically with it.
niko
Quote2009-06-20 11:14:00
I think the license differences are incredibly minor, despite what wxWidgets may have you believe. Static linking is the only genuine difference, but the vast, vast majority of people use Qt with dynamic linking - it's been the default option for binary releases of Qt since forever, and the way that 99% of people use it.
steve
Quote2009-06-20 17:15:00
@steve, But static Linking too has it benefits. "Now you can link OGRE3D statically also under our new modified license", though I personally like this license scheme better. the only problem with LGPL is static linking.
kinjalkishor
Quote2009-06-20 18:44:00
I further agree on the benefits of using wxWdigets, but QT has now become my GUI library of choice since the license change. I have never found the need to use static linking, and in fact like QT using the LGPL, since it forces community members to contribute their patches and improvements. A couple things I like about QT:
Theming - native OS look or customizable. Now supports GTK+ look on Linux, too.
CSS styles - Belongs with theming, but deserves separate mention for its innovativeness.
QtCreator - great IDE for rapid development
Webkit - Extremely useful for a variety of applications. I love being able to expose native QT widgets to the web page.
Don't get me wrong; wxWidgets still has many, many positives, but I feel that QT has even more. One thing I really miss about wxWidgets, however, is the AUI windowing interface. QT has something similar, but it isn't as quite as good. ;-)
Theming - native OS look or customizable. Now supports GTK+ look on Linux, too.
CSS styles - Belongs with theming, but deserves separate mention for its innovativeness.
QtCreator - great IDE for rapid development
Webkit - Extremely useful for a variety of applications. I love being able to expose native QT widgets to the web page.
Don't get me wrong; wxWidgets still has many, many positives, but I feel that QT has even more. One thing I really miss about wxWidgets, however, is the AUI windowing interface. QT has something similar, but it isn't as quite as good. ;-)
irrdev
Quote2009-06-21 12:03:00
niko: Did you do the design of your app with a designer application or by code? Because as I recall wxWidgets does not have a GUI designer for Visual Studio..
MasterGod
Quote2009-06-21 19:51:00
Did it by hand, but wasn't that much effort.. :)
niko
Quote2009-06-22 16:49:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |