-1

I'm planning to port or rewrite an MFC GUI C++ app, to use in a GNU/Linux environment, and hopefully make it cross-platform. The app has few, if any, dependencies other than MFC and the standard C++ library.

The thing is, I have very little experience in GUI app programming, and in programming for Windows.

My question: What does "de-MFC'ing" an application typically consist of? On the lowest level, every piece of code depending on MFC headers needs to be replaced with alternative code or an alternative dependency or both, but I would like a higher-level sketch of what the challenges and the kinds of effort required.

Notes:

  • I intentionally haven't described the application, to focus the question on de-MFC'ing as a process.
  • In case it matters - I have significant C++ experience, just not with MFC and Windows.
  • Assume the app is "MFC-heavy", i.e. its reliance on MFC isn't just for the GUI, it goes all in on what MFC offers. But no other libraries (or rather, you can ignore anything else).
  • The GUI aspect is important...
einpoklum
  • 2,478
  • 1
  • 13
  • 30
  • 4
    Honestly, this depends so much on the structure of the app. If it is already well separated into layers, you can possibly just pull out the layers containing the business logic and stick a new GUI of your choice on top. If there's no good separation and MFC classes reach right down through the code, you've got a much bigger job on your hands. – Philip Kendall Oct 30 '22 at 21:49
  • 9
    One big question is which UI toolkit are you going to replace the MFC with. This is not a trivial question, and will likely shape a lot of the follow on decisions. – user1937198 Oct 30 '22 at 22:36
  • @user1937198: That's definitely a big question. I was assuming someone would write about the choice between a "narrow" GUI toolkit and something more frameworky like Qt. – einpoklum Oct 30 '22 at 23:37
  • @PhilipKendall: See edit. – einpoklum Oct 30 '22 at 23:38
  • *"I intentionally haven't described the application, to focus the question on de-MFC'ing as a process."* - replacing MFC in an application is **all** about the application, its size, its structure, and its usage of the MFC, so the whole question is based on the wrong assumptions of the existence of a "simple" approach. – Doc Brown Oct 31 '22 at 06:23
  • FWIW, here is what I would do: if the application is larger than 50K lines of code, I would usually shorten the evaluation process for an UI framework and simply choose Qt, and then google for "port MFC to Qt" (compare the results you get with "port MFC to ", if you like. – Doc Brown Oct 31 '22 at 06:46
  • @DocBrown: The question makes no assumption of there being a "simple" approach. If you asked me the same question about, say, de-Boostification, I could give you a general answer (though not a complete one since I'm not that much of an expert). Anyway, your comment about Qt should be an answer, albeit not a complete one. If you could provide the rationale for it as well - in an answer - that would help me make at least that decision. – einpoklum Oct 31 '22 at 07:59
  • @einpoklum: at least you are assuming this answer can be sensibly answered without knowing more about the specific application. And my rationale is simple: choosing the "market leader" for cross-platform C++ GUI frameworks is usually the least risky and most "future proof" approach. But Qt should be surely powerful enough for replacing all MFC standard features. Backside is, Qt needs to fit into your budget - and without knowing more about the application, I cannot tell you if it is completly oversized for your purpose, or maybe lacks some "non-standard things" important to you. – Doc Brown Oct 31 '22 at 09:54
  • ... also, this all makes this more like a "tool recommendation" question in disguise, and you surely know that these questions are off-topic here, – Doc Brown Oct 31 '22 at 09:56
  • See also on Reddit: https://www.reddit.com/r/cpp_questions/comments/cbf2hq/what_gui_library_to_use_to_replace_mfc_in_a_huge/ – Doc Brown Oct 31 '22 at 10:16
  • @DocBrown: So, the question is about what are the broad categories of "MFC standard features" which need to be replaced, and what does replacing them entail: A specific library, a different library per platform, refactoring of various aspects of the code, etc. I am not asking for a tool recommendation. – einpoklum Oct 31 '22 at 10:20
  • @DocBrown: That question is indeed about recommending a specific GUI library. That's not what I asked. – einpoklum Oct 31 '22 at 10:22
  • @einpoklum: no, you *thought* you were not asking for a tool recommendation, but actually, which new UI framework to pick is what you have to clarify first and foremost. – Doc Brown Oct 31 '22 at 11:49
  • 2
    @einpoklum But now consider de-Javascriptification. There is no general process, besides "write it again, but without MFC" or "split it up into parts, then write each part again, but without MFC" – user253751 Oct 31 '22 at 14:54
  • @user253751: What is "de-Javascriptification"? You mean, of websites? You could definitely characterize that in broad strokes. Talk about utilizing HTML features to the max; dynamic capabilities of CSS using element states and context; page design paradigms and the static counterparts of various dynamic ones; use of server-side execution; etc. – einpoklum Oct 31 '22 at 20:31
  • @einpoklum Let's say, taking a Javascript+HTML phone app, and removing the Javascript and HTML. – user253751 Oct 31 '22 at 20:31
  • @user253751: Not a relevant (or meaningful) example. Taking an app and removing the programming language code means it's not an app. – einpoklum Oct 31 '22 at 20:34
  • @einpoklum It's relevant. You take this JS+HTML app and you have to come up with an android app with no JS or HTML in it. How do you do it? Complete rewrite - that's how – user253751 Oct 31 '22 at 20:35
  • @user253751: Yeah, so, de-MFC'ing an app does not require a complete rewrite, and certainly not deleting all C++ code and putting in something else. – einpoklum Oct 31 '22 at 20:45
  • 3
    it requires deleting all MFC code and putting in something else – user253751 Oct 31 '22 at 20:47

1 Answers1

2

Done that, in different directions.

You want to have your app, with additional header files, and some source files implementing the same functionality for windows and Linux (where the code needs to be different).

Move your code, as it is, to a different build machine (Linux in your case) and try to build it. Then you go to your very first file with errors and fix them. For example, if the compiler complains about “#include <windows.h>” you add a file gui.h, include it, and fill it with declarations as needed.

Done that, first day I had about 4,400 errors (because the compiler stopped at 100 errors in a file). Some months later the app built.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • 2
    The main point IMO is that there is no magic trick or secret recipe but weeks or months of hard work. There isn't even a magic trick or secret recipe to reliably minimize those weeks or months of hard work. Start the hard work, solve specific problems as they surface, don't get distracted in fruitless design deliberations. – Hans-Martin Mosner Nov 01 '22 at 09:19
  • One thing that may help is to rewrite some of the MFC classes yourself so you don't have to change the code that uses them. E.g. MFC has a CString class, so just write a wrapper based on std::string and now you don't have to worry about changing CString to std::string any time soon. – user253751 Nov 01 '22 at 14:57