C++ codebase rewrite from MFC to *nix

I'm interning in a company for the summer and I've to look at different ways of looking at the current codebase (C++,MFC, around 100K lines) and using state machines to model the current program.

I've been reading a couple papers and CPP2XMi looks like it may be some use to try to build sequence diagrams as a start.

The end goal is to gauge the feasibility of moving away from microsoft as an O/S and look at development (possibly in another language) on *nix.

I've also started looking at the MFC dependancies to see if we could just port the current C++ code.

I've had the program running through WINE and performance-wise, it seems acceptable but I still need to investigate other solutions as this will only work on X86 while we have other solutions running running on MIPS and ARM.

Any other ideas or caveats I could look at?

The first thing I would look at is where do I use mfc and other non portable stuff. If the only place there is mfc is in the interface layer for example you then can isolate the work.

If there is no such separation I would look at the fesablity of creating some sections of the code that are isolated and portable. Once you have a base of portability you can begin abstracting all of the services rendered by the non portable code. Any way you slice it though MFC to Nix is a big change and will require a significant amount of work. One other possibility is to see if you can run it under a windows emulator.

From reading through the wxWidgets book, it seems very similar to MFC. You might have a look at it.

I would first look into whether the GUI is separated from the rest of the application. With MFC, this includes limiting use of utility classes like CString to GUI-only code.

If the code is well-factored in this way, the easiest thing to do is probably to leave the MFC GUI code alone, and simply build a new GUI for your other platforms using the native GUI library of choice for each new platform. This will give a proper native appearance and behavior to the application that is really difficult to achieve any other way.

If the application logic is intermixed with the GUI code, it's a good time to ask whether you could devote resources to creating a proper separation, with the goal of doing the above once you've achieved separation. This is risky, from a business standpoint, because it can look like you have made a lot of effort and merely ended up back where you started. It isn't until you start work on the new GUI atop the refactored application that your sponsors see any real progress.

You can also look at portable GUI libraries like wxWidgets and Qt.

I have programmed for both MFC and wxWidgets, and they are conceptually very similar. I have never had to port code from one to the other, but I did once port from Borland's OWL to MFC, which was a similar experience. This sort of thing is not particularly difficult; it's just a grind. I can only recommend doing it when you have multiple reasons for dropping the old GUI library. For instance, perhaps you were also thinking of dropping Visual C++ entirely, or switching from Professional to Express, losing access to MFC. If you were planning on sticking with VC++ Professional (or above), it becomes difficult to justify throwing away your MFC GUI.

I once ported a big COM library from MFC to portable code. I used the STL and boost to replace all the MFC bits. For example, CString => std::string and VARIANT => boost::any.

It took forever, but it was mostly straightforward replacement and tweaking. Fortunately it didn't have any gui code-- it was a data processing library.