- LinuxにおけるWindowsゲーム実行構造をカーネルレベルで全面的に再設計し、従来のwineserverベースの同期ボトルネックを解消
- 新しいNTSYNCドライバーがNT同期オブジェクトをカーネルで直接処理し、最大8倍以上のFPS向上を記録
- WoW64の完成により、64ビットLinuxでも32ビットWindowsアプリを追加ライブラリなしで実行可能
- Waylandドライバー強化、Vulkan 1.4対応、Bluetooth・Force feedback改善など、グラフィックス・入出力全般の互換性を拡大
- Proton、SteamOS、LutrisなどWineベースのエコシステム全体に性能と安定性向上の効果が広がる
Wine 11の主な変化
-
Wine 11は単なる年次アップデートではなく、 Linux上でWindowsゲームを実行する仕組みをカーネルレベルで書き換えた大規模な刷新版
- 長年にわたって蓄積されたバグ修正と性能改善に加え、NTSYNC対応、WoW64完成、Waylandドライバー強化などの構造的変化を含む
- Proton、SteamOSなどWineベースのプロジェクト全体に性能向上が波及
従来の限界と暫定策
- これまでのWineは、WindowsのNT同期プリミティブ（mutex、semaphore、eventなど）をLinux上で完全には実装できていなかった
- 各スレッド間の同期のために毎回wineserverへRPC呼び出しを行う必要があり、毎秒数千回の呼び出しがフレーム遅延や不規則なタイミングを引き起こしていた
- Esyncはeventfdを活用してwineserver呼び出しを減らしたが、ファイルディスクリプタ上限の問題が発生
- Fsyncはfutexベースでより高速だが、カーネル外部パッチが必要なため、一般的なディストリビューションでは使いにくい
- Linux 5.16のfutex_waitvはFsyncの原型とは異なり、完全な代替ではない
- どちらの方式も暫定的な解決策に過ぎず、一部のNT API（例: NtPulseEvent、NtWaitForMultipleObjectsのwait-for-allモード）は正確に実装できなかった
NTSYNC — カーネルレベルの同期再設計
- NTSYNCはLinuxカーネルに新しい**/dev/ntsyncデバイスドライバー**を追加し、Windows NT同期オブジェクトを直接モデル化
- ユーザー空間ではなくカーネル内部で同期処理を行い、wineserverとの往復呼び出しを排除
- キュー管理、イベントのセマンティクス、原子的操作をすべてカーネルが直接実行
- 開発者はEsyncとFsyncを作ったElizabeth Figuraで、2023年のLinux Plumbers Conferenceで発表後、Linux 6.14にマージ
-
性能向上の数値
- Dirt 3: 110.6 → 860.7 FPS（678%向上）
- Resident Evil 2: 26 → 77 FPS
- Call of Juarez: 99.8 → 224.1 FPS
- Tiny Tina’s Wonderlands: 130 → 360 FPS
- Call of Duty: Black Ops Iは完全にプレイ可能な状態に
-
fsyncとの違い
- fsyncユーザーに対する改善は限定的だが、マルチスレッドのボトルネックがあったゲームでは劇的な改善
- メインラインカーネルに含まれるため追加パッチが不要で、Fedora 42・Ubuntu 25.04など最新ディストリビューションで即利用可能
- SteamOS 3.7.20ベータに標準搭載され、Proton GEでも有効化
- NTSYNCはWine史上初めてカーネルレベルで正確な同期実装を達成した事例
WoW64完成 — 32ビット互換性の統合
- **WoW64（Windows 32-bit on Windows 64-bit）**アーキテクチャの実装がWine 11で完成
- 64ビットLinuxシステムで32ビットWindowsアプリ実行時に別途32ビットライブラリをインストールする必要がない
- 単一バイナリが実行ファイルのビット数を自動検出して処理
- OpenGLメモリマッピング、SCSIパススルー、16ビットアプリケーション対応まで含む
- 1990年代の旧式Windowsソフトウェアも実行可能
- 以前はディストリビューションごとのmultilib設定の違いで実行が難しかったが、現在はWineが内部的に処理
Waylandおよびその他の主な改善
-
Waylandドライバー
- クリップボードの双方向コピー、ドラッグ＆ドロップ対応、解像度切り替え時のコンポジターによるスケーリングで旧式ゲームの互換性を向上
- X11からWaylandへ移行する際のWine互換性問題の大半を解消
-
グラフィックスとメディア
- X11でEGLがOpenGLのデフォルトバックエンドに変更され、GLXを置き換え
- Vulkan 1.4対応、Vulkan VideoベースのH.264ハードウェアアクセラレーションデコードを追加
-
入出力と周辺機器
- Force feedback改善により、レーシングホイール・フライトスティックへの対応を強化
-
Bluetooth BLEサービスとペアリング対応**,** MIDIサウンドフォント処理を改善
- Zip64圧縮、Unicode 17.0.0、TWAIN 2.0スキャン（64ビット）、IPv6 ping機能を追加
-
性能とプラットフォーム拡張
- Linux・macOSでスレッド優先度管理を改善し、マルチスレッド性能が向上
- ARM64で4Kページサイズのシミュレーションに対応し、ARMベースLinux機器との互換性を確保
ゲーム互換性とバグ修正
- Nioh 2、StarCraft 2、The Witcher 2、Call of Duty: Black Ops II、Final Fantasy XI、Battle.netなど主要タイトルの互換性を改善
- 数百件のバグ修正が含まれ、全体的な安定性と性能が向上
総合評価
- NTSYNC、WoW64完成、Wayland改善、大規模バグ修正が組み合わさったWine 11は、Proton以降で最も重要なリリース
- Proton、Lutris、BottlesなどWineベースのすべてのプロジェクトで性能と互換性が向上
- Linuxでゲームを楽しむユーザーなら、Wine 11はぜひ試す価値のあるバージョン
2件のコメント
結論としては、また古いゲーム数年分の下位互換性が壊れる結果になりそうだな..
これが等価交換ってやつだよね
Hacker Newsのコメント
Wine プロジェクトにはほとんど無限の敬意を抱いている
30年にわたって Windows の文書化された/されていない挙動をそのまま再現しようとする作業は、退屈で報われにくい仕事に聞こえるが、そのおかげで Wine は実際に使える製品になった
特に古いゲームが Windows よりもうまく動くのを見ると、その細部へのこだわりと 苦痛への忍耐力 はすごいと感じる
たまに簡単なゲームを動かしてみて「これ動くのか？」と思うことはあったが、信頼できるとは思っていなかった
今ではその判断が 完全に間違っていた と認める
Excel 2010 が最後に Platinum 等級を獲得したバージョンらしい
ゲームよりこうしたアプリのほうが難しい理由は興味深い
テスト結果ページ を見ると、こうした体系的な検証が高い互換性を生む鍵だとわかる
あのプロジェクトで得られた知見が Wine 開発に数多く流れ込んでいる
当時は Wine のようなものを自分で作りたかったが、知識が足りなかった
今は Linux をサーバー用途でしか使わないので出番がなく、Mac 向け Wine もあると聞いたが、わざわざ動かしたい Windows アプリもない
Proton のおかげでゲームのフレームレートが大幅に上がったのを見て驚いた
Dirt 3 が 110FPS から 860FPS に、Resident Evil 2 が 26FPS から 77FPS に上がったというのは信じがたい
Valve がここに資金を注ぎ込んだからだと思う
既存の fsync ベースの Wine と比べると、向上幅は数パーセント程度だ
それでも ntsync が明確な改善であることに変わりはない
ntsync ドキュメント を見ると、Windows の同期構造を Linux でより正確に実装するためのカーネルドライバだ
ntsync の性能向上にあまり浮かれすぎるなという意見もある
ほとんどの場合、性能向上は一桁パーセント台で、一部のゲームはむしろわずかに遅くなる可能性もある
こういう低レベル技術の話を見ると、自分が CRUD アプリ ばかり作っているのが恥ずかしく感じる
以前、天才開発者が極限スケジュールに苦しめられた末、単純な VB の CRUD 業務に移って「有給休暇みたいだ」と言っていたという話を聞いたことがある
Rails、Phoenix、Django を試したが簡単ではなかった
最近は Claude の助けで少し進展がある
企業の要求事項は複雑なので、アーキテクチャが簡単に崩れることがある
Valve に何千ドルも使った金が、結局 Wine 改善に使われたと思うとうれしい
Valve がどれだけ多くの開発者や契約者を雇っているのか気になる
つまり資金の大半はそちらに流れている
Wine は逆説的に 自己破壊的 かもしれない
Linux でゲームがよく動くようになれば、開発者たちが最初から Linux 向けポートを作るようになって、Wine が不要になる可能性がある
ネイティブポートがあっても、Windows 版を Proton で動かすほうが安定している
Windows API は馴染みがあり変化もしないので、開発者は今後もそちらを基準に開発し続ける
Windows ABI は今でもより安定しているので、性能差がごく小さい限り Windows ビルドだけを維持するほうが効率的だ
ユーザー空間で 共有メモリ を使って ntsync を実装できるのではないかという質問があった
Claude は「95% のゲームでは単純なアプローチで十分だったため、複雑な共有メモリロジックを実装する動機がなく、正確性が重要になった時点ではカーネルに入れるのが自然だった」と説明している
ntsync は単なる API ラッパーではなく、NT カーネルの同期動作を再現する カーネルレベルのアダプタ だ
ソースコード を見ると、カーネルスケジューラと密接に連携している
文書リンク
Linux が Windows を 再実装しながら、かえってよりうまくやっている のを見るのは驚きだ
Microsoft が自社ソフトウェアをますます使いにくくしている一方で、こうした成果は本当にすごい
古いゲームには 16 ビットベースのものが多く、32 ビットゲームであってもインストーラが 16 ビットである場合が多い
Wine 開発者がこれを見ているなら、Carolina Code Conference 2026 で関連発表をしてほしい
登壇者募集は 3 月 31 日まで開いている
macOS でも同じものが欲しいなら このリポジトリ に貢献すればよい
昔、学校の Mac で Bolo という戦車ゲームを遊んだ思い出はあるが、Windows ゲーム数の 1% にも満たない気がする