-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...
Improve this question
20
  • 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, 2022 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, 2022 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, 2022 at 23:37
  • 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, 2022 at 14:54
  • 3
    it requires deleting all MFC code and putting in something else
    – user253751
    Oct 31, 2022 at 20:47

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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 1, 2022 at 9: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 1, 2022 at 14:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.