Cross-platform Windows / OS X Development, with a large existing code base

There is a large existing code base for a complex application written in C ++ using MFC and WinAPI, which must be ported to Mac OS X. The ideal solution is to have as much code as possible between different platforms, especially code such as business logics. The GUI may vary depending on how good the cross-platform GUI tools are. There are several low-level OS calls that will vary across platforms. The main goal is not to end up with two separate software versions that need to be developed and maintained separately.

I looked at Qt, but I would be interested to know what other alternatives exist, and how people solved this problem in the past.

  • If you are going to migrate an existing application written in MFC, what would you use / how would you do it?
  • If you can start a project from scratch on both platforms, what would you use / how would you do it?
+7
source share
3 answers

We should have made a similar decision a couple of years ago and decided to go with Qt. The application was a combination of Windows Forms / Managed C ++ (we did not have a cross-platform requirement), we evaluated some sets of ui, there we also examined Java.

If you are familiar with MFC, you may find WxWidgets more โ€œcomfortable,โ€ I would suggest that the structure of the object is closer to this. This is actually what made us not use it. The Qt design is very well thought out and better suited to what we do. Java was discarded as an option, as we actually did not have much knowledge in the house.

Starting from scratch, I would choose Qt again (even with some things going on with Nokia). I still like the toolbox. Options that I might think that we did not consider when we made our first assessment (due to the availability and limitations of the project) of Mono, Adobe Air or just a web application.

+6
source

โ€ข If you were to migrate an existing application written in MFC, what would you use / how would you do it?

I would use wxWidgets . It has excellent documentation, supports multiple platforms, and has been around for some time. As for part of your question ... I would replace all MFC / Win32 calls with wxWidget calls. This simplifies things, but essentially this is what needs to happen in order to get a true multi-platform opportunity.

โ€ข If you could start a project from scratch on both platforms, what would you use / how would you do it?

I would still use wxWidgets because I am familiar with it. Qt is a terrific structure, very capable and has a large user base (fortune telling).

I understand that there are other structures, but Qt and wxWidgets seem to be the leaders of the cross-platform platform. I do not think that you can go wrong with the choice.

EDIT: This answer was influenced by my personal experience in porting a large MFC application written in Visual C ++ 6 to use wxWidgets to work on Linux.

+3
source

I would stick with a native graphical interface for any platform. To do this, it is necessary to divide the presentation layer into two sublayers: (1) the actual implementation, which uses specific types of widgets / controls and (2) the level of presentation abstraction. This way you get the look on every platform using the same presentation logic.

By the way, you can do it evenly even in managed code, assuming that MonoMac really works as promised (I didnโ€™t try it, itโ€™s not the will and need to follow Mac-Mania). That way, you can have completely clean CLR-enabled code for your abstract presentation with bindings to WPF on Windows and the corresponding CLR-AppKit shells on Mac.

+2
source

All Articles