Windowsランチャーの「動く」を6つに分ける

標準読者は、Wineとprefixの基礎を知り、Windows向けランチャーの互換性を自分で調べたい技術者である。この記事の目標は、processが生きたことを「動いた」とせず、次の6条件を別々に判定できるようになることだ。

検証対象は、ChromiumとNode.jsを同梱するデスクトップアプリ基盤（Electron）で作られたx64 Windows clientだった。同じ配布面には過去のJava系clientも存在したが、別binaryの知見を現行clientへ持ち込むと、調べるruntimeもfailure surfaceもずれる。

Windows installerのGUIは、PowerShellを使う「既存アプリ終了」確認で停止した。そこでinstallerを無理に完走させず、公式metadataから固定した配布物をMac側で検証し、Windows installer形式（NSIS）の最終payloadだけをmacOS標準の展開器で取り出した。

clientは起動直後にERROR_PROC_NOT_FOUND (127)で落ちていた。複数の不足symbolを一覧にしても、どれが実際にprocessを止めたかは分からない。Crashpad dumpの例外位置からdelay-IAT slotへ戻し、実行時まで関数解決を遅らせる仕組み（delay import）の対象を照合すると、load-bearingだったのはUSER32.IsWindowArrangedだった。

API crashを直すとwindowは残ったが、contentは黒いままだった。hard traceが示したのはGPU能力の不足ではなく、GPU processが別process所有のWindows window handle（HWND）へVulkan surfaceを作れない境界だった。

browser認証では、認証後に独自URL schemeでdesktop clientへ戻る。Macアプリがその戻り先を受け取る仕組みをprotocol handlerと呼ぶ。互換ランチャーは認証値を解釈せず、受け取ったURLを同じ固定client、prefix、runtimeへ渡す。

Electron製clientの画面が見えても、そこから起動する32-bitゲームのfontや動画が自動で成立するとは限らない。公式client経由で購入済みゲームを起動すると、親clientとは異なるplugin、DirectShow、GStreamer経路が現れた。

game Aの日本語fontはprefix限定設定で直し、黒い起動ロゴは子processへbundled GStreamer環境が届いていないことをtraceで確定した。親clientの成功を隣のprocessへ転用せず、子ゲーム自身のpipelineを調べた結果である。

最後に、確認できたことと確認していないことを同じ粒度で記録する。「マイゲームが見えた」から新規認証や全タイトル互換へ一般化しない。