Linuxへのポート、またはMFC用のラッパーを作成しますか？

Question

プログラムのコア機能を分離してLinuxに移植する方が簡単か、またはMFC機能のラッパーを記述してLinuxで動作する元のMFCプログラムを取得する方が簡単ですか？

例：

、あなたの基本的なダイアログベースのMFCアプリケーション（いくつかのダイアログウィンドウを）取る、それはコアの解析コードの変更なしにLinuxのコマンドラインで実行するように取得します。主な目的は、分析コードを変更しないことです。これを念頭において、MFCアプリケーションが解析コードに使用するのと同じファイルを使用するプログラムのコマンドラインバージョンを記述します。分析コードで使用されるMFCクラスおよび関数とまったく同じように動作するコードを記述します。実際には、これらのクラスのMFCソースコードから始め、すべてのMicrosoft固有のもの（MFC、ATLなど）を切り取り、ラッパーコードとして使用してください。対

：

は、コアの解析コードを取るQtのコマンド・ライン・プロジェクトに差し込みます。任意のMFCまたはWin32の機能については、QtまたはSTL/Boostのいずれかと同等のクロスプラットフォーム互換機能と置き換えてください。

Answer 1

Winelibに対してコンパイルしてください。ほとんどの機能を書き換える必要はありません。

アンOS /プラットフォーム依存層、
アンOS抽象化レイヤ、
アン：私は間違いなく、明確に定義された層にソースコードを分離う時間と資源を考えると、あなたの意見を踏まえて

、 OSに依存しないミドルウェア&
UIレイヤ

これは、どのソフトウェアアプリケーションでも発生する最も基本的なレイヤードアーキテクチャです。そうすれば、新しいオペレーティングシステム/プラットフォームに移植する必要があるときはいつでも、OS/platform dependent layerと書くだけで、他のすべてのレイヤーは変更されません。同様に、UIフレームワークを変更する必要が生じたときには、単にUI layerを変更するだけで、残りのスタックは変更されません。

もちろん、このようなソリューションは使い捨てで十分な時間とリソースを必要としますが、いったんやりなられれば、将来あなたの人生ははるかに容易になります。

Answer 2

私は2番目のオプションを実行するのに十分な時間とリソースがあれば、より洗練されたアプローチに見えます。高速の&が必要な場合は、@Alsの提案に従ってWinelibを使用することができます。

ところで、QtとSTL/Boostはマルチプラットフォームのライブラリであるため、今後はマルチプラットフォームのバージョンとして "移植"バージョンを使用してWindows上にも展開し、MFC依存性を取り除くことができますデメリット：Qtはかなり重い依存関係です）。