［CEDEC 2007］TSFにUAC。Windows Vistaベースのゲーム開発における「ちょっといい話」

川西裕幸氏（マイクロソフト デベロッパー＆プラットフォーム統括本部 エバンジェリスト，左）とNyaRuRu氏（右）

　CEDEC 2007では，マイクロソフトの川西裕幸氏による「Windows Vistaゲーム開発」というセッションが開催された。この手のイベントではお馴染みの川西氏が登場ということで，DirectX 10.1のディープな話題が聞けるのでは……と思いきや，「超地味」な内容に。とはいえ，視点を変えるとなかなか面白いネタもあったので，突っ込んでレポートしていくことにしよう。

地味ゆえ意外と知られていない

ゲームの日本語入力問題

　演壇に立った川西氏が最初に口にしたセリフは「今日のテーマは地味です」だった。
　「派手なネタを期待していた方に悪いので」と，Windows Vistaの派手なプロモーションビデオを再生して，ざっとしたWindows Vistaの紹介を行って，すぐ最初のテーマ「TSF」（Text Service Framework）解説のために招かれたゲストスピーカー，NyaRuRu氏にバトンタッチした。

　NyaRuRu氏は「Microsoft MVP for DirectX」の肩書きを持つプログラマだ。Microsoft MVPとは，Microsoftの技術に詳しいと同社によって認められた在野のプログラマに贈られる，一種の称号のようなものである。
　そんなNyaRuRu氏の取り上げたTSFだが，まず何が問題となっているかというと，日本語入力をサポートしているゲームの一部――というよりほとんど大半――が，Windows Vista上で動作しなくなっている点だ。

　症状は，「日本語入力をオンにすると入力ウィンドウが現れるものの，チラチラと明滅したような表示になるだけで，日本語の入力を正しく行えない」というもの。（その必要がないため）日本語入力をサポートしないタイトルなどを実行したとき，誤って日本語入力をオンにしてしまうと似たような現象が発生するのは，“洋ゲー”プレイヤーなら経験的にご存じと思う。アレと同じ現象が，Windows Vistaでは日本語入力をサポートするゲームでも生じてしまう。それはなぜなのか，というのが，NyaRuRu氏による解説のテーマというわけである。

IMEからTSFに切り替えられた理由。分かる人には分かると思うが，分からない人も「要は設計が古いから」と捉えておけば間違いない

　NyaRuRu氏はその理由を冒頭で「DirectX SDKにあるバグ」と一言でまとめてくれているのだが，本稿では分かりやすくするために，背景から先に説明していくことにしたい。
　さて，4Gamer読者の大半は，日本語入力といえば「IME」（Input Method Editor）という言葉を思い出すのではなかろうか。
　しかし実のところ，Windows Vistaの標準状態では，IMEは使われていない。標準で付属する日本語変換エンジンはIMEのAPIをサポートしていないのだ。では，どうやって日本語入力を実現しているかというと，それがTSFなのである。

　先ほど述べたように，TSFはText Service Frameworkの略。文字どおり「文字入力のための包括的なフレームワーク」だ。IMEからTSFに切り替えられた理由はいくつかあるようだが，一言でまとめるなら「IMEは設計が古いから」。IMEのAPIが初めて提供されたのは16bit Windows時代なので，古くなってしまうのも無理はない。

TSFの歴史。なんと6年前からあったそうだ。これは筆者も知らなかった

TSF非対応（＝IME対応）のアプリケーションでTSFを通じた入力を可能にするのがCUASだ。スライドにある「TIP」（Text Input Processor）は，TSFに対応した入力エンジンのこと

入力データの流れ。ちょっと見づらいかもしれないが，サードパーティのIMEがある/ないときでデータの受け渡される経路が変わるという，複雑怪奇なモノになっている

　TSFはCOMベースのフレームワークで，最近のWindowsプログラム開発になじみがいいほか，手書き入力，音声入力などにも対応しやすい（※IMEのAPIでも対応できないことはないが美しくない）などの特徴を持つ。
　筆者も知らなかったのだが，TSFが提供されだしたのは「Windows Vistaが最初ではない」（NyaRuRu氏）とのこと。初期のTSFはOffice XPに同梱されていて，Office XPをインストールするとWindows XPにTSFがインストールされるようになっていたらしい。また，Windows XP SP1からは標準でTSFがインストールされていたそうだ。

　もっとも，世の中の大半のソフトはTSFに対応しておらず，IMEを前提に日本語入力周りが設計されている。“TSFオンリー”になったWindows Vistaでも，IME前提のソフトが動かないとお話にならないわけで，IMEのAPIをエミュレートする「CUAS」（Cicero Unaware Application Support）というレイヤーが組み込まれているのだ。なお余談だが，「Cicero」はTSFの開発コードネームである。

　恐ろしいことに，Windows Vistaはそれこそ「ATOK」など，IME対応となるサードパーティの入力メソッドも，きっちりとサポートする。Windows Vistaにサードパーティ製IMEをインストールするとIMEネイティブのAPIが復活するのだが，その間を取り持つCUASは，極めて複雑な処理を行っているようだ。「Microsoftは，過去のアプリケーションとの互換性を取るため，非常に苦労している」（NyaRuRu氏）というのを実感させられるような話である。

　以上が背景説明。簡単にまとめると「サードパーティのIMEをインストールしない限り，Windows VistaではTSFが使われる」ことになる。

　話を本題に戻そう。ゲームで日本語入力をサポートするには，ウインドウを表示させず，ゲーム側で表を行わなければならないこれはゲーム開発者にとっていわば常識だ。
　先の複雑怪奇なスライドとCUASという危うい仕組みから「CUASやTIPのせいでウィンドウを出さないモードが動かなくなったのでは!?」と思うかもしれない。
　実際，Windows XP時代の古いTIPでは，ウィンドウを出さないモード――これをTIPではUILess modeという――には対応できないという問題があったのだが，Windows Vistaで起きている問題の原因はまったく別のところにある。というのも，「Direct X SDK付属のIME使用サンプルにバグがあった」（NyaRuRu氏）のが，そもそもの原因なのだそうだ。

30秒で分かる事件のあらまし

　事情はスライドに示すとおり。要するに，Microsoftの提供するDirectX SDKのIME使用サンプルにバグがあったのだそうだ。IMEが使用されているとき，IME側がこのバグを無視してしまうため，正常に「動いてしまって」いた。一方，IMEをエミュレートするCUASはIMEの仕様どおりに（＝真っ正直に正しく）動作するため，バグが動作不能を引き起こした，という筋書きである。そして，そのバグの存在が明らかにならないまま，ソフトベンダーがSDKのコードをマネし続けたため，Windows Vistaでのトラブルが起きたというわけだ。

上が修正前のコード。下が修正後のコードだ

　では，どの辺を直さなきゃならないのか，というのが右のスライドである。
　IMEの表示内容をゲーム側で肩代わりするとき，WM_IME_SETCONTEXTというメッセージでlParamをクリアしなければならない，ということ自体は正しいそうだ。
ただ，上のコードが変というのは，プログラマなら誰でも分かるはずである。ウインドウプロシージャに渡るlParamはローカル変数だから，クリアしても何の意味もないからだ。
　というわけで，実際には下のようにlParamのフラグを落としたうえで，DefWindowProc()にそのlParamを渡してやらなければならないとのこと。まあ，いわれてみれば当たり前で，これを誰も気づかなかったというのも妙な気がする。

　というわけでNyaRuRu氏は「バグはコピペで広がる」という教訓を示して会場の笑いを誘っていた。まったくそのとおり。

着実に対応が進みつつあるUAC

Games for Windows認定を受けるために必須となる「Xbox 360共通コントローラのサポート」も，Windows Vista世代のゲーム開発では推奨される

　NyaRuRu氏の説明に続いて，川西氏が話したのは，Windows Vista対応ゲームで守るべき事柄についてである。「ベストプラクティス」と題されたその内容は，「Program Files以下にプログラムをインストールする」などといった，Windows XPで従うべきルールに従うのは当然として，64bitでも動作チェックする，プログラムに署名を入れる，といったものである。

　まあ，これらは要するに「プログラマへのお願い」なのだが，それを踏まえた川西氏が突っ込んで取り上げたのが，Windows Vista対応に当たって大きなハードルの一つとなる「UAC」（User Account Control）だった。

「UACと仲よくしよう」と呼びかける川西氏。昇格が必要なのはインストール時だけに留めねばならない

　UACについて念のため説明しておくと，Windows Vistaでは，一般ユーザーの権限が削減されており，権限を越えた操作を行うには「昇格」する必要がある。そして，昇格するときには，いちいちダイアログでユーザーの確認を取るようになっている。
　したがって，Windows Vistaでは「一般ユーザーの権限で動かせるプログラム」が望ましく，仮に昇格が必要な場合も，インストール時だけに留めなければならない。

　また，ゲームにおいて割と問題になるのは，「一般ユーザー権限では，Program Files以下の変更を行えない」ようになっている点だろう。川西氏は「いまどきないとは思いますが」と笑っていたが，古いゲームではインストール先ディレクトリのファイルを変更するものがかなりあるからだ。

　一例を挙げてみよう。例えばid Software作品は伝統的に，どこのフォルダにインストールしても，インストール先フォルダの設定ファイル（※cfgファイル）を参照・変更するようになっているが，こうした動作はWindows Vistaだと許されない。
　もちろん，「許されない」といっても，完膚無きまでに不許可だと困ってしまうので，Windows Vistaには救済機能が組み込まれている。インストール先フォルダの設定ファイルを変更しようとすると，Windows Vistaはその動作を取り上げて，ユーザーディレクトリ（標準はC:\Users\usernameの下）の「AppData\Roaming\（プログラム名フォルダ）を作り，その下に「影の設定ファイル」を作って，そのファイルを参照・操作させるようになっているのだ。
　なお，いったん影の設定ファイルができると，インストール先フォルダの設定ファイルは参照されなくなる。また，この救済機能が機能するのはWindows APIを通じて変更が行えるINIファイルの場合のみで，独自に操作している場合は機能しない。先のid Softwareの一連のゲームも.INIファイルではないため救済策は機能しないのだ。

インストール先ディレクトリに書き込みしないように，というスライド。面倒な話だが，Windows Vistaでは従う必要がある

　この救済機能について触れた川西氏は，「（救済機能を使うと）設定ファイルがどこにあるのかユーザーから分からなくなるという欠点がある」点を指摘し，そもそもインストール先ディレクトリの下を変更しないようにゲームを作ってほしいと述べていた。

　なんだか面倒な話に思えるだろうが，実のところ，ゲーム側の対応は着実に進んでいる。例に挙げたid Softwareとその関連タイトルの場合だと，最新作「Enemy Territory: Quake Wars」は，Winodws Vistaの作法に従うように変更されている。対応が進めば，ゲーマーにとってUACも「うざったい」存在ではなくなるはずだ。……過去のタイトルについてひとまず置いておけば，だが。


　以上，川西氏が述べたとおり，非常に地味なセッションとなったが，ふだんあまり耳にしない，日本語入力関連の裏事情などを聞くことができたのは収穫だった。派手なネタを期待していた参加者も，相応の収穫は得られたセッションではなかったかと思う。
　UACなど，Windows Vistaでの動作を考えると対応してもらわなければ困る部分も多いわけで，対応が進んでいけば，少しずつではあるが，Windows Vistaへの乗り換えも楽になっていくのではなかろうか。


※お詫びと訂正（2007年10月3日）：NyaRuRu氏の講演内容を解説した部分に，一部誤解を招く表現がありました。お詫びして訂正いたします。