19

I have a rather large MFC based program. I have been tasked to get it running on Linux. I have explained that this will require a re-write of the program either into straight C++ with STL (more work), or into Qt/C++ (less work). I am now told that I need to write wrappers to get every MFC class working in Linux and use preprocessor directives to only compile what is needed in either Linux or Windows. I explained that we are having a communication disconnect and that I believed this to be more work than rewriting the entire project from scratch (which I would not have to do to convert to Qt).

Any good arguments out there to help explain this issue? Am I wrong?

E.Freitas
  • 542
  • 1
  • 4
  • 18
  • 1
    "need to write wrappers to get every MFC class working in Linux"...ehm, what? I would say Qt is the most sensible way to go. – Bart Aug 04 '11 at 17:25
  • 4
    MFC is just a thin wrapper around the Windows API. You'll have to replace every one of those API calls with their equivalent Linux calls. Whoever you're dealing with clearly doesn't know much about programming! – Praetorian Aug 04 '11 at 17:25
  • Is a virtual machine (Linux as hostm windows as guest) out of the question? – Vinicius Kamakura Aug 04 '11 at 17:49
  • @Praetorian: Hardly, you rather map the MFC classes to the equivalents in some other framework/class library - or use WINE or Winelib, not implement the whole API! – Clifford Aug 04 '11 at 22:16
  • 1
    @Clifford : You haven't seen idiomatic MFC code. That very much assumes that a `CDC` is just an `HDC`. Things go downhill rapidly when you're running on a system that just doesn't have an `HDC`. – MSalters Aug 05 '11 at 13:05
  • 2
    Curious how the story ended. – macetw Jun 14 '16 at 20:15
  • @macetw I'm too curious how you proceed. – Arun Pal Feb 12 '19 at 11:18

3 Answers3

15

If you don't want a full rewrite, you could try compiling against Winelib. Most things should just work and then since you have the source, you can work around the parts that don't.

Brendan Long
  • 53,280
  • 21
  • 146
  • 188
  • Would it make sense to try to run it under Wine without any sort of recompilation first? – mattr- Aug 04 '11 at 17:27
  • @Matt Rogers: If you want to gradually rewrite parts of it for Linux, Winelib is obviously a better option. – ninjalj Aug 04 '11 at 17:29
  • @Matt Rogers - Definitely worth a try. – Brendan Long Aug 04 '11 at 17:32
  • ninjalj: Agreed, but if we're just talking about getting it running, it seems like a first step would be to try it under Wine. – mattr- Aug 04 '11 at 17:33
  • 7
    Winlib does not implement MFC; you would have to compile the MFC source on Linux against Winelib, which is legally dubious. See http://www.winehq.org/docs/winelib-guide/mfc for details. Just running it on WINE without recompilation is far less problematic. – Clifford Aug 05 '11 at 17:24
  • Link: 404 Not Found ... Again. :( – macetw Jun 14 '16 at 20:14
  • Does anyone tried wine for migration from windows to linux , Also if yes does wine affect performance ? – Arun Pal Feb 12 '19 at 11:19
7

The obvious solution is to run the code unchanged and un-recompiled on WINE.

A simple (kludgy) solution is to run an entire Windows VM on the Linux system, and deploy the application as a virtual hard-drive, but that will require a Windows license and is little different than simply connecting a Windows system to a Linux network.

If you must re-write, wxWidgets would be more familiar to an MFC developer than Qt perhaps.

Here is an article on porting MFC apps to Linux that considers the use GTK+, Qt and wxWidgets. It also discusses why you should consider and try WINE before any of those options. The author talks about future articles on the subject, but appears to have written nothing further since 2004.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • +1, I was going to suggest wxWidgets too except that the OP seems settled on Qt. – Mark Ransom Aug 04 '11 at 17:42
  • I am familiar with Qt, not so much with wxWidgets. That's pretty much the only reason. – E.Freitas Aug 04 '11 at 18:01
  • @E Freitas: Familiarity is fine, but to port the code you will also have ot become familiar with MFC - just to understand it. wxWidgets is very similar to MFC so some porting is a matter of direct replacement of class names. See http://wiki.wxwidgets.org/WxWidgets_For_MFC_Programmers for details; it even provides a sed script for performing a large number of the necessary substitutions which may give you a headstart in your port. The Qt framework on thw other hand is architecturally more different. – Clifford Aug 04 '11 at 22:02
4

The sources for MFC and ATL total to over 500000 lines of code, and most of the functionality of this code is actually provided by the Windows API itself. How many lines of code can you write in a day? The scale of what you are being asked to do is simply impractical, even if you're only implementing a small subset of MFC.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • Yes, I imagines somewhere on the order of a decade or more of work, and all that without any QA department. :) – E.Freitas Aug 04 '11 at 18:02
  • 4
    The task is not as big as you suggest, because the task is not what you suggest. It is certainly not to rewrite 500000 lines of code, but simply to map the classes and function calls from one framework/OS to the near or exact equivlalents in another, and perhaps modifying the architecture to match a different framework and messageing architecture. Hardly impractical, just hard work. – Clifford Aug 04 '11 at 22:07
  • 1
    @Clifford, I picked the source of MFC because it "maps" the MFC architecture to the Windows API. Since another API will be less of a direct match I would expect it to be harder still. Another base of comparison would be the wxWidgets library, but I don't have those sources easily available at the moment. – Mark Ransom Aug 04 '11 at 22:39
  • @Clifford: wxWidgets is about two millions LOC. (https://www.ohloh.net/p/wxwidgets/analyses/latest) So you're looking at a fourfold increase of code for a non-exact match; perhaps you should double that again for a drop-in MFC replacement. – MSalters Aug 05 '11 at 13:09
  • @MSalters: I do not see your point, it is not as if you have to write all that code again - who cares how much code it is? – Clifford Aug 05 '11 at 17:05
  • 1
    @Mark: Are you then suggesting recompiling the MFC source on Linux? Does Microsoft's license permit that? Either way that has already been done against Winelib http://www.winehq.org/docs/winelib-guide/mfc. Yes mapping MFC interfaces to a non Win32 API would be hard, but that is hardly a sensible approach. Mapping the probably small *subset* MFC interfaces used an any single application to a *similar* class library/framework such as wxWidgets would be entirely feasible, and as I mentioned in another comment, partially automatable. – Clifford Aug 05 '11 at 17:09
  • @Clifford, read the original question again - that's *exactly* what the questioner was asked to do, write all that code again rather than using an existing library (Qt was proposed and rejected). – Mark Ransom Aug 05 '11 at 17:10
  • @Clifford, no I'm not suggesting compiling MFC for Linux. I'm just suggesting what the scope of the task "write wrappers to get every MFC class working in Linux" would be, in answer to "good arguments out there to help explain this issue". – Mark Ransom Aug 05 '11 at 17:15
  • @Mark: That is one way of interpreting it. That may even be what he was asked to do; it is most probably not what is needed or even intended. A naive, literal interpretation of stated requirements is hardly ever productive and more obstructive. I refer you to: http://blog.thingsdesigner.com/uploads/id/tree_swing_development_requirements.jpg – Clifford Aug 05 '11 at 17:17
  • @Mark: I see what you mean. I would interpret "write wrappers to get every MFC class working in Linux" as writing mapping to something similar available on Linux. However you are right "every MFC class" is a bit of an ask and probably pointless - only the subset of interfaces actually used in the application need be implemented. A better solution however remains to port the application directly to a cross-platform framework and discard the MFC code completely, since the result can be re-compiled for either platform. – Clifford Aug 05 '11 at 17:21