開発

ReactOSがDirectX刷新 Wine 10.0統合で対応拡大

ReactOSがWine 10.0基盤のDirectX更新を統合。49万行追加で数百本のゲーム開放へ。

9分で読める SINGULISM 編集チームが確認・編集

ReactOSがDirectX刷新 Wine 10.0統合で対応拡大
Photo by Antonis Georgiou on Unsplash

オープンソースのWindows互換OSであるReactOSが、DirectX基盤の大規模更新を統合した。 PhoronixのMichael Larabelの報道では、Wine 10.0の状態を反映した実装が取り込まれたとされている。 変更規模は新規49万8000行の追加と11万9000行の削除に達する。 従来の独自対応の多くが除去され、描画経路の共通化が進んだ。 本記事は Phoronix に基づく(All Rights Reserved)。日本国著作権法32条の公正な引用に依拠する。

今回の更新は、Windows用応用 software や駆動 software との二値互換を目指す方針に沿うものだ。 ReactOSはNT系の内部構造を再実装し、既存資産の実行環境を確保してきた。 描画周りは互換性の難所であり、娯楽 software の動作を左右してきた。 Wine由来の実装を取り込むことで、保守性と拡張性の改善が図られた。

Wine 10.0基盤への大規模更新

今回統合された変更提案の目的は、DirectX基盤をWine 10.0に更新することにある。 開発を主導したのはReactOS開発者のJustin Millerである。 同氏は少なくとも230時間以上をこの作業に投じたと説明している。 作業は未完の部分を残しつつ、主要な統合段階に到達した。

更新では従来の独自対応が大幅に整理された。 個別の回避策に依存せず、上流の実装をそのまま生かす方向が強まった。 一部の試験項目の不具合も修正された。 長期的な保守負担の軽減につながる整理だと受け止められる。

開発の経緯は、ReactOS、Half-Life 2動作を達成 オープンソースWindows互換OSの30年で辿られた長期的な互換性向上の流れに位置づけられる。 娯楽 software の起動実績が積み上がり、描画基盤の更新が次の段階となった。 今回の統合は、その延長線上にある節目だ。 基盤更新と応用事例の往復が開発を前進させている。

49万行追加の実装規模と内容解説

統合された符号量は、新規49万8000行と削除11万9000行に上る。 数百時間規模の作業を要した大型の変更提案である。 単なる版上げではなく、独自対応の除去を伴う置換が中心だ。 上流との差異を縮小し、将来の追従を容易にする狙いがある。

削除対象となったのは、ReactOS固有のDirectX関連の回避策である。 短期的な動作確保には有効だったが、上流との乖離を招いていた。 今回の置換により、符号基盤の見通しが改善された。 重複実装の削減は不具合調査の効率化にも寄与する。

Miller氏は変更提案の中で、作業量の大きさと未完の課題に言及した。 原文の記述は次の通りだ。

This is an incredibly long time coming, that’s taken at least 230+ hours of my life so far.

同氏は目的についても次のように記している。

The goal of this PR is to update our DirectX stack to WINE-10.0, while removing a lot of our hacks.

試験項目の修正も含まれており、品質基盤の底上げが図られた。 大規模置換に伴う退行の検出と抑止が今後の焦点になる。

OpenGLとVulkanによる変換対応

新しい実装は、DirectXの処理をOpenGLとVulkanで変換する構成を可能にする。 ReactOS上で直接実行できない描画命令を、既存の描画基盤に中継する仕組みだ。 Vulkanの利用には条件があり、独自分岐かMesaの software 描画が前提とされている。 実行環境ごとの制約を踏まえた選別が必要になる。

注目点は、ReactOSのDirectX基盤がWindows自体でも動作しやすくなったことだ。 ReactOS専用の閉じた実装ではなく、Windows上でも利用可能な層に近づいた。 二つの環境で同じ基盤を検証できる利点は大きい。 不具合の切り分けと修正の共有が進めやすくなる。

この方向は、WineとReactOSの符号共有の歴史とも整合する。 WineはWindows用応用 software をUnix系OSで動かす互換層を整備してきた。 ReactOSは核や駆動 software 層を含むOS全体の再実装を目指してきた。 描画基盤の共通化は、双方の成果を生かす合理的な選択だ。

数百本のゲーム開放へ検証事例紹介

Miller氏によれば、関連する他の変更提案と合わせれば数百本規模の娯楽 software が利用可能になる。 単体の更新だけでもNT5系での起動事例が確認されている。 具体例として挙げられたのがDragon Age: Originsである。 同 software がNT5系で起動に至ったことが報告された。

NT5系はWindows XPやServer 2003世代に対応する系統である。 旧世代の応用資産を現行環境で維持する需要は根強い。 起動に至るか否かは、描画や音声、入力など複数の層の協調に左右される。 DirectX基盤の更新は、その隘路の一つを解消する。

開発者はX上で、近くDirectX 10や11や12の娯楽 software への対応が可能になると述べた。 現時点で全ての題名が動作する状態ではない。 検証と修正の積み重ねが前提になる。 それでも対応範囲の拡張余地は明確に広がった。

試験体制の重要性は、GNOME OS Test Center、Apple TestFlightに着想が示すOS試験基盤の議論とも重なる。 大規模な基盤更新ほど、体系的な試験と配布の仕組みが成果を左右する。 ReactOSでも起動可否の記録と再現手順の共有が鍵になる。 開発基盤の整備をめぐる関心は、4社が選んだAgentic Infra、Infinigenceの戦略にも表れている。

Windows自体での動作改善の意味

Windows自体での動作改善は、技術的な副次効果にとどまらない。 ReactOSの実装が特定環境の専用品から外れ、移植性の高い層になったことを示す。 Windows上で直接試験できれば、ReactOS固有要因と共通要因の分離が容易になる。 修正の上流還元や下流取り込みも円滑になる。

独自対応の除去は、開発体制の持続可能性にも関わる。 個別の回避策は短期的には有効だが、長期的な追従費用を増やす。 上流のWine 10.0に寄せることで、更新差分の適用が単純化される。 限られた人員で広い互換範囲を支えるうえで有効な戦略だ。

残る課題はVulkan経路の制約である。 独自分岐かMesaの software 描画に依存する現状は、性能と導入容易性の面で限界がある。 装置駆動 software や描画基盤との連携強化が求められる。 今後の分岐統合や性能検証の進展が注目される。

編集部の見解

今後3〜6か月では、Wine 10.0由来の描画経路が集中的な試験対象となり、不具合報告が増加すると見る。特にVulkan経路は独自分岐やMesaの software 描画に依存する制約が残る。開発資源の配分と検証体制の整備が進展速度を左右すると評価する。

1〜3年ではDirectX 10や11や12への対応拡張が焦点になると見る。Windowsとの二重動作が検証効率を高め、互換層全体の保守性を改善すると評価する。旧版Windows向け資産の延命手段として実用価値が高まる可能性がある。

互換性の拡大は利用者の選択肢を広げる一方で、権利処理や動作保証の所在を曖昧にしないだろうか。Vulkan依存の解消には何が必要であり、誰が担うべきだろうか。開放される数百本という規模をどう検証し、品質を担保すべきだろうか。

参考

よくある質問

ReactOSの今回のDirectX更新は何を変更したのか
DirectX基盤をWine 10.0相当に更新し、従来の独自対応を大幅に除去した。新規49万8000行の追加と11万9000行の削除を伴う大規模置換であり、OpenGLとVulkanによる変換構成が可能になった。
どの程度の娯楽 software が動作するのか
関連する他の変更提案と合わせれば数百本規模が利用可能になるとされている。単体でもNT5系でDragon Age: Originsの起動が確認された。DirectX 10や11や12への対応も視野に入っている。
Vulkan利用の制約は何か
Vulkan経路は独自分岐かMesaの software 描画が前提とされている。すべての環境で高性能に動作するわけではない。今後は分岐の統合や装置駆動 software との連携、性能検証の進展が課題になる。
出典: Phoronix

コメント

← トップへ戻る