14

私からの以前の関連する質問はこちらです古いペイントプログラムのリバースエンジニアリング

私はここに私の活動拠点を設置しました: http://animatorpro.org wiki は近日公開予定です。

さて、これで 300,000 行のレガシー MSDOS コードベースができました。それは一種の「あなたが望むものに注意してください」という状況です。私は経験豊富な C プログラマーではありません。私も完全に経験が浅いわけではありませんが、すべての意図と目的のために、私は言語、特にそのライブラリの複雑さに慣れていません。私は特に、MSDOS 用に特別に作成された C プログラムとクロスプラットフォームのプログラムとの間の気まぐれな違いについては知りません。しかし、私はこのコード ベースを 1 年以上研究しており、Animator Pro について知っていることは次のとおりです。

使用したコンパイラとツール:

  • ワトコム C コンパイラ
  • tcmake (Turbo C からプログラムを作成)
  • 386asm、Phar Lap dos エクステンダー専用のアセンブラー
  • そしてもちろん、Phar Lap dos エクステンダー自体。
  • あいまいな DOS ユーティリティの選択

コンパイルの多くは、バッチ ファイルによって行われるようです。これらすべてのツールのコピーを入手しましたが、まだコンパイルに成功していません。(ただし、その兄である autodesk animator のオリジナルをコンパイルしました。

REX に基づいて、DLL が利用可能になる前に DLL をレプリケートするプラグイン システムがあります。プラグイン システムは以下を処理します。

  • ビデオ ドライバー (多数の VESA ドライバーが含まれています)
  • 入力ドライバー (wacom タブレット、キーボードを含む)
  • 描画ツール
  • インク (Photoshop のフィルターや描画モードなど)
  • Scripting Addons (本質的にコンパイルされたスクリプト)
  • ファイル形式

C 言語に基づいた、POCO という名前の独自のスクリプト インタープリターがあります。スクリプト言語には、プラグイン システムが実行できるほぼすべてのことを実行するのに十分なパワーがあります。ただ遅いだけです。

この情報を踏まえた上で、これが私の開発計画です。これを批判してください。ソース コードは上記のリンクから入手できるので、必要に応じて状況を自分で簡単に評価できます。

  1. オリジナルのツールでコンパイルします。
  2. DJGPP を使用するように切り替え、元のアセンブラに加えて DJGPP でコンパイルできるように必要な変更を加えます。
  3. Allegro.cc の「ゲーム」ライブラリを含め、できるだけ多くの機能をそのライブラリに切り替えます。おそらく、Allegro API を使用する新しいビデオおよび入力ドライバを作成するだけです。私が SDL ではなく allegro を考えている理由: Allegro には DOS バージョンがあり、魅力的なことに、そのコア機能の 1 つは Animator Pro のネイティブ形式の FLIC を再生する機能です。
  4. うまくいけば、3 の後、プロジェクト内のほとんどまたはすべてのアセンブラーを排除できます。うまくいけば、それはあいまいな方言であり、大幅な変更なしでは最新の無料のアセンブラーではアセンブルできないためです。私はそれらすべてを試しました。残っているものはすべて、NASM でアセンブルするために変換されるか、アセンブラーの実際の機能を定義できる場合は C コードに変換されます。
  5. dos エクステンダーを Phar Lap から HX Dos http://www.japheth.de/HX.htmlに切り替えます。これにより、WIN32 API を可能な限り複製することが約束されます。次に、それが機能するために必要なすべてのコード変更を行います。
  6. Win32 バージョンが HXDos 上で実行できると仮定して、Allegro.cc の win32 バージョンに切り替えます。さらに必要な変更を加える
  7. プラグイン システムを変更して、ある種の標準的なクロス プラットフォーム プラグイン ライブラリを使用します。これがどうなるか、私にはわかりません。多分あなたはいくつかの提案を提供できますか？プラグイン システムを最初に作成した開発者と話をしたところ、セグメンテーションの制限により、最新の OS では実行できないことがいくつかあると彼は言いました。これが何を意味するのかはわかりませんが、すべてのプラグインをほぼゼロから書き直す必要があることを意味していると思います。
  8. 魔法のように、私は上記のすべてを完了し、Windows、OSX、および Linux で実行できるようにし、長いファイル名などの他のクロスプラットフォームの問題や、私が考えもしなかったことを処理することができます。

誰でもこれで問題が発生しましたか？アレグロは良い選択ですか？そうでない場合、なぜですか？このプラグイン システムについてどうしますか? あなたは何をしますか？これはすべてばかげているのでしょうか。オリジナルをインスピレーションとして使用して、最初から書き直す必要がありますか? （それを行うには、元の開発者が「約1か月」かかるようです）

上記で触れていないことの 1 つは、テキスト/フォント システムです。どうすればよいかわかりませんが、Animator Pro には独自のカスタム フォント形式があり、Postscript Type 1 フォントやその他の形式も使用できます。

4

3 に答える 3

7

あなたの計画に対する私の最大の懸念は、一言で言えば、あなたのアプローチは、環境を微調整してDOSから遠ざけることで、巨大なもの全体を常に機能させようとすることのようです。つまり、環境を微調整するたびに、一度に壊れた可能性のある約 10 億の微妙な仮定があり、そのどれもまだ理解していないということです。それらを一度にほぐすのは、信じられないほどの苦痛を伴います。

私が移植を行っている場合、私のアプローチは、最新の環境で何かを実行するためにできるだけ多くのコードを無効にし、パーツを一度に 1 つずつオンラインに戻すことです。ディスプレイ ドライバをロードして何かを描画する簡単なテスト ハーネス プログラムを作成し、それを DOS 用にコンパイルして、インターフェイスを理解していることを確認します。次に、同じインターフェイスを実装するが Allegro (または SDL または SFML) を使用する C コードをいくつか作成し、そのプログラムを Windows または Linux で動作させます。出力が異なる場合は、単純なテスト ケースを使用して作業できます。

このポートでのあなたの仕事は、さまざまなインターフェースと機能の実装を完全に新しいものに置き換えることです。 これは、単体テストが得意とする仕事です。 DOS で古いコードを実行する何らかのテストを行わずに、新しいコードを作成しないでください。潜在的な問題をできる限り小さくシンプルにします。アセンブリ コードを書き直すのではなく、実際に作業が簡単になると合理的に確信できる場合にのみ移植します (つまり、NASM で少し調整するだけで問題なくコンパイルできるアルゴリズムなど)。一度に脳に快適に収まるよりも大きな部分を噛まないでください.

私は、あなたの進歩を見るのを楽しみにしています！あなたがやろうとしていることは素晴らしいと思います。やってくれてありがとう。

于 2011-02-07T20:39:55.007 に答える
6

うーん、OpenGL ビデオ「ドライバー」を作成することでアプローチできるかもしれません。そして今日のマシンは大量の RAM で十分に高速であるため、メイン CPU ですべてのピクセル固有のアルゴリズムをバック バッファーに実行することができ、それは機能します。「一般的な」VGA ドライバーがビデオ バッファーをポインターにマップしただけなので、ここから開始します。高解像度ディスプレイでピクセルを確認できるように、UI にズーム モードがありました。

于 2011-06-06T19:28:56.957 に答える
0

移植性を念頭に置いて書かれていない既存の自明ではないコードベースを取り上げて、それを移植可能にしようとすることは、しばしば非常に困難です。途中で多くの問題が発生します。ゼロから始めて、既存のコードを参照としてのみ使用してコードを書き直すことをお勧めします。ゼロから始める場合は、Qt などの新しいプロジェクトで既存のポータブル UI ソリューションを活用できます。

于 2011-02-06T03:02:12.460 に答える