16

一般に、16 ビット Windows プログラムを Win32 に変換するには、何をする必要がありますか? コードベースを継承し、隅に潜んでいる 16 ビット コードを見つけて唖然とするのは私だけではないと確信しています。

問題のコードは C です。

4

6 に答える 6

18
  1. wParamとの意味はlParam多くの場所で変更されています。偏執的になり、可能な限りメッセージクラッカーを使用するように改宗することを強くお勧めします. 彼らはあなたの頭痛の種を救います。一つだけアドバイスするとしたら、これです。
  2. メッセージ クラッカーを使用している場合は、STRICT. 、、またはその他のものintを使用する必要がある場所を使用して、Win16 コード ベースをキャッチするのに役立ちます。これらを変換すると、このリストの #9 で大いに役立ちます。HWNDHANDLE
  3. hPrevInstance役に立たない。使用されていないことを確認してください。
  4. Unicode 対応の呼び出しを使用していることを確認してください。これは、すべてを s に変換する必要があるという意味ではありませんが、 、、およびをにTCHAR置き換えて、明白な名前を付けたほうがよいことを意味します。OpenFile_lopen_lcreatCreateFile
  5. LibMain現在DllMainは であり、ライブラリ全体の形式とエクスポート規則が異なります
  6. Win16 には VMM がありませんでした。 GlobalAlloc、LocalAlloc、GlobalFree、およびLocalFreeは、より現代的な同等のものに置き換える必要があります。LocalLock完了したら、 、LocalUnlockおよび友人への通話をクリーンアップします。それらは今では役に立ちません。あなたのアプリがこれを行っているとは想像できませんが、WM_COMPACTINGそこにいる間は依存しないようにしてください.
  7. Win16にはメモリ保護もありませんでした。アウトプロセス ウィンドウへのポインタを使用SendMessageまたは送信していないことを確認してください。PostMessageパイプやメモリ マップ ファイルなど、より最新の IPC メカニズムに切り替える必要があります。
  8. Win16 には、プリエンプティブ マルチタスキングもありませんでした。別のウィンドウから迅速な回答が必要な場合は、電話SendMessageしてメッセージが処理されるのを待つのは非常にクールでした. それは今では悪い考えかもしれません。PostMessageより良いオプションではないかどうかを検討してください。
  9. ポインターと整数のサイズが変わります。特に Win16 構造の場合は、データをディスクに読み書きしている場所を注意深く確認してください。短い値を処理するには、手動でやり直す必要があります。繰り返しになりますが、これに対処するための最も簡単な方法は、可能な場合はメッセージ クラッカーを使用することです。それ以外の場合は、必要に応じて手動で探して変換する必要がありintますDWORD。
  10. 最後に、明らかなことに成功したら、64 ビットのコンパイル チェックを有効にすることを検討してください。16 ビットから 32 ビットに移行する際に直面する問題の多くは、32 ビットから 64 ビットに移行する場合と同じであり、最近の Visual C++ は実際に非常に優れています。いくつかの長引く問題を見つけるだけではありません。最終的な Win64 への移行の準備も整います。

編集: @ChrisN が指摘しているように、Win16 アプリを Win32 に移植するための公式ガイドはアーカイブされてお​​り、上記の私のポイントに肉付けして追加します。

于 2008-09-29T04:44:24.577 に答える
6

ビルド環境を正しくすることとは別に、対処する必要のある詳細をいくつか示します。

  1. intを含む構造体は、shortに変更するか、16ビットから32ビットに拡張する必要があります。構造のサイズを変更し、これがディスクにロード/保存される場合は、データファイルのアップグレードコードを書き込む必要があります。

  2. ウィンドウごとのデータは、多くの場合、GWL_USERDATAを使用してウィンドウハンドルとともに保存されます。一部のデータを32ビットに拡張すると、オフセットが変更されます。

  3. POINT＆SIZE構造体はWin32では64ビットです。Win16では、これらは32ビットであり、DWORDとして返すことができました（呼び出し元は戻り値を2つの16ビット値に分割します）。これはWin32では機能しなくなり（つまり、Win32は64ビットの結果を返しません）、関数は戻り値を格納するためのポインターを受け入れるように変更されました。これらすべてを編集する必要があります。GetTextExtentのようなAPIはこれの影響を受けます。この同じ問題は、一部のWindowsメッセージにも当てはまります。

  4. Win32では、レジストリを優先してINIファイルを使用することはお勧めしません。INIファイルの機能は引き続き機能しますが、Vistaの問題に注意する必要があります。16ビットプログラムは、多くの場合、INIファイルをWindowsシステムディレクトリに保存していました。

これは私が思い出すことができる問題のほんの一部です。Win32の移植を行ってから10年以上になります。あなたがそれに入ると、それは非常に速いです。移植に関しては、各コードベースに独自の「感触」があります。途中でいくつかのバグを見つけることさえあるでしょう。

于 2008-09-29T03:22:34.697 に答える
3

MSDNの記事Porting 16-Bit Code to 32-Bit Windowsに決定的なガイドがありました。

于 2008-09-29T19:24:47.020 に答える
1

オリジナルのwin32sdkには、ソースコードをスキャンし、変更が必要な行にフラグを立てるツールがありましたが、ツールの名前を思い出せません。

過去にこれを行わなければならなかったとき、私はブルートフォース手法を使用しました-すなわち：1-32ビットコンパイラとリンカを使用するようにmakefilesまたはビルド環境を更新します。必要に応じて、IDEで新しいプロジェクトを作成し（私はVisual Studioを使用します）、ファイルを手動で追加します。

2-ビルド

3-エラーを修正します

4-完了するまで2＆3を繰り返す

プロセスの苦痛は、移行するアプリケーションによって異なります。1時間で10,000の回線プログラムを変換し、1週間以内に75,000の回線プログラムを変換しました。また、あきらめて（ほとんど）最初から書き直した小さなユーティリティもいくつかあります。

于 2008-09-29T02:59:05.250 に答える
0

試行錯誤がおそらく最善の方法であるというアランに同意します。

ここにいくつかの良いヒントがあります。

于 2008-09-29T03:07:54.667 に答える
0

コンパイラがおそらくほとんどのエラーをキャッチすることに同意しました。また、「near」および「far」ポインタを使用している場合は、これらの指定を削除できます。ポインタは、Win32では単なるポインタです。

于 2008-09-29T03:19:16.560 に答える