OMF 16ビットオブジェクトファイル形式からCOFF32ビットオブジェクトファイル形式に変換する方法はありますか?
3 に答える
おそらく、OMF16コードは16ビットx86リアルモードまたは286プロテクトモードを対象としていますか?その場合、オブジェクトファイル形式は実際には問題ではありません。コード自体は、異なるレジスタサイズと異なるアドレス指定スキームを使用するため、完全に互換性がありません。
さらに、コードがDOS、Win16、またはOS / 2(つまり、OMF16を使用したシステム)を対象としている場合、32ビットターゲットを対象とするのは、オブジェクトファイル形式を変換する場合だけではありません。
質問にタグを付けるソースから再構築する必要がありますか?CまたはC ++ですか?それか、あなたの手に重要なリバースエンジニアリングタスクがあります!
存在するかどうかは真剣に疑問です。16 ビット環境で実行するように設計されたコードは、32 ビット モードとバイナリ互換性がありません。たとえば、次の命令のビット サイズを反転するように CPU に指示する命令があります。16 ビット モードでは、32 ビット命令を使用するためにこのような命令が必要です。ただし、32 ビット モードで 16 ビット命令を使用するには、同じオペコードが必要です。
一連のオペコードを 16 ビットと見なすか、32 ビットと見なすかは、セグメント記述子で指定されます。
いずれにせよ、OS に依存しない 16 ビット コードを 32 ビット モードで使用したい場合は、IDA を使用して逆アセンブルし、32 ビット アセンブラで再コンパイルして使用できます。もちろん、それがライセンスで許可されている場合に限ります。(これはフェアユースかもしれませんが、IANAL)。
コードが基盤となる OS にも関連付けられている場合、これはさらに困難になる可能性があり、おそらくコードのかなりの部分を書き直す必要があります。
ネットで検索したところ、次のリンクが見つかりました。最初のリンクはツールのコレクションです。
http://sourceware.org/binutils/
2 つ目は、必要だと思われるツールです: http://sourceware.org/binutils/docs/binutils/objcopy.html
それらはすべての場合 (上記の bazsi77) で機能するわけではありません。テストするだけです。