Win16 CコードをWin32に変換する

StackOverflow https://stackoverflow.com/questions/147351

  •  02-07-2019
  •  | 
  •  

質問

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

問題のコードはCです。

役に立ちましたか？

解決

  1. wParam と lParam の意味は多くの場所で変更されました。 メッセージクラッカーを使用するために、強く偏執的になり、可能な限り変換することをお勧めします。彼らはあなたの頭痛の種を救いません。アドバイスが1つしかない場合は、これで終わります。
  2. メッセージクラッカーを使用している限り、 STRICT も有効にします。 int を使用して、 HWND 、 HANDLE などを使用するWin16コードベースをキャッチするのに役立ちます。これらを変換すると、このリストの＃9で大いに役立ちます。
  3. hPrevInstance は役に立ちません。使用されていないことを確認してください。
  4. Unicode対応の呼び出しを使用していることを確認してください。これは、すべてを TCHAR に変換する必要があるという意味ではありませんが、 OpenFile 、 _lopen 、および _lcreat と CreateFile を使用して、わかりやすい名前を付けます
  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に移植するための公式ガイドはまだ利用可能であり、両方とも充実しており、上記の私のポイントに追加しています。

他のヒント

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

    intを含む

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

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

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

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

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

記事に決定的なガイドがありますポーティング16 -32ビットWindowsへのビットコード（MSDN）。

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

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

2-ビルド

3-エラーの修正

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

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

私は、試行錯誤がおそらく最良の方法であるとアランに同意します。

いくつかの優れたヒント。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top