移植到 Linux，还是为 MFC 编写包装器？
分离程序的核心功能并将其移植到 Linux 更容易，还是围绕 MFC 功能编写包装器以使原始 MFC 程序在 Linux 中运行更容易？
示例：
使用基于对话框的基本 MFC 应用程序（多个对话框窗口），使其在 Linux 命令行下运行，而无需修改核心分析代码。主要目标是不修改分析代码。考虑到这一点，编写程序的命令行版本，该程序使用与 MFC 应用程序用于分析代码的相同文件。编写与分析代码中使用的 MFC 类和函数完全相同的代码。事实上，只需从这些类的 MFC 源代码开始，删除所有 Microsoft 特定的内容（MFC、ATL 等）并将其用于您的包装器代码。
对比：
获取核心分析代码，将其插入到 Qt 命令行项目中。对于任何 MFC 或 Win32 功能，请将其替换为 Qt 或 STL/Boost 中的等效跨平台兼容功能。
Is it easier to separate the core functionality of a program and port it to Linux, or to write wrappers around the MFC functionality to get the original MFC program running in Linux?
Example:
Take your basic dialog based MFC application (several dialog windows), get it to run under Linux command line without modification of the core analysis code. The main goal is to NOT modify the analysis code. With that in mind, write a command line version of the program that uses the same files that the MFC application uses for the analysis code. Write code that will act exactly like the MFC classes and functions that are used in the analysis code. In fact, just start with the MFC source code for those classes, cut out all the Microsoft specific stuff (MFC, ATL, etc..) and use this for your wrapper code.
versus:
Take the core analysis code, plug it into a Qt command line project. For any MFC or Win32 functionality, replace it with the equivalent cross-platform compatible functionality from either Qt or STL/Boost.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试针对 Winelib 编译它，您不必重写大部分功能。
根据您的评论，考虑到时间和资源，我肯定会将源代码分成明确定义的层：
操作系统/平台相关层，
操作系统抽象层，
独立于操作系统的中间件&
UI 层
这是在任何软件应用程序中都会遇到的最基本的分层架构。这样，每当我需要将其移植到新的操作系统/平台时，我只需要编写一个操作系统/平台相关层，而所有其他层都保持不变。同样，当需要更改 UI 框架时，我可以轻松地修改 UI 层，而堆栈的其余部分保持不变。
当然，这样的解决方案需要您可支配的充足时间和资源，但一旦您这样做了，您将来的生活就会轻松得多。
Try compiling it against Winelib and you won't have to rewrite most of the functionality.
In the light of your comments, Given the time and resources I would definitely separate the source code in to well defined layers:
An OS/platform dependent layer,
An OS Abstraction Layer,
An OS independent middleware &
An UI layer
This is the most basic layered architecture one would encounter in any software application. That way Whenever I need to port it to a new Operating system/Platform, I just need to write a
OS/platform dependent layerand all my other layers remain unchanged. Similarly, when need arises to change the UI framework I can easily just modify theUI layerand rest of the stack remains unchanged.Ofcourse, such an solution needs ample time and resources at your disposable but once you do, your life is much easier in future.
如果有足够的时间和资源，我会选择第二种选择，在我看来，这是一种更干净的方法。如果需要快速且肮脏的解决方案，您可以按照@Als 的建议并使用 Winelib。
顺便说一句，Qt 和 STL/Boost 是多平台库，因此将来您可以使用“移植”版本作为多平台版本，将其部署在 Windows 上并摆脱 MFC 依赖（优点：只需一个代码库即可继续工作；缺点：Qt 的依赖性相当大）。
Having enough time and resources I would do the second option, it seems to me a cleaner approach. If a quick&dirty solution is needed, instead, you could follow @Als' suggestion and use Winelib.
By the way, Qt and STL/Boost are multiplatform libraries, so in a future you could use the "ported" version as a multiplatform version, deploying it also on Windows and getting rid of the MFC dependency (advantage: only one code base to work on; disadvantage: Qt is a quite heavy dependency).