現在正解

システムコールは翻訳されません。

システムコールは通常、Windows自体のソフトウェアではなく、共有システムライブラリへの一般的な呼び出しによって行われます。ソフトウェアで使用されるWindows APIは、システムコール（ほとんどの場合は個人用と見なされ、Windowsの一部ではないソフトウェアではまったく使用されていません）に焦点を当てるのではなく、一般的なライブラリAPIであるため、Windowsではかなり印象的な長期実装を実装できます。互換性。

したがって、wineはAPIを実装しますが、Windowsシステムコールは実装しません。そうすることもできません。ユーザーエリアソフトウェアなので、ソフトウェア割り込みを捕捉できません。

さて、

アーキテクチャが同じであれば、Windows .exeファイルをLinuxシステムで実行できることは驚くべきことではありません。

呼び出し規則、ファイル抽象化、オブジェクトファイル形式、およびその他のさまざまな側面の違いを過小評価します。他のオペレーティングシステムで使用されているインターフェイス用に作成されたソフトウェアを正常に実行、呼び出し、基本システムとメモリを交換することはそれほど簡単ではありません。

read1これは通常、POSIX / libcおよびLinux APIを実装し、それ自体がシステムコールをほとんど実行しないC関数（たとえば）を使用する場合と非常によく似ています。syscall(SYS_READ, …)libcを書こうとする人はほとんど見つけられません。

より良い答えになると思います。

ワインはまだそれを行うことができませんし、今後もそうはわかりません。正しいパッチを有効にすると、ワインの準備は（実験的に）可能です。

上記はWINEでシミュレートしたほとんどの場合に当てはまりますが、@mbrigコメント、スタート2019年頃、wine-staging するWindowsシステムコールをキャプチャする機能。 Linuxを使用してこれを行います。セキュリティコンピューティング機能。

Seccomp は、プロセスがカーネルに次の情報を渡すことができるように設計されています。

こんにちはカーネル、私はサーバーで、すべてのリスニングソケットを設定しました。 Webサイトを提供するために必要なもの以外はシステムコールをする理由がないので、 、 、 および以外exitのシステムコールを行うとバイナリがフロアになります。readwritesigreturn

prctlこれはパラメータを使用してシステムコールを実行してこれを行いますPR_SET_SECCOMP。

これは少し柔軟ではなかったので、システムコールとその引数が正しいことを確認するプログラムを実際に定義するプロセス機能が後で追加されました。ただし、これらのフィルタはシステムコール時にBPFプログラムとして定義する必要がありますprctl(PR_SET_SECCOMP,…)。生成された信号ハンドラが実行する必要がある機能を指定することもできます。

WINEはこれを行うことができ、デフォルトでWINEプロセス内で行われたシステムコールがLinuxシステムコールで使用される範囲外であることを確認する以外は何もしません。それ以外の場合は、システムコールが正常に進行することが許可されます。その場合、SIGSYS が発生し、単一の Windows システムコールに対してスケジューラが実行されます。

小さな問題：頑張ってください探す公式メインラインwineストアでは、パッチはまだ「エンドユーザー」ワインにリリースされていません。パッチの3年は少し長い時間です。このアプローチには問題（パフォーマンスへの影響、セキュリティメカニズムと組み合わせた場合の問題）があり、メインラインワインに含まれる場合も含まれない場合もあるためです。メカニズムはソフトウェアと呼ぶことです。wine。