2012年他にやったこと - Mozc 編
Mozc 1.10.1389.102 が公開されたということやっと書ける感じの 2012年やったこと - Mozc 編 - NyaRuRuが地球にいたころ の続き.2012 年にやっていたことの今回公開分.
Support IBus 1.5
Red Hat によって主導され,GNU/Linux 界隈で使われている Input Method Framework であるところの IBus が,メジャーアップデートにあたって設定ファイルの解釈を変えるという決定を下したところ,挙動の変化に気づいたユーザーが IME 側にバグを登録してくることになり,IME 側で設定ファイルを変更することで対処することになったという案件.
平常心平常心と自分に言い聞かせつつ淡々と対処.
Increase opaque buffer size for x32
Mozc が日本語入力を提供しているところの Chromium OS から,x32 でビルドすると static assert に引っかかったからバッファサイズ変更してねとやってきたバグ.こんな身近に x32 を検討中のプロジェクトがあったのかという驚きの気持ちで淡々と対処……したんだけど,その後色々あって Chromium OS の日本語入力は PNaCl でビルドした Mozc が使われることになったため,たぶんこの修正は無意味なはず……
プロセス間通信の AppContainer 対応
Windows 8 で導入された AppContainer サンドボックス下で動作するストアアプリから Mozc を使うにはどうすればよいか考えて実装する,というお仕事.
Mozc のように out-of-process 型の IME にとって,サンドボックスは天敵.実際 Windows 8 のベータテストの段階から色々実験を行っていて,AppContainer から外部プロセスへは単純に名前付きパイプで通信できないというのは分かっていた……んだけど同時にどうしようもなく過ぎていく日々.もちろん胃は痛い.マルチプロセス設計を見直すというのは,Mozc のコード規模では既に悪夢と言ってよく,ストアアプリ対応を諦めるという選択までもがかなりの現実味を持つという状況.ほんと胃が痛かった日々.
結局 AppContainer 導入による Windows 開発への影響 - NyaRuRuが地球にいたころ で紹介したように,名前付きパイプの DACL にエントリを追加すればよいという情報を発見しほっと胸をなで下ろしたのが 8 月頃.
ちなみにこの手法,API の説明を読むに,out-of-process で動作するアクセシビリティ系常駐ソフトへの配慮から残された裏口のようにも読める.変化と互換性の間で綱渡りをする Microsoft らしい配慮がなければ,今でも没入型 UI で Mozc は動作しないままだったかもしれない.
今回公開されたコードでは,以下のうち "(A;;GA;;;AC)" を足している部分がそれ.
https://code.google.com/p/mozc/source/browse/trunk/src/base/win_sandbox.cc?r=131#247
case WinSandbox::kSharablePipe: // Sharable Named Pipe: // - Deny Remote Acccess // - Allow general access to LocalSystem // - Allow general access to Built-in Administorators // - Allow general access to the current user // - Allow general access to ALL APPLICATION PACKAGES // - Allow read/write access to low integrity ssdl += L"D:(D;;GA;;;NU)(A;;GA;;;SY)(A;;GA;;;BA)"; if (SystemUtil::IsWindows8OrLater()) { ssdl += L"(A;;GA;;;AC)"; } ssdl += allow_user; if (SystemUtil::IsVistaOrLater()) { ssdl += allow_rw_low_integrity; } break;
Mozc を Windows 8 対応させるにあたって,最も重要だったのはこの一行だといっても過言ではない.
TSF 再対応
Windows 8 の没入型 UI では TSF ベースの IME (正確には Text Input Processor; TIP) 以外は使えないというのは割と知られた話.しかし実際の ところ迫害はこれにとどまらず,デスクトップモードでも IMM32 ベースの IME には次のような制限がある.
- 言語バー API を使用して,通知領域にアイコンを表示できない
- 言語設定から IME の設定画面を開けない
正直 Windows 8 では IMM32 ベースの IME は現実的とは言えないんじゃなかろうか.
このような理由もあって,Mozc を TSF に再対応させるのは割と早いうちから決心していた.もっとも,プロセス間通信の問題の方がより頭が痛かったので TSF の問題は割と放置気味だった.
プロセス間通信の問題が片付いて,Chromium の TSF 対応も一段落しところで,一人で淡々と TSF 対応を開始.それも無事 12 月中にすべてリリース.短期間に大量のコードレビューをこなしてくれた同僚に感謝.
こうして,IMM32/TSF との関わりがまた増えた.
- 学生時代に C# で TSF ベースの IME を途中まで作る
- 学生時代に Windows Vista 向け TSF 対応記事を書いたり CEDEC で講演したり
- 入社後,TSF で書かれていた初代 Mozc クライアントの開発を手伝う
- Windows XP 環境での CUAS に絶望し,IMM32 で Mozc クライアントをゼロから書き直す
- Chromium の TSF 対応を指揮
- Windows 8 向けに Mozc クライアントを TSF で書き直す (New!)
今回書き散らかしたコードはこのあたりに見ることができる.
https://code.google.com/p/mozc/source/browse/trunk/src/#src%2Fwin32%2Ftip
vcbuild から Ninja への移行
2012 年末,TSF 対応コードを一通りリリースし終わった後,同僚たちが休暇モードに入るのを横目に始めた年末ビルドパイプライン大掃除.
Mozc の Windows ビルドは,gyp のおかげで柔軟性が高く,ターゲットとなる Visual C++ のバージョンを変更するのは容易である.実際手元の開発では Visual C++ 2012 + Visual Assist X で快適開発ということが割と簡単にできている.一方,ビルドサーバーはいまだに Visual C++ 2008 を使っていた.これに関して最近以下のような懸念点があった.
- Chromium がデフォルトコンパイラを Visual C++ 2008 から Visual C++ 2010 に移行した
- Visual C++ 2010 になると,nullptr や auto が使えるようになる
そんなわけで,Mozc のデフォルトコンパイラを Visual C++ 2008 から Visual C++ 2010 に変更しようと思い立つ.
この変更で問題になるのは,従来コマンドラインからのビルドに使っていた vcbuild.exe が使えなくなり,.NET ベースの msbuild.exe に移行しなければならないことである.密閉型のビルドサーバーに .NET ベースの複雑な依存関係を持ち込むのはうれしくない.そこで,最近 Chromium でも併用されている ninja を使ってみることにした.
Ninja は,当時 Chromium チーム に在籍していた Evan Martin による make 代替ツールで,gyp や CMake のようなツールから自動生成されたビルド設定を読み込むことを前提に,とにかく高速に動作することを目指している.Ninja は Chromium 開発で多用されているだけでなく,最近は LLVM のような CMake 利用プロジェクトにもファンを広げているようだ.今回 vcbuild.exe ではなく Ninja を採用したもう一つの理由は,社内で勢いを持ちつつあるツールにはなるべく乗っかっておくという経験則もある.困ったときに聞きやすいし,自分の経験が同僚の役に立つこともある.
もっとも,Chromium 付随プロジェクトにありがちな話として,Chromium が必要になった部分だけ実装され,他は未実装というのは今回も同じ.Mozc を gyp + Ninja + Visual C++ 2010 で快適にビルドするには,gyp の Ninja 向けジェネレータ側にいくつか追加実装を行う必要があった.12 月頃せっせとパッチをアップストリームしている姿を以下に見ることができる.
移行は無事予定していた期間で終わり,現在の Mozc のビルドサーバーは gyp + Ninja + Visual C++ 2010 で動いている.