将程序的核心功能分开并将其移植到Linux，或者围绕MFC功能编写包装以获得在Linux中运行的原始MFC程序更容易吗？端口到Linux，或为MFC写封装？
例子：
把你的基本的基于对话框的MFC应用程序（几个对话窗口），得到它没有核心分析代码修改Linux命令行下运行。主要目标是不修改分析代码。考虑到这一点，编写一个使用MFC应用程序用于分析代码的相同文件的程序的命令行版本。编写与代码中使用的MFC类和函数完全相同的代码。实际上，只需从这些类的MFC源代码开始，删除所有Microsoft特定的东西（MFC，ATL等），并将其用于包装代码。
与：
取岩心分析代码，将其插入Qt的命令行项目。对于任何MFC或Win32功能，请将其替换为Qt或STL/Boost的等效跨平台兼容功能。
尝试编译它对Winelib并且您不必重写大部分功能。
在您的意见光，鉴于我肯定会在源代码中定义明确的层分离的时间和资源：
的OS /平台相关层，
的OS抽象层，
的OS独立中间件&
的UI层
这是最基本的分层架构在任何软件应用程序一个会遇到。这样每当我需要将它移植到一个新的操作系统/平台时，我只需要编写一个OS/platform dependent layer，而其他所有层都保持不变。同样，当需要更改UI框架时，我可以轻松修改UI layer，而其余部分保持不变。
当然，这样的解决方案需要充足的时间和资源在你的一次性使用中，但一旦你这样做了，你的生活将来会容易得多。
有足够的时间和资源我会做第二个选择，在我看来，一个更干净的方法。如果需要快速的&脏解决方案，相反，您可以按照@Als的建议并使用Winelib。顺便说一下，Qt和STL/Boost是多平台库，所以在将来你可以使用“移植”版本作为多平台版本，在Windows上部署它并摆脱MFC依赖性（优势：仅限于：一个代码库可以工作;缺点：Qt是一个相当重要的依赖项）。
另外，我也无法使用Qt。这肯定会减少开销。 –
如果您完全放弃了GUI，并且您需要的每个其他MFC功能在Stdlib中或Boost中都具有相同的功能，您绝对可以成功。但恕我直言，重要的是分离分析核心代码并仅使用Stdlib/Boost功能，然后在每个平台上插入任何接口。 –
对不起，我不能用这个酒。我应该早一点提及。 –