NyaRuRuが地球にいたころ

Android 9.0 に追加した API

Mon, 12 Nov 2018 01:43:47 +0900

github.com github.com

Android 8.1 に追加した API

Sun, 10 Dec 2017 17:34:07 +0900

github.com

Android 8.0 Oreo に追加した API

Fri, 25 Aug 2017 13:16:44 +0900

github.com

EditorInfo#IME_FLAG_NO_PERSONALIZED_LEARNING

2015 年やったこと - Mozc 編

Tue, 03 Jan 2017 15:38:42 +0900

1 年遅れぐらいになりますが，OSS Mozc 関係で 2015 年にやったことのまとめです．

空き時間を利用したプロダクトチーム外からのコミットということで，新規機能に関しては引き続き何も行っていません．前年と同じく OSS プロジェクトとしての環境整備と技術的負債の解消に注力した年でした．

以下が主な活動内容です．

Google Code (Subversion) から GitHub (git) への移行を完了
- 過去のコミット履歴を可能な限り維持
- ドキュメントを Markdown で書き直す
- Travis CI および AppVeyor を利用し，サポートしている全プラットフォームについて CI (Continuous Integration) を実現
  - Android
  - Linux desktop
  - NaCl
  - Windows
  - macOS
コードの簡略化
- プロダクションに使われなかった実験的コードの削除
- サポートを終了した古い OS 向けコードの削除
- 積極的にコンパイラをアップグレードし，C++ 11 のライブラリでコードを書き換え
  - Windows 環境は Visual C++ 2010 から 2013 を経て 2015 へ
    - インストーラの Universal CRT 対応
  - 非 Windows 環境は GCC から Clang / libc++ に移行
  - base/hash_tables.h を std::unordered_map / std::unordered_set に置き換え
  - mozc::scoped_ptr<T> を std::unique_ptr<T> に置き換え
Windows 10 向けの緊急性の高い問題の修正

コミット単位でみる作業まとめ

Windows XP 向けコードの削除

以前は最低サポート環境が Windows XP であったため，Windows Vista 以降に追加された API は GetProcAddress で動的にリンクするというスタイルで統一されていました．Windows XP 廃止後も同様のコードは動くことは動くのですが，コードが不必要に長くなるだけでなく，Loader Lock に代表されるような同期的モジュール解決の問題すらも不必要に呼び込んでしまいます．そこで，Windows Vista 以降に追加された API に関しても可能な限り暗黙的なリンク (Implicit Linking) に変更したのが主な変更内容です．

少し冒険してみた点としては，DLL の Import Library が提供されない input.dll についても，ビルドルールを工夫して暗黙的にリンクするようにしてみたということでしょうか．基本的には DLL から「正しい」LIB ファイルを作るにはと同じことを行っています．

Android 版の不要なコードの削除

サポートバージョンを上げたことにより不要になったコードを削除しました．

Visual C++ 2013 への移行

Mozc の Windows 向けビルドは，2015 年始めの時点では依然として Visual C++ 2010 を使用しており，これが C++ 11 移行の大きな障害となっていました．これをまずは Visual C++ 2013 段階までアップグレードするという試みです．これに付随して，Windows Kit (Windows SDK) 8.1 に追加されたライブラリや定数を使ったコードの簡略化も行いました．

この過程で遂に実現できたもののひとつに，NOMINMAX マクロをプロジェクト全体に適用することに成功した，というものがあります．そうです，<windows.h> を include するだけで，min/max というプリプロセッサマクロが定義されてしまうという問題が，commit 2cc1a055 によってついに過去のものとなったのでした．

Visual C++ 2015 への移行準備

2015 年の年末にかけて，さらに Visual C++ 2013 から Visual C++ 2015 への移行の下準備を行いました．移行の完成は 2016 年を待つことになりますが，2015 年の段階である程度の下準備 (Google Test や Protocol Buffers のアップデート等) を完了することができました．

C++ 11 対応

Visual C++ 2013 への移行でいよいよ C++ 11 対応の目途がたったことから，まずは全プラットフォームで C++ 11 が前提とできるようにビルドルールの変更等と行いました．この過程で STLPort を利用した Android ビルドを非サポートとしたり，非 Windows 環境のデフォルトコンパイラを Clang に統一したりといった変更も行っており，全体としてはビルドルールの簡略化に貢献できたものを考えています．

その後，実際に C++ 11 の新しいライブラリを用いて以下のような置き換えを行いました．技術的に難しいところはないものの，単純に多数のファイルを変更する必要があるため，時間に余裕があるときでないとなかなか難しい作業です．

base/hash_tables.h を std::unordered_map / std::unordered_set に置き換え
mozc::scoped_ptr<T> を std::unique_ptr<T> に置き換え

実験的コードの削除

Remove unused code from mozc_tool · google/mozc@51b1f78 · GitHub

もしかしたら将来使うかも，と導入したものの，結局プロダクションで使われなかったコードの削除も行いました．例えば上記コミットで削除されているコードは，1,000 行以上もありながら Windows 専用かつプロダクションでは一度も使われていないという正真正銘デッドコードです．

ibus-mozc 廃止に向けた下準備

予定されていた ibus-mozc の廃止は結局 2015 年中に行われませんでしたが，そのための下準備としていくつか ibus-mozc 関連のコードのクリーンアップを行っています．

一番入れたかった変更は commit 7a129e65 で，mozc_server 中にある ibus-mozc 専用コードを今のうちに削除しておくというものです．このコードは，IMR_QUERYCHARPOSITION や NSTextInputClient firstRect と同様の機能をなんとか Gtk+ IM Module 上に実現しようとしたものの名残で，クライアントコードはなるべく簡潔にするという Mozc の設計思想に基づき mozc_server 側にエミュレーションコードが実装されました．しかしながら，Mozc Issue #243 で議論されているように本質的に解決できないコーナーケースが存在すること，および ibus-mozc 以外では使用されていないこと，という 2 点の理由から，ibus-mozc 廃止前に完全に削除しておきたかったのでした．

GitHub への移行と Continuous Integration (CI) の整備

Google Code のサービスを終了にともない，OSS Mozc についても GitHub への移行を行うこととなりました．当時は私自身あまり git に慣れていなかったこともあり，Subversion から git への移行をあれこれ試行錯誤するのにずいぶんと時間を使ったように思います．

とはいえ移行が済んだあとは GitHub のエコシステムに感心するばかりでした．特に CI については最終的にサポートしている全プラットフォームについて自動ビルドをセットアップすることができ，マルチプラットフォーム対応に価値を置いているプロジェクトとしては本当に助かっています．

Travis CI のセットアップ

AppVeyor のセットアップ

gclient から git submodule への移行

Windows 10 対応

Windows 10 で状況が変わった点についてもいくつか緊急的な修正を行いました．

言語バーが Store App でも使われるようになったことへの対処
サンドボックス下で実行されるアプリケーションから mozc_server プロセスを起動できないという制約が Windows 8.1 時代よりも目立つようになったため，いくつかの対症療法的な変更

不安定なテストの改善

Travis CI 上で不安定だったテストについて安定化を試みました．

透明度付き PNG ファイルを PBGRA32 形式の Bitmap ファイルの変換するツールを作成

Add a tool to convert PNG file to PBGRA32 BMP · google/mozc@73a8154 · GitHub

ちょうど 2015 年，会社のロゴが更新され，候補ウィンドウに表示される画像も変更する必要ができました．

Windows 版の mozc_renderer は，会社ロゴの表示に GDI の AlphaBlend API を利用しています．問題はこの API はいわゆる乗算済みアルファフォーマット (正確には PBGRA32 形式) を期待していることです．デザイナーさんから渡された PNG ファイルを PBGRA32 に変更する必要があったですが，適当なツールがみつからなかったので急遽作ったのがこちらのコードでした．

雑感

以前から興味のあった GitHub 上での作業や CI について一通り体験することができたのは非常に有意義でした．また，git filter-branch や git rebase を使ったコミット履歴の編集を学ぶ上でも良い機会でした．

一方，前年に引き続きメンテナンス作業に注力して実感したのは，ソフトウェアのメンテナンスというのは本当にコストがかかるというというものでした．OSS Mozc に関して言うと，以下の作業だけで年間 100 時間は軽くかかっています．

コンパイラのバージョンを上げる
依存するライブラリのバージョンを上げる
丁寧にリリースノートを書く
ドキュメントを最新の状態に維持する
Issure Tracker に報告された問題に丁寧に答える

自分の場合これらの作業に有給休暇 10 日分以上を消費していることになるわけで，今後も同程度の貢献が継続可能かというと大変に疑問です．各種 Linux ディストリビューションで OSS Mozc が採用されるのはありがたい一方，最大の不安は期待値が高くなりすぎることです．将来のメンテナンスも含めて，あくまで無保証で提供されているという点を今一度思い出していただければという次第．

過去の関連エントリ

Android 7.1 に追加した API

Wed, 07 Dec 2016 15:23:41 +0900

github.com github.com github.com github.com

BaseInputConnection#commitContent(android.view.inputmethod.InputContentInfo, int, android.os.Bundle)
EditorInfo#contentMimeTypes
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION
InputConnection#commitContent(android.view.inputmethod.InputContentInfo, int, android.os.Bundle)
InputConnectionWrapper#commitContent(android.view.inputmethod.InputContentInfo, int, android.os.Bundle)
InputContentInfo#InputContentInfo(android.net.Uri, android.content.ClipDescription)
InputContentInfo#InputContentInfo(android.net.Uri, android.content.ClipDescription, android.net.Uri)
InputContentInfo#describeContents()
InputContentInfo#getContentUri()
InputContentInfo#getDescription()
InputContentInfo#getLinkUri()
InputContentInfo#writeToParcel(android.os.Parcel, int)
InputContentInfo#CREATOR

Android 7.0 Nougat に追加した API

Wed, 24 Aug 2016 14:32:47 +0900

github.com

View#dispatchFinishTemporaryDetach()
View#dispatchStartTemporaryDetach()
View#isTemporarilyDetached()

github.com

InputConnection#closeConnection()
InputConnectionWrapper#closeConnection()
BaseInputConnection#closeConnection()

github.com

InputConnection#getHandler()
InputConnectionWrapper#getHandler()
BaseInputConnection#getHandler()

github.com

Settings#ACTION_KEYBOARD_LAYOUT_SETTINGS

github.com

TextView#getImeHintLocales()
TextView#setImeHintLocales()

github.com

LocaleSpan#LocaleSpan(LocaleList)
LocaleSpan#getLocales()

github.com

SuggestionSpan#getLocaleObject()

github.com

InputConnection#deleteSurroundingTextInCodePoints(int, int)

github.com

InputMethodManager#dispatchKeyEventFromInputMethod(View, KeyEvent)

github.com

InputMethodSubtype#getLanguageTag()
InputMethodSubtype.InputMethodSubtypeBuilder#setLanguageTag(String)
SpellCheckerSubtype#getLanguageTag()

github.com

EditorInfo#locales()

github.com

LocaleList#describeContents()
LocaleList#writeToParcel(Parcel, int)
LocaleList#CREATOR

Windows 10 Insider Preview Build 14332 実験ノート: ブラウザと IME のプライベートモード連携

Mon, 02 May 2016 11:26:50 +0900

Windows 10 Preview ビルド 14328 でお試しいただける日本語 IME の変更点について – Windows & Devices 開発統括部

入力履歴の管理が便利になりました。人に見られたくない履歴が候補リストに表示されて困った経験はありませんか？
プライベートモード（仮称）を使えば、その間に蓄積された入力履歴はモードの終了時には削除され、その後意図しない場面で表示されてしまうことを防ぐことができます。
プライベートモード（仮称）はIME のアイコンをクリックして表示されるメニューから「プライベートモード」を選択することでオン・オフすることができます。Edge や Internet Explorer で InPrivate ブラウズ機能をお使いの場合は、本機能が自動的にオン・オフされます。
プライベートモード（仮称）で蓄積された入力履歴はプライベートモードの間だけ有効となり、モードの終了時には削除されます。それまでにプライベートモード以外で蓄積されていた入力履歴のデータには影響ありません。

ブラウザと IME のプライベートモード連携は，自分にとっても時間があったらやれたらいいなぁと思っていた機能だったこともあって，週末を利用して少し調べてみました，がどうも時間切れっぽいのでメモだけでも残しておきます．想定読者はブラウザ開発者，IME 開発者，および IME API 開発者という感じですが，正直に言えば自分用のメモです．

この機能，名前に (仮称) が付いているようにまだまだフィードバックしだいで色々変わりうる段階と思われます．というわけでまだちょっと調べたりないのですが，実験したい人向けにメモでも残しておく次第です．

疑問点

そもそも Internet Explorer / Edge と MS-IME はどのようなプロトコルでこの動作を行っているのか?
サードパーティ製のブラウザと MS-IME の組み合わせで同じことができるか?
Internet Explorer / Edge とサードパーティー製の IME で同じことができるか?

今回の調査結果

そもそも Internet Explorer / Edge と MS-IME はどのようなプロトコルでこの動作を行っているのか?

時間内に絞り込み切れませんでした．無念……

サードパーティ製のブラウザと MS-IME の組み合わせで同じことができるか?

上の結果が確定しなかったため確たる結論に至れず．残念……

Internet Explorer / Edge とサードパーティー製の IME で同じことができるか?

公開 API のみで，InPrivate モードの検出が可能であることまでは確認．少なくとも見かけ上は可能．

調べたこと

ITfTextInputProcessorEx::ActivateEx に指定される flags は，InPrivate かどうかで変化するか?
ITfThreadMgr::GetGlobalCompartment → ITfCompartmentMgr::EnumCompartments の結果は InPrivate かどうかで変化するか?
ITfThreadMgr::QueryInterface → ITfCompartmentMgr::EnumCompartments の結果は InPrivate かどうかで変化するか?
ITfDocumentMgr::QueryInterface → ITfCompartmentMgr::EnumCompartments の結果は InPrivate かどうかで変化するか?
ITfContext::QueryInterface → ITfCompartmentMgr::EnumCompartments の結果は InPrivate かどうかで変化するか?
ITfContext::EnumProperties で列挙される ITfProperty に対応しそうなものはあるか?
Edge の設定する InputScope は InPrivate かどうかで変化するか?
InputScope の一種 IS_PRIVATE (== 61) で MS-IME は動作を変化させるか?
Windows 10 Anniversary SDK Preview Build 14332 の API ヘッダの差分および InPrivate と付いた API に関連しそうなものはあるか?

得られた知見

Build 14332 時点で，正式な InPrivate 連携 API が Text Services Framework (TSF) に存在するかどうかは疑わしい．InputScope を含め，TSF の API で観測可能な範囲内に InPrivate モードの有効無効を示唆するものは一切見つけられなかった．
Build 14332 時点で，InputScope の一種 IS_PRIVATE によって MS-IME をプライベートモードにすることはできなかった．
Internet Explorer であれば，ieframe.dll のエクスポート関数 IEIsInPrivateBrowsing が依然として利用可能．ただしこの API は Edge のプロセスには読み込まれない．
Windows 10 SDK では，ProcessInPrivateInfo という列挙値が processthreadsapi.h に追加されている (少なくとも 10.0.10586.0 SDK の時点で既に存在する)．

typedef enum _PROCESS_INFORMATION_CLASS {
    ProcessMemoryPriority,
    ProcessMemoryExhaustionInfo,
    ProcessAppMemoryInfo,
    ProcessInPrivateInfo,
    ProcessInformationClassMax
} PROCESS_INFORMATION_CLASS;

Build 14332 時点で，以下のコードは Internet Explorer および Edge 共に InPrivate モードのみ true を返す．

bool is_process_in_private() {
  BYTE value = 0;
  if (!::GetProcessInformation(GetCurrentProcess(),
                               ProcessInPrivateInfo,
                               &value,
                               sizeof(value)) {
    return false;
  }
  return value != 0;
}

フィードバックアイディア

ちょっと裏付け不足でまだ未登録なのですが，概ね以下の点についてもうちょい調べてみないとなーと思っております．

プライベートモード連携に関しては，TSF の公開 API 内で完結させ，サードパーティー製ブラウザおよびサードパーティー製 IME との相互運用性に配慮して欲しい．ファーストパーティ製ブラウザおよびファーストパーティ製 IME の間のみで使われるプライベートプロトコルは好ましくない．
ProcessInPrivateInfo は，現状取得のみが可能なように見える．これに該当する特殊プロセスの作成に非公開 API が必要なのであれば，ファーストパーティ製ブラウザのみがそれを使用可能という状況は好ましくない．

改定履歴

2016-05-02: ProcessInPrivateInfo の追加時期について表現を変更．少なくとも 10.0.10586.0 SDK の時点で存在する．

My OSS Wish List

Mon, 14 Sep 2015 05:21:02 +0900

業務外にパッチを書いたりしている OSS プロジェクト，だいぶやりたいことが溜まっているので，優先順位をつける意味でもまとめてみた．業務と基本無関係なので，代わりにやっていただくのは大歓迎．なので以下は Wish List ということにしておきたい．

OSS Mozc 関係

[Mozc] Windows 版向けのインストーラーをビルドできるようにする

2013 年に Windows 版のコードを概ねオープンソース化したときに，面倒で後回しにしたのがこの部分．プロダクト版の WiX スクリプトは実際公開済みではあるのだけど，自動アップデート関係の設定等もここで行っているため OSS 版のインストーラにそのまま転用できなくなっている．技術的な障害は何もなく，OSS 版向きでない処理を取り除くだけ，なんだけどずるずるとはや 2 年半ぐらい．

やること．

OSS Mozc 向けに，余計なものを取り除いた WiX スクリプトを書く
ビルドに必要な WiX のインストール方法を決める．OSS Mozc のリポジトリにチェックインしてしまうか，choco install wixtoolset あたりを使う．

[Mozc] DirectWrite を使うと真っ白になる問題を再現させる

候補ウィンドウの DirectWrite で表示するというコードを実装したのがだいぶ前の 2013 年 12 月ごろ．先日こいつが安定版に取り込まれ，それなりの数のユーザーにリリースされたところ，文字が全く表示されなくなるという問題が各所で起こることが判明．急遽該当コードを無効化するという事態に．報告を読む限り Windows 7 環境限定っぽいのですが手元で再現できていないので詳しいことはよくわからず．

やること．

再現環境を入手する
Mozc の実装に問題があるかどうかを調査する．問題があれば修正する．
もし環境側の問題であれば，それを検出する方法があるか調査する．
DirectWrite を用いた表示を無効化する設定を設定ダイアログに追加するべきか検討する．必要があればその実装．

[Mozc] ソースコードのチェックアウトプロセスから Subversion 依存を取り除く

Mozc Issue #299 参照．技術的な障害は何もなく，淡々と手を動かせば終わるはず．

[Mozc] 依存する外部リポジトリの管理を gclient から Git submodule に変更

Subversion 依存が取り除かれれば，あとは機械的に対応可能．

[Mozc] ibus-mozc の削除

Mozc Issue #287 及び Mozc Issue #194 参照．これは割と自分の都合でお願いして削除することを決めてもらった話なので，早いところ何とかしたい．

ibus-mozc に関しては主に 2 つの理由からサポートをやめたいと思っていた．ひとつはメンテナー不在という問題，もうひとつは互換性問題の多発による周辺プロジェクトの疲弊がある．

メンテナー不在に関しては単純で，自分の空き時間の使い道としては優先順位が高くない，というのが理由である．自分が OSS Mozc のメンテナンスを引き受け始めたころには，既に Chromium OS は IBus の使用をやめており，ibus-mozc を業務でメンテナンスする人間はいなかった．自分の場合 OSS 関係のプロジェクトに関しては基本的に業務外時間で面倒を見ていて，そのため土日にできる範囲で作業するというスタンスを取っている．日本語入力については，Windows と Android であれば日常的に使っているという意味もあってまだ興味が持てるものの，Linux Desktop 上で日本語入力することは基本的にない．そのため，既知のバグを概ね直しきったところで手を引くべきだと考えていた． Mozc Issue #194 という Issue を立てメンテナーを社内外から募集してみたのが 2 年ほど前．残念ながら特に引き取り手は現れなかったので，まだ作業する余裕があるうちにコードを削除してしまおうというのが現在の考えである．というものの実際ここ数ヶ月は時間がとれずに作業が進んでいなかったので，もう少し早く始めていれば良かったのかもしれない．

互換性問題に関しては，複雑だ． IBus 1.4 あたりから，IBus の様々な処理が非同期プロセス間呼び出しとして実装されているのだけど，自分が普段使っているアプリケーションを中心にこれが何度も互換性問題を引き起こしている．

自分の理解が正しければ，もともと Chromium OS でのパフォーマンスを稼ぐために寄せられたパッチ群がもとで ibus が非同期処理を多用し始めた，という歴史だったように思う．とすれば不幸としか言いようがない．とはいえ同僚が今もこの件で時間を消費していることを考えると，多くのユーザーには IBus 以外の実装に移って欲しいという気持ちもある．心境としては複雑ではあるのだけど．

やること．

社内リポジトリで変更済みの ibus-mozc 関係の更新を全て OSS 化
ibus-mozc 関係のコードを全削除
fcitx-mozc 等の代替ソフトウェアに足りない機能があれば，可能な範囲でそちらへの協力．
IBus の非同期モードが問題を引き起こしている周辺プロジェクトへのできる限りの協力．

[Mozc] tsf-mozc の Windows 10 関係の互換性問題の調査

やること．

Windows 10 環境を作る
色々と言われている問題が再現するか調査．再現するなら直す．

[Mozc] Windows 環境での縦書きサポート

ずっと言われているのでどこかで時間を取って何とかしたい．候補ウィンドウ側に関してはハッカソンで一回動くところまで作ったことがあって，2 日もあればそこまではできることは確認済み．問題は変換エンジン側で，縦書き時にカーソルキーの意味が変わるという動作をきちんとプロトコルレベルで定義する必要がある．

やること．

候補ウィンドウの縦書きを実装．テストも追加．
縦書きと横書きでキーマップを入れ替えるためのプロトコルを定義する

[Mozc] Qt 5.x への移行

Mozc では依然として Qt 4.8.x 系を使っているのだけど，いくつかの理由から 5.x へのアップグレードを急ぐ必要がある．

Qt 4.8.x では Windows の HiDPI 環境をサポートできない．これはだいぶ深刻．
様々な Linux ディストリビューションが Qt 4.x のサポートを打ち切りたがっている．

基本的には Qt のアップグレードでビルドが通らなくなるところをひたすら直していく以外にないのだけど，Qt にパッチを当てずに移行可能かはまだ未知数．また，ビルドが通っても特定ユーザー環境で問題が発生する可能性もあり，先は長い．

[Mozc] Linux および Android 向け Continuous Build / Test 環境の整備．

現在の OSS Mozc は，Windows と OS X に関してある程度の Continuous Build / Test 環境が有効化されているものの，Travis CI が長らく Linux 12.04 にとどまっているため Linux および Android に関しては有効化できていなかった．最近 Travis CI が Docker をサポートを追加したらしく，そろそろ何とかなりそうな気がしている．

[Mozc] その他溜まっている OSS Mozc の更新

Mozc の開発は現在も社内リポジトリが master． OSS リポジトリの更新タイミングは，基本的に誰かの手が空いているときであって，ここ 1 年半ぐらいは自分が土日及び休暇の空き時間を利用して行っている．で，ここのところ時間がとりにくかったのもあって，OSS 化すべき更新が 7 ヶ月分ぐらい溜まっている．

やること．

作業のさらなる自動化．
ビルド確認の手間を減らすべく CI の拡充．

gclient から git submodule に移行すれば，GitHub 界隈のエコシステムをもうちょっとうまいこと活用できるんではないかと期待．

GYP 関係

[GYP] Revert された 540e4b1e665 の再有効化

これは完全に巻き込まれ案件なのだけど，個人的に気になっていて何とかしたい．以下時系列．

いくつかのビルドツールで問題を起こすことから，GYP は同一ビルドターゲット内に (ディレクトリだけ異なる) 同名ファイルが存在することを許さない．一方，社内外からこの制限が不便だという声があがっていた．
数年前，社内リポジトリにとりこまれたバージョンの GYP に，このファイル名チェックを回避するオプションを追加するローカルパッチが提案され，メンテナンスを担当していた自分はうかつにもこれを受け入れてしまう．以後，アップデートのたびにパッチを当てなおす必要がうまれメンテナンスコストが増大．
自分が中心となって，GYP upstream に同等のオプションを実装 GYP r1947．
上記機能が実装された GYP を社内にインポート．いくつかのプロジェクトがそのオプションを有効にする．
とある Chromium 開発者，この制限を完全に取り除くパッチを提案．受け入れられる．GYP r1993．
上記機能が実装された GYP を社内にインポート．不要になったオプションは削除される．
GYP r1993 が，Chromium のビルドで警告を引き起こすことが分かり revert される．GYP c0cf1f22eb

というわけで，最新の GYP をそのまま社内にインポートすると，いくつかのプロジェクトでビルドが壊れることが分かっている．何とかしたい．この問題，自分の理解では OS X の libtools の制限によるもので，XCode では技巧的な方法で回避済み．同じことを GYP の Ninja ジェネレータでも実装すれば済む話，なんだけど時間が取れずまだ何もできていない．

が，こうやって書いてみると，自分的には最新の GYP がインポートできれば十分なので，もう一回社内の該当プロジェクトにオプション追加すれば良いだけのような気もしてきた……

やること．

自分で直すまたは代わりにやってくれる人をみつける．

Chromium 関係

[Chromium] Web MIDI の実装に Windows 10 の新 MIDI API が使えるか調査

Chromium Issue #512433 参照． Windows 10 には MIDI API が追加されていて，Windows 版 Chromium の Web MIDI がもっと使いやすくなる可能性がある．

やること．

自分でやるまたは代わりにやってくれる人をみつける．
自分でやる場合，まずは Windows 10 環境を作る．

[Chromium] その他 Chromium の Web MIDI サポートで担当者募集中バグの修正

2015 年 9 月 13 日現在 24 個の担当者募集中バグがある．しかしこれはちょっと分量的につらいかも．

やること．

自分でやるまたは代わりにやってくれる人をみつける．
MIDI の meetup 等で協力者を募る．

[Chromium] Android Lollipop で追加された新 IME API のサポート

Chromium Issue #424866 参照．去年 Android Lollipop に追加した CursorAnchorInfo API，Chromium でまだサポートされていないのでなんとかしたい．実はパッチまでは既にあるのだけど，Chromium 特有のレビューコスト・パフォーマンスに関する敷居の高さに阻まれ中断中．これはひょっとしたら業務時間中にやりきる口実を見つけられる可能性もゼロではないのだけど，その時間を Android 本体に使ったほうがどう考えても合理的なので早いところ担当してくれる Chromium 関係者を見つけるべきだと思っている．

やること．

代わりにやってくれる人をみつける．あるいは気合を入れて自分でやりきる．

Firefox 関係

[Firefox] Android Lollipop で追加された新 IME API のサポート

Mozilla Issue #1094729 参照．去年 Android Lollipop に追加した CursorAnchorInfo API，Firefox でまだサポートされていないのでサポートされて欲しい．新 IME API が自社製品でしか使われないというシナリオは避けたい．心の底から．それが Microsoft ウォッチャーとして Text Services Framework から得た教訓なのですな．

やること．

あの手この手で実装してもらう．あるいは気合を入れて自分で実装してパッチを取り込んでもらう．
新 API の解説を書く．
How the input method can request 'updateCursor' event? - Stack Overflow に付いている回答に補足する形で，各種ブラウザの実装状況についてコメントする．

Docker 上に IPython Notebook 実行環境を作って DeepDream を動かす

Sun, 05 Jul 2015 09:21:07 +0900

DeepDream を動かしてみようと思ったら 9 割ぐらい IPython Notebook と必要なライブラリの環境整備だったのでそのまとめ．

作業日
- 2015 年 7 月 4 日
作業前の筆者の状況及びそこから導かれる想定読者
- IPython Notebook を使ったことがない．環境構築もしたことがない．
  - Mathematica は使ったことがあるかもしれない．
- docker コマンドが動く Linux Desktop 環境を，実機，または VM 内 (Windows にインストールした VMWare 等) にもっている．
- Deep Neural Network と呼ばれる技術について，特に知らないし，特に自分で手を動かして何かしたこもなく，業務でも当面使う予定はない．
- インターネットからの数 GB 程度のデータダウンロードが可能である．
目標
- docker コマンドが動く環境ならどこでも DeepDream のチュートリアルを実行できるようになる．
目標ではない
- Deep Neural Network と呼ばれる技術について，何らかの知見を得る．

Deep Neural Network 素人であるところの筆者が理解できた範囲の話の背景

6 月中旬ごろ，不思議な画像を生み出す画像処理アルゴリズムが Google Brain Project に所属する研究者たちによって公表されました．

Inceptionism: Going Deeper into Neural Networks

Inceptionism の背景ですが，たとえば 10 段から 30 段にもなるニューラルネットワークが存在したとき，各段の振る舞いが実際に何をやっているのかは自明な話ではありません．この疑問に対する実験の 1 つとして，特定の段のニューロンの特性を使って入力画像を強調してみたらどうなるか，というのがどうも Inceptionism の意義というか立ち位置のようです．

実際，ランダムノイズ画像に上記強調処理を行った結果何やら物体めいたものが見えてきたというのが，ブログの前半で述べられていることです．

So here’s one surprise: neural networks that were trained to discriminate between different kinds of images have quite a bit of the information needed to generate images too.

さて，異なる画像を識別するように訓練されたニューラルネットワークは，画像を生成するために必要な情報をある程度持っているのであれば，これを使って面白画像が生成できないかというのが後半パートです．

Inceptionism ブログ記事では，実際の画像強調処理の具体的なアルゴリズムは記述されていませんでしたが，7月1日になって，IPython Notebook というインタラクティブな Python 実行環境を使ってチュートリアル的に行う方法が公開されました．この GitHub リポジトリの名前が DeepDream です．

ちなみに DeepDream として新たに公開されたのは，数十行程度の反復処理アルゴリズムだけで，Inceptionism ブログ記事の画像を再現するために公開が必要だった本当にこの反復処理アルゴリズムだけであったことが分かります． DeepDream では，GoogLeNet という訓練済みニューラルネットワークを用いており，このデータは 2014 年 12 月に公開済みでした．

さて問題は，普段この種の処理と無縁な生活をしている人間にとって，まずこの IPython Notebook の実行環境を (DeepDream に必要なライブラリを揃えつつ) 整えるのが大変面倒だ，ということです．というわけで Docker の出番です．

なぜ Docker を使うのか

まず最初になぜ Docker を選んだのかについて書いておきます．筆者の気づいた範囲で，DeepDream の実行環境を整えるにあたって面倒なのは次のような点です:

Caffe というライブラリを正しくインストール・設定する必要がある
- GoogLeNet のデータセットが含まれていなければならない
- 特定 GPU / ドライバへの依存を避けるために，Caffe は CPU 処理モードになっていて欲しい
pip コマンドで複数の Python ライブラリをインストールする必要がある
IPython Notebook はブラウザをフロントエンドに使用するため，実行環境にはブラウザがインストールされている必要がある

これらの処理を，普段使用している Linux Desktop 環境を汚さず，かつ (なるべく) 再現可能な形で，Linux ディストリビューション間の非互換性に煩わされることなく行いたいというのが Docker を使用する目的です． Docker を用いることで，仮に IPython Notebook 実行環境を予期せず壊してしまっても，すぐに最初からやり直すことが可能です．また，いったんコンテナイメージを作ってしまえば，ホスト環境が変わってもすぐに同じ実験を行うことが可能です．

ほんと，Docker みたいなのが自分の学生時代にも欲しかったものです……

(Docker) ホスト Linux

以下では Ubuntu 14.04.1 64-bit 版を想定していますが，必要な環境は Docker コンテナ内に用意するため，ホスト環境に要求するのは以下の 2 点です．

Docker が動く
(表示用のブラウザを X11 経由でホスト画面に表示するため) GUI ログイン可能である

Docker のセットアップについては詳しく述べませんので，Supported installation - Docker から辿ってインストールしてみてください．

なお，以下では sudo なしで docker コマンドが実行可能なように設定されていることを前提に書かれています．その設定を望まない場合は各自 sudo を付けて読み替えてください．

Docker コンテナのダウンロードとインストール

必要なコンテナは DockerHub にアップロード済みです．

docker pull nyaruru/deepdream-ipython-notebook

セキュリティが気になる人・自分で再現を試みたい人は，deepdream-ipython-notebook/dockerfile/ で Dockerfile を確認することができます．

何か問題・改善点がありましたら GitHub 上のNyaRuRu/deepdream-ipython-notebook までお知らせください．また，今回は github.com/visionai/clouddream をベースイメージに使わせていただいており，Caffe のセットアップ等大部分の処理はそちらで行われています．

Docker コンテナの実行

まず，コンテナ内からホストへの X11 接続を許可しておきます．

xhost +local:

DeepDream を一通り実行するだけであれば，以下のように docker コマンドを実行するだけで十分です．

docker run -i -t --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix:ro nyaruru/deepdream-ipython-notebook

上手くいけば，コンテナ内で Firefox が起動され，そのウィンドウがホスト GUI 環境に表示されるはずです．終了するには，ターミナル上で Ctrl-C を実行すれば OK です．

docker コンテナ起動時に --rm オプションを付けていることに注意してください．この結果，コンテナ終了時に作業内容は全て失われますが，もう一度実行しなおすことで確実に動く状態からやり直すことが可能です．

DeepDream IPython Notebook チュートリアルの実行

Docker コンテナを起動すると，すでに IPython Notebook が起動しているはずです．DeepDream のディレクトリが表示されているはずですので，そこから dream.ipynb を選択します．

IPython Notebook が表示されます．Mathematica 経験者であれば，あの Notebook みたいなもの，と思えばとっつきやすいかも．

上の方に ▸ ボタンがありますので，それを押していくとチュートリアルの内容が上から順に実行されてきます．

以下の箇所を実行することで，チュートリアルのサンプル設定での DeepDream が画像を強調処理していく様子をリアルタイムに見ていくことができます．

_=deepdream(net, img)

デフォルトのパラメータは，関数定義に書いてあるとおり以下のようになります．

ter_n=10
octave_n=4
octave_scale=1.4
end='inception_4c/output'

さらに DeepDream を楽しむために

パラメータを変える

こちらについても詳細についてはチュートリアルに書かれています．たとえば，

net.blobs.keys()

を実行することでニューロン層のリストが表示されます．強調処理に使う層を inception_3b/5x5_reduce に変更してみるというのが

_=deepdream(net, img, end='inception_3b/5x5_reduce')

の行っていることです．

ホスト環境のディレクトリを Docker コンテナ内に見せる

ここまで来ると，実際に色々な画像で実験してみたくなります． Docker のホストとコンテナでファイルをやり取りする方法はいくつかあるかと思いますが，ここでは -v オプションでホストの特定ディレクトリをコンテナ内に公開することにします．

docker run -i -t --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix:ro -v $HOME/Pictures:/opt/pictures nyaruru/deepdream-ipython-notebook

これで，ホスト環境の $HOME/Pictures がコンテナ内の /opt/pictures と共有されます．たとえば foobar.jpg を $HOME/Pictures に置いたとします．IPython Notebook のデータを読み込んでいる次の行を探してください．

img = np.float32(PIL.Image.open('sky1024px.jpg'))
showarray(img)

これを，

img = np.float32(PIL.Image.open('/opt/pictures/foobar.jpg'))
showarray(img)

に書き換え，フォーカスを合わせた状態で実行 ▸ ボタンを押します．これで画像が読み込めれば成功です．あとは改めて deepdream を行っている行を実行します．結果は，ブラウザの「画像に名前を付けて保存」で保存してもいいでしょうし，Python で

frame=deepdream(net, img)
PIL.Image.fromarray(np.uint8(frame)).save("/opt/pictures/foobare_result.jpb")

と書いても良いでしょう．

その他の実装

github.com/jcjohnson/cnn-vis にて，独立実装による Inceptionism の再現実験が試みられています．こちらでは，MIT Places データセットに対して訓練された GoogLeNet のデータを用いることで，建物に反応する (と思われる) ニューロン層を使った実験も行われています．

Future Work

今回の Dockerfile はあくまで IPython Notebook チュートリアルの実行を目標としているので，DeepDream の処理を動画に対して行ったり，GPU を使って高速化したりはまた別リポジトリで行いたいと思っています．

そのうえで，いくつか気になっている点としては，

Caffe が CPU モードで動くのはいいんだけど，CPU 1 コアしか使っていない気がする．
ホスト環境のファイル受け渡しが若干面倒なので何とかしたい．
ベースにしている Docker イメージから引き継いだ特性として，コンテナ内のユーザーが root なのが若干気にいらない．出来れば root でブラウザを動かしたくない．

あたりでしょうか．この辺はまた時間が取れたら見ていきたいところです，

Docker とか Caffe とか普段触ることがないので，詳しい方ぜひおすすめテクニック等教えてください．

2014 年やったこと - Mozc 編

Wed, 11 Feb 2015 18:30:43 +0900

いつもどおりコードが公開されている範囲で．

実は 2013 年にやっていたこと

OSS Mozc のアップデートタイミングの関係上，2013年やったこと - Mozc 編 - NyaRuRuが地球にいたころに載っていなかった内容です．概ね 2013 年末休暇シーズンに余暇としてやっていました．

Windows 版での候補ウィンドウのカラー絵文字対応

Mozc チームを離れる直前，休暇シーズンということもあって久しぶりに自分の書きたいコードでも書くかと言うことでやってみたのがこのカラー絵文字対応です．

作業のほとんどは mozc_renderer (独立したプロセスとして動く，候補ウィンドウ表示用プロセス) 内の文字表示処理を DirectWrite に対応させることでした．カラー絵文字専用に追加したコードは数行です．
r192 にてリリース．
変更の大半は renderer/win32/text_renderer.cc にまとまっています．

候補ウィンドウの DirectWrite 対応

思い起こせば 2009 年，Mozc の候補ウィンドウ表示を別プロセス化したころから DirectWrite を使うというアイディア自体はありました．緊急性と重要性の高いタスクは他にいくらでもあったことからこのアイディアは長らく放置されていたのですが，カラー絵文字表示の副産物として 4 年越しの実現となります．Windows 8 以前の OS でも，高 DPI 環境ではそれなりにメリットがあるかもしれません．
r192 にてリリース．

ITfFnReconversion::GetReconversion 対応

tsf-mozc が ITfFnReconversion::GetReconversion をサポートしていなかったので実装してみた，というものです．ITfFnReconversion::GetReconversion を使用する一部アプリケーション以外でユーザーの目に見える変化はありません．

一番わかりやすいのは Microsoft Word で，文字を選択したあと右クリックすると，コンテキストメニュー内に再変換候補が表示されるようになります．

Mozc 内部のプロトコル的に再変換は対応済みだったので，あとは単純に実装するだけという内容でした．

2014 年にやったこと

2013 年 12 月末をもって所属的には Mozc チームを離れたこともあり，休日・休暇に作業できる内容であることというのを特に重視していた 2014 年でした．そんなわけで注目してみたのが，OSS 版周りの自主オープンソース活動でした．OSS としてみた Mozc プロジェクトは，特に対外的な締め切りもなく，本当に時間的に余裕があるときだけ作業するのに適しています．また，OSS 化後のソースコードについては個人の PC 環境で作業できるので，喫茶店や旅行先でコードを見たり変更したりしながらあれこれ試せるのも嬉しいポイントでした．

OSS Mozc を選んだもうひとつの理由としては，最近モバイル OS 向けに OSS Mozc をベースにした IME を作っていただけるケースが増えていて，少し応援してみたくなったというのもあります．数字的にも合計数百万インストールという規模で，OSS としてはまずまずの成果．間接的にモバイル IME 開発の活発化に貢献できるのであれば，休日の使い方としてはまずまず Mobile First かなと思った次第．

さて，2014 年のテーマとして個人的に興味があったのは，社内リポジトリから OSS リポジトリへに変更を移動するとき，そのコミット粒度を小さくするのは可能か，というものでした．

これまで OSS Mozc といえば，いわゆる "code drop" 方式でリリースされていました．開発自体は社内のリポジトリで行い，しかるべきタイミングに (たいていはプロプライタリな製品として社外にリリースされたあと)，開発されたソースコードを OSS として公開する，というものです．このとき問題になるのがコミットログで，OSS Mozc は様々な理由から変更は 1 つの SVN コミットにまとめられ，数千行から多いときは数万行の変更になることもありました．この巨大なコミットに含まれる変更点全てを把握するは開発者自身にとっても難しく，コミットログやリリースノートを書くときに苦労したのを憶えています．

そこで試してみることにしたのが，OSS 化して問題ない変更については，確認の上，個別のコミットとして OSS リポジトリに適宜反映させていくというものでした．作業自体は休日等の空き時間を利用して行っています．2014年5月24日から12月25日の間に，222 個のコミットを行いました (うち 81 コミットは 2014年12月6日から12月31日までの間，有給消化の年末休暇中に行っています)．

2014年5月24日から12月25日の間のコミット一覧

残念ながら r467 だけは従来通りの巨大コミットになってしまいましたが，これは Android 向け新機能が多数含まれるため分けきれなかったというのが理由です．それ以前の 218 個のコミットはコミットメッセージと変更が (概ね) 対応した通常のコミットに見えるようになっています．変更の粒度を下げたことで，最後の巨大コミットを待つことなく，27 個のバグを閉じることができました．

この作業，個人的に何が新鮮に感じたかというと，それがある種の <コミット後レビュー> だったことです (このあたりの話，コードレビューいろいろ - steps to phantasien を先に読むことをおすすめ)．会社に入って以来，<コミット前レビュー> は 6 年ぐらいやってきたものの，<コミット後レビュー> を継続的にやったのはこれが初めてでした．
感想 1．既にコミット済みのコードに対するレビューなので，気になるところを修正するとそれが別コミットになってしまう．
感想 2．ある程度の期間のコミットの差分をまとめて見たことで，無駄なコードが増えたのに気付きやすくなる．以下典型的なケース．

ある問題に，A という方法で対処する
A という方法では完全に問題が解決できないことが分かり B という方法に切り替える

複数のコミットが数日から数週間の間に加えられていたとき．あとで全体の差分を見てみると不要な変更が残ってしまっているケースを数件発見．これは確かに <コミット前レビュー> で見つけにくいパターンかも．

まあそんなわけで新鮮でもあった細切れ OSS 化作業ですが，休日の時間を結構吸い取られる作業であったのも確かで，今後どうするかはまだ決めていません．

一方，OSS 版リポジトリを活用し，実際にバグを直したり技術的負債を返済したりといったことも行っていました．以下は，そんな休日自主オープンソース活動についてです．

TF_E_NOLAYOUT 問題

Mozilla Japan の中野さんから報告していただいた問題です．調査の結果，以下のような OS 側の問題であることが分かりました．

TSF で書かれた IME (TIP) が ITfContextView::GetTextExt() を呼び出す．
TSF ランタイムがアプリケーションの実装する ITextStoreACP::GetTextExt() を呼び出す
アプリケーションが ITextStoreACP::GetTextExt() に対して TS_E_NOLAYOUT を返す
TSF ランタイムが戻り値を E_FAIL に書き換える
TSF で書かれた IME (TIP) が ITfContextView::GetTextExt() の結果として E_FAIL を受け取る

開発元のサポートに相談したところ，ITfContextView::GetACPFromPoint() と ITfContextView:: GetRangeFromPoint() にはこの問題がないことが分かり，TS_E_NOLAYOUT が返されているかどうかの判定をこれらの API で行うという回避策をおすすめされました．その方針で tsf-mozc 側にて対処してみた，というのが一連の流れとなります．
r192 にてリリース．コード的には以下となります．
https://code.google.com/p/mozc/source/browse/trunk/src/win32/tip/tip_range_util.cc?r=192#231

HRESULT TipRangeUtil::GetTextExt(ITfContextView *context_view,
                                 TfEditCookie read_cookie,
                                 ITfRange *range,
                                 RECT *rect,
                                 bool *clipped) {
  BOOL clipped_result = FALSE;
  HRESULT hr = context_view->GetTextExt(
      read_cookie, range, rect, &clipped_result);
  if (clipped != nullptr) {
    *clipped = (clipped_result != FALSE);
  }
  // Due to a bug of TSF subsystem, as of Windows 8.1 and prior,
  // ITfContextView::GetTextExt never returns TF_E_NOLAYOUT even when an
  // application returns TS_E_NOLAYOUT in ITextStoreACP::GetTextExt. Since this
  // bug is specific to ITfContextView::GetTextExt, a possible workaround is
  // to also see the returned value of ITfContextView::GetRangeFromPoint.
  // If the attached application implements ITextStoreACP::GetACPFromPoint
  // consistently with ITfContextView::GetTextExt,, we can suspect if E_FAIL
  // returned from ITfContextView::GetTextExt comes from TF_E_NOLAYOUT.
  if (hr == E_FAIL) {
    // Depending on the internal design of an application, the implementation of
    // ITextStoreACP::GetACPFromPoint can easily be computationally expensive.
    // This is why we should carefully choose parameters passed to
    // ITfContextView::GetRangeFromPoint here.
    const POINT dummy_point = {
       numeric_limits<LONG>::min(), numeric_limits<LONG>::min()
    };
    CComPtr<ITfRange> dummy_range;
    const HRESULT next_hr = context_view->GetRangeFromPoint(
         read_cookie, &dummy_point, 0, &dummy_range);
    if (next_hr == TF_E_NOLAYOUT) {
      hr = TF_E_NOLAYOUT;
    }
  }
  return hr;
}

ちなみにこの問題，現在ベータテスト中の Windows 10 では OS 側で無事修正されている模様です．

Win10 + Nightly + Google日本語入力で試してみたところ、TSFの、ITextStoreACP::GetTextExt()で、TS_E_NOLAYOUTを返しても、TIPにE_FAILが返されてしまってたバグは修正されてるっぽい? #もずでぶ @NyaRuRu
— なかのん DAYS'' (@d_toybox) October 1, 2014

TSF を有効にした Firefox がフォーカスを失ったとき候補ウィンドウが表示されたままになる

tsf-mozc と TSF-aware Firefox の組み合わせで，文字入力中に別アプリケーションにフォーカスを移すと，Mozc の候補ウィンドウが表示されたままになるという問題です．
tsf-mozc 側で ITfThreadFocusSink::OnSetThreadFocus() と ITfThreadFocusSink::OnKillThreadFocus() を処理していなかったのが問題でした．
r192 にてリリース．

Issue 206: 特定ロケールの Windows 環境で prediction/dictionary_predictor.cc をビルドすると C2065 エラーで失敗する

https://code.google.com/p/mozc/issues/detail?id=206
Mozcの C++ で書かれたソースコードは基本的に BOM なし UTF-8 で統一されているのですが，過去何度もVisual C++ が C2065 エラーでコンパイルに失敗するというトラブルに見舞われて来ました．そこで発明された対処法が，とりあえず non-ASCII 文字は "" で囲む，というものです．
OSS Mozc の方に C2065 の報告が来たわけですが，今回も "" で囲って対処となりました．
r192 にてリリース．

Issue 215: mozc::Encryptor 実装のポータブル化

https://code.google.com/p/mozc/issues/detail?id=215
mozc::Encryptor というクラスの実装から，プラットフォーム別の処理を極力取り除いたというものです．
Mozc は，確定履歴などいくつかのローカルファイルを保存時に AES256 CBC モードで暗号化します (Design Doc 参照)
当時この実装はプラットフォームごとに異なっていて， Mac 版， NaCl 版，および Linux デスクトップ版 Mozc では OpenSSL が，Windows 版では Win32 Crypto APIが，そしてAndroid 版では javax.crypto.Cipher クラスが使われていました．
さて，話は 2014 年 2月22日にさかのぼります．当日 Mozilla Japan 東京オフィスで開かれていた FxOS コードリーディングミートアップ #4 にふらりと参加した筆者は，Mozc を Emscripten でビルドできないものかとあれこれ試し始めました．Mozc のビルドは概ね「近寄るべきではない程度に大変」の部類に属しますが，そうはいってもクロスコンパイルの必要な Android 対応と NaCl 対応は既にできているわけです．数時間もあれば最初の一歩ぐらいはなんとかなるだろうと軽い気持ちで始めたものの，結果的に最初の一歩すら踏み出せずに敗退することとなります．

そもそもOSS MozcはNDK使ったAndroid向けネイティブビルドもNaCl SDK使ったpNaClビルドも対応済みなのに，どうしてこうなった状態．
— NyaRuRu (@NyaRuRu) March 25, 2014

このとき最初の一歩として立ちふさがったのが，この OpenSSL 依存でした．以下に，当時私が参考にしようとしていた nacl-mozc の OpenSSL 依存部分を示します．
https://code.google.com/p/mozc/source/browse/trunk/src/base/base.gyp?r=185#508

    ['target_platform=="NaCl"', {
      'targets': [
        {
          'target_name': 'pepper_file_system_mock',
          'type': 'static_library',
          'sources': [
            'pepper_file_system_mock.cc',
          ],
          'dependencies': [
            'base.gyp:base',
          ],
        },
        {
          'target_name': 'openssl_crypto_aes',
          'type': 'static_library',
          'variables': {
            'openssl_dir%': '<(DEPTH)/third_party/openssl/openssl',
          },
          'direct_dependent_settings': {
            'defines': [
              'HAVE_OPENSSL=1',
            ],
            'include_dirs': [
              '<(gen_out_dir)/openssl/include',
              '<(openssl_dir)/include',
            ],
          },
          'cflags': [
            # Suppresses warnings in third_party codes.
            '-Wno-unused-value',
          ],
          'include_dirs': [
            '<(gen_out_dir)/openssl/include',
            '<(openssl_dir)',
            '<(openssl_dir)/crypto',
            '<(openssl_dir)/include',
          ],
          'hard_dependency': 1,
          'sources': [
            # The following files are the minumum set for 'encryptor.cc'
            '<(openssl_dir)/crypto/aes/aes_cbc.c',
            '<(openssl_dir)/crypto/aes/aes_core.c',
            '<(openssl_dir)/crypto/aes/aes_misc.c',
            '<(openssl_dir)/crypto/mem_clr.c',
            '<(openssl_dir)/crypto/modes/cbc128.c',
            '<(openssl_dir)/crypto/sha/sha1dgst.c',
            '<(openssl_dir)/crypto/sha/sha1_one.c',
            '<(openssl_dir)/crypto/sha/sha256.c',
            '<(openssl_dir)/crypto/sha/sha512.c',
            '<(openssl_dir)/crypto/sha/sha_dgst.c',
            '<(openssl_dir)/crypto/sha/sha_one.c',
          ],
          'dependencies': [
            'openssl_config',
          ],
          'export_dependent_settings': [
            'openssl_config',
          ],
        },
        {
          'target_name': 'openssl_config',
          'type': 'none',
          'actions': [
            {
              'action_name': 'openssl_config',
              'inputs': [
                'openssl_config.sh',
              ],
              'outputs': [
                '<(gen_out_dir)/openssl/include/openssl/opensslconf.h',
              ],
              'action': [
                'bash', 'openssl_config.sh', '<(gen_out_dir)', '$(abspath ./)',
              ],
            },
          ],
        },
      ]},
    ],
  ],
}

ここでやっているのは，OpenSSL のソースコードがダウンロード済みと仮定して，configure スクリプトを走らせ，ターゲットの toolchain でビルドする，というものです．asm.js 版 Mozc を作るにあたって，これとほぼ同様の作業を行う必要がありました．一方 Android 版も， JNI を使って javax.crypto.Cipher クラスの一部を C++ に公開するという，処理的にもビルド設定的にも非常に複雑な実装になっていることが分かりました．
実は Mozc がローカルにファイルを保存するときの暗号化処理は，"カジュアルな" 情報漏洩対策という何とも微妙な目的で導入されたという過去があります．デスクトップ版のみであった最初期は，この機能による複雑さの増加もまだ許容できたのかもしれませんが， Android 版や NaCl 版開発時に「がんばって移植すべき機能」のひとつになってしまったのは不幸でした．これらの環境では，システムの OpenSSL を単純に呼び出すといった方法が使えなかったため，ビルド時に OpenSSL 自体をビルドしたり，JNI コードを追加したりといった方法で対処されることとなりました．このがんばりは，予定されたスケジュールまでに製品をリリースするという点では有効でしたが，残ることになった複雑さはまさに技術的負債でした．
さて，よくよく処理内容を調べてみると，SHA1 と AES256 CBC の計算で，きちんと認証を受けた OS 固有実装を利用しようとした結果，物事が複雑化しまっていることがわかります．しかしながら，もともと "カジュアルな" 情報漏洩対策でしかない暗号化処理で，FIPS 認定にこだわるというのも変な話です．だったら自前で SHA1 と AES256 CBC を実装してしまえば，大幅にビルドが単純になるだろう，と始めてみたのがこの Issue 215 となります．
基本実装は r192 に含まれていますが，この時点では旧実装も残されていました．その後，r208，r209，r497 として旧実装は削除されています．
規格を読みながら有名アルゴリズムを実装するのは楽しい体験でした．計算結果の比較のために見ていた Chromium の SHA1 実装にバグを見つけるというおまけもありました (Chromium Issue 348333) ．4 月に OpenSSL の Heartbleed が盛り上がったのも，面白い偶然の一致です．
まとめると，以下のようなメリットがあったものと考えています．

実行時に依存するライブラリが少なくなる
ビルドが単純化される
プラットフォーム共通コードが増える
(OSS Mozc に GPL コードを組み合わせたい人にとっての)，潜在的なライセンス非互換問題のリスクが減る

Issue 211: 2 段階ビルドを廃止

https://code.google.com/p/mozc/issues/detail?id=211
従来，たとえば Android 版 Mozc の APK をビルドするときには，以下のようにコマンドを 3 回実行する必要がありました．

python build_mozc.py gyp --target_platform=Android
python build_mozc.py build_tools -c Release
python build_mozc.py build -c Debug_Android android/android.gyp:apk

これが，以下のようにコマンド 2 回でビルドできるようになった，というものです．

python build_mozc.py gyp --target_platform=Android
python build_mozc.py build -c Debug android/android.gyp:apk

Mozc のビルドが build_tools というコマンドと build の 2 段階に分けられたのは，実に 2010 年，Mozc を OSS 化するにあたってビルドシステムを GYP に移行するさなかのことでした．当初の動機は，時間のかかるバイナリ辞書圧縮処理を開発中何度も実行したくないという理由でした．状況が変わったのは，Android 版や NaCl 版の必要がでてきてからです．これらのプラットフォームはクロスコンパイルを必要とし，そのための基盤として 2 段階ビルドが「利用」されました．ビルドの複雑さは一時制御不能な規模までふくれあがり，一見正しく見える変更が，なぜか Android ビルドだけを壊すという問題が多発しました．記憶が確かなら 2011 年から 2012 年頃が最も酷かったように思います．
このひどい状況は，2013 年末，Android 版ビルドが GYP の Android.mk ジェネレータから一般的な make ジェネレータに切り替えられることで大幅に改善され，今回 FxOS コードリーディングミートアップ #4 に参加したのを切っ掛けに取り払ってみた感じです．
ちなみに 2010 年ごろ懸念されたビルド時間の問題も，今時のワークステーションで作業する分には概ね問題になりません．
基本実装は r192 にて．その後，r211およびr214にて有効化されました．
2 段階ビルドに使用されたコードはその後 r371 および r507 として完全に削除されます．

Issue 224: enable_gtk_renderer=0 指定時にビルドが失敗する

https://code.google.com/p/mozc/issues/detail?id=224
Linux 版 Mozc で， mozc_renderer を無効にした状態でビルドしようとするとコンパイルエラーになるという問題．単純なミスだったので即修正となりました．
r215 にて修正．

Unicode 絵文字変換を NaCl 環境および Linux デスクトップ環境でもデフォルト有効化

今までは特定環境のみ Unicode 絵文字をデフォルト有効化というロジックだったのですが，コードがだいぶ複雑になってしまっていたので，逆に特定環境のみデフォルト無効化というロジックに変更しました．このときの簡略化の一環で， NaCl 環境および Linux デスクトップ環境でも Unicode 絵文字変換はデフォルト有効化となりました．
r229，r230，r231 の 3 つのコミットにより有効化．

Issue 226: ibus-mozc の周辺文字列取得コードが正しく動作していなかった

https://code.google.com/p/mozc/issues/detail?id=226
ibus-mozc の周辺文字列の取得コードにバグがあって，UTF-8 文字列のバイトオフセットを使って部分文字列を切り出すべきところに，間違って文字数を使って部分文字列を切り出していたというもの．結果的に，ibus-mozc で周辺文字列を考慮した変換が意図しない形で動作してしまっていました．
r232 および r233 にて修正．

Issue 227: IBus 1.5 環境下で確定取り消しが動作しない

https://code.google.com/p/mozc/issues/detail?id=227
Issue 201 修正の副作用で，ibus-mozc を IBus 1.5 環境下で使用しているとき，確定取り消し (MS-IME キー設定で言うところの Ctrl+BS) が動作しなくなっていた，という問題の修正です．
r234 にて修正．

Issue 233: ibus-mozc 使用時，MozcTool に対応するテキストラベルが存在しない

https://code.google.com/p/mozc/issues/detail?id=233
MozcTool に対応するテキストラベルが存在せず，空白のエントリが表示されるというものです． IBus 1.4 環境までは言語バー的な UI が標準で表示されていたため問題になりませんでしたが，IBus 1.5 環境で言語バー的な UI が廃止されたためこの問題が表面化する可能性が高くなりました．

ちょうど社内のワークステーションが Ubuntu 14.04 に切り替わるタイミングだったので，同僚から言われる前に IBus 1.5 関係のやり残しタスクの一環で直してみた感じです．
r251 にて修正．

Issue 236: Windows 8.1 update1 環境で Explorer がクラッシュすることがある

https://code.google.com/p/mozc/issues/detail?id=236
安定性の確認もかねて，家でときどき tsf-mozc を使っていたところ，Windows 8.1 update1 環境で Explorer がクラッシュする確実な手順を発見したので，デバッグ・対処してみたというものです．再現率 100% なので， Visual Studio で簡単にデバッグできるかと思いきや，windbg で WinRT の内部まで潜る必要があって大変でした．Ntdebugging Blog の記事を見つけられなければデバッグは無理だったように思います．WinRT で言語共通の実行時例外がどのように実装されているか興味がある人には，この記事面白いかもしれません．
r252 にて対処．

Issue 222: Linux デスクトップ, NaCl, および Android ビルドで Ninja を使用する

https://code.google.com/p/mozc/issues/detail?id=222
2012年他にやったこと - Mozc 編 - NyaRuRuが地球にいたころで書いたように，2012 年末から Windows 版 Mozc は Ninja でビルドされるようになっていたのですが，これを Linux デスクトップ, NaCl, および Android ビルドでも使うようにしたというものです．
やってみて分かったのですが，どうも GYP の Ninja ジェネレータとmake_global_settings という GYP の設定の組み合わせで Android 向けクロスビルドを行ったのは Mozc が最初らしく，結局自分で GYP 側も直す必要がありました．以下のようにせっせと GYP 側にパッチを送っていたりします．たまに役立つ GYP コミット権．

Mozc 側では，r265, r266, r267, r268 の 4 回に分けて有効化されました．

Issue 240: Linux デスクトップ, NaCl, および Android ビルド環境構築のための Dockerfile の提供開始

https://code.google.com/p/mozc/issues/detail?id=240
OSS Mozc の公式ビルド環境を Docker で定義してみよう，と Docker の勉強がてらやってみました．特に Android 版 Mozcのビルド環境を Docker 化できたおかげで，その後のビルドの検証がだいぶ楽になりました．
r271 にて Ubuntu 12.04 ベースのコンテナを提供開始．
r330 にて Ubuntu 14.04 ベースのコンテナの試験提供を開始しました．
なお， r486 で Ubuntu 12.04 ベースのコンテナは役目を終了し，以後は Ubuntu 14.04 に一本化しています．

Ninja の Console Pool 機能を有効化

https://code.google.com/p/mozc/source/detail?r=314
Ninja 1.5 の新機能に Console Pool というのがあって，これが Mozc の Android ビルドのときに使えるかなと試してみたものです．
r314 にて有効化．

Issue 246: Linux, NaCl, および Android 環境で，'Set input mode to X' コマンドが直接入力モードで動作しない

https://code.google.com/p/mozc/issues/detail?id=246
https://bugzilla.redhat.com/show_bug.cgi?id=1119048
Red Hat Bugzilla で ibus-mozc 向けに報告されていた問題で，キーマップエディタで直接入力モード時に「ひらがなモードに切り替え」というコマンドを設定したとしても，実際には動作しないという問題です．
Windows では問題なく動作するのですが，動作するプラットフォームが実はホワイトリスト方式になっていて，Windows 以外では意図的に受け付けないようになっていました．実際には Mac 以外で許可することに問題はないので，そのように対処した，というものです．
r315 にて修正．

Issue 244: Visual C++ 2013 対応

https://code.google.com/p/mozc/issues/detail?id=244
OSS Mozc を Visual Studio 2013 でビルドできるようにしてみた，というものです．
r311 以降で対応．
ちなみにこの後 Visual Studio Community がリリースされたおかげで，無償版の Visual Studio を利用して OSS Mozc Windows 版をビルドできるようになっています．
なお， r509 以降では Visual Studio 2013 にサポートするコンパイラを一本化しています．

About ダイアログ上の Copyright 表記の更新

2014 年も半分以上過ぎているのに，About Dialog 上の Copyright 表記が 2013 年のままだったので直したというものです．
r324 にて修正．

アプリケーションマニフェストに Windows 10 対応宣言を追加

Windows 版の実行ファイル全てに，Windows 10 対応という GUID をセットするというものです．
r344 にて対処．

UserHistoryStorage の 2038 年問題

Mozc の入力履歴ファイル内で使用されるタイムスタンプが 2038 年以降不正な値になるという問題です．たまたまコードを眺めていて発見したので直してみました．修正自体はほぼ Protocol Buffers で定義されたデータ型の型を uint32 から uint64 に変更するだけといえます．Protocol Buffers の特徴として，この変更に関しては互換性と保存されるデータサイズ的に影響を及ぼさないと分かっていたため，割と気軽に直すことができました．
r346 にて対処．

SafeStrToDouble/SafeStrToFloat を Android 環境で再度有効化

https://code.google.com/p/mozc/source/detail?r=370
特定バージョンの Android NDK でビルドすると，strtod に 16 進数表記の文字列を渡したときの挙動に非互換の変更があったため，Android 環境で一部のテストを無効化されていたのですが，Android NDK r10c でこの問題が修正されたためテストを再度有効化したというものです．
r370 にて対処．

Issue 249: Windows 8 以降の環境でスタート画面に統合された IME 候補表示が正しく動作しない

https://code.google.com/p/mozc/issues/detail?id=249
これも家で tsf-mozc を使っていて発見した問題です．当時実験的に tsf-mozc でITfFnSearchCandidateProvider をサポートしていたのですが，どうも実装が不完全だったため逆に問題のある挙動になってしまっていたらしく，該当機能を無効化することで対処となりました．
r329 にて修正．

Issue 248: Android 環境に物理キーボードを接続し，デッドキーを使用するとクラッシュする

https://code.google.com/p/mozc/issues/detail?id=248
OSS Mozc の Issue Tracker に寄せられた報告です．Android 環境での Mozc のデッドキーイベントの扱いに問題があり，特定キーボードレイアウトで特定キーシーケンスを入力すると必ず Mozc がクラッシュしてしまっていました．
r463 にて修正．

Issue 255: ibus-mozc を XIM プロトコルで使用すると，フォーカスロスト時にプリエディットがクリアされない

https://code.google.com/p/mozc/issues/detail?id=255
OSS Mozc の Issue Tracker に寄せられた報告です．元々は日本 IBM の人から SUSE Linux に報告が寄せられ，さらに openSUSE の Issue Tracker を経ての報告だそうです．
ibus-mozc を XIM プロトコルで使用し，gedit 上でプリエディットが残っている状態で，別アプリケーションにフォーカスを移し，再度 gedit にフォーカスを戻すと，以前のプリエディットは既に確定されているのに，ibus-mozc は以前のプリエディットの内容が残ったままであるかのように振る舞う，という問題でした．
調べてみると Mozc 1.2.809.102 より前のバージョンではこのケースでも正しく動いていたものの， Chromium OS (当時はまだ IBus を使用していた)でのフォーカス周りのバグに対処すべくあれこれ変更するうちに現在の挙動になってしまったということが分かりました．
r386 にて修正．

2015 年の話とか

今年は休日の空き時間があまり読めないので，分からないというのが正直なところです．少なくとも OSS 化作業については，Android 5.0 向けの OSS 化が一息ついたので，多少は時間が稼げたんではなかろうかと．

もし何かひとつ優先するすれば，今年こそ不要コードの削除に注力したいかなと．Windows XP 対応のために入れていたコードや，もうあまり意味の無さそうなパフォーマンスチューニング，古いコンパイラのために必要だったコードなどなど．書いた本人ならすぐに判断がつくものの，もし仮に誰かが引き継いでしまうと消していいかの判断がつかなくなりそうなものは今のうちに消してしまいたいと思う次第．

次点としては，Windows 版向けにずっとやりたかったことあれこれ，たとえば OSS 版のインストーラーを動くようにするとか per-monitor DPI-aware 対応とか．とはいえ，すべては今年の休日具合次第なんですけどね．あとどんなミートアップに参加するかも．

過去編

2014 年やったこと - Chromium 編

Sun, 04 Jan 2015 21:06:39 +0900

Chromium 関係，コードはあまり書いていない一年でした．数字としてはコミット 17 回，コードレビュー 13 回となります．一方 Issue Tracker 上での活動はまあそれなりにで，Issue 登録 19 回，コメントを書き込んだり状態を変更したりといった Issue の数は 173 件となりました．

自分でやったこと

Windows 版 Chromium の Aura 移行完了後不要になった IME 関連コードの削除

Issue 319122 - chromium - Remove TSFEventRouter[Observer], InputMethodTSF, and related unused code. - An open-source project to help move the web forward. - Google Project Hosting

2014 年 1 月から 2 月にかけて，Aura + Ash 移行に伴い不要になった IME 関連コードの削除をやっていました．既にチームを移っていたこともあり，最後の後片付けという感じです．書くだけ書いて後片付けを次の人に任せるのは気が引けたというのもありますし，Chromium に関わり始めた 2012 年ごろ，おっかなびっくり書いたやっつけコードを自らの手で消し去る良い機会だったというのもあります．

Windows 版 Chromium で HiDPI 有効化時に IME の候補ウィンドウの位置がずれる問題の修正

Issue 260529 - chromium - IME UI is not placed at proper position when HiDPI is enabled - An open-source project to help move the web forward. - Google Project Hosting

2013 年に自分が登録したバグですが，普段使っている Windows ノート PC がこの影響を受けていてあまりにも不便だったので，土日の空き時間を使って自分で直してみたものです．

Android 5.0 の新 IME API への対応 (未完)

Issue 424866 - chromium - Support InputMethodManager#updateCursorAnchorInfo for Android 5.0 - An open-source project to help move the web forward. - Google Project Hosting

後で改めて書くかと思いますが，2014 年のメインプロジェクトの仕事のひとつで Android 5.0 にいくつか IME API を追加，というのをやっておりました．追加した API は InputMethodManager.html#updateCursor API の置き換えを狙ったもので，変換中の文字列のスクリーン座標を IME に伝えられるようにするものです．さて，この種の新 API の宿命として，IME だけでなくテキスト入力 widget 側にも新 API 対応が必要になります．Android の標準 TextView を使っているアプリケーションであれば何もしなくてよいのですが，独自にテキスト描画を行っているアプリケーションではそうはいきません．Chromium も当然ながらこのカテゴリに属し，Android 5.0 の SDK を使用して割と面倒なコードを追加する必要がありました．この仕事，当初は Chromium Android 版チームの人に頼もうかと漠然と考えていたのですが，Android 5.0 の開発期間中にとりあえず動く検証用コードを書き上げてしまったこともあり，なし崩し的に自分で対応コードを追加することになったという感じです．
とはいえコードレビューでのリクエストに色々応えていたらだいぶ規模が大きくなり，そのまま年末休暇シーズンに突入してしまったため，実現は 2015 年に持ち越しとなりました．

Issue Tracker 上で情報提供しつつ直してもらったものからいくつか

base::SHA1HashBytes に 4 GB 以上のデータを渡すと誤ったハッシュ値を返す

Issue 348333 - chromium - Security: base::SHA1HashBytes produces wrong SHA1 hash when |len| >= 4GB - An open-source project to help move the web forward. - Google Project Hosting

別件で SHA1 Hash の計算式を調べていたときに，参考に見てみた Chromium の内部関数に問題を見つけてしまったというものです．ざっと見てみた範囲では問題になるケースは見つけられませんでしたが，念のためセキュリティバグとして報告，修正してもらいました．

Chrome Remote Desktop (Chromoting) のウィンドウ上ではクライアント環境の IME は常にオフにすべき

Issue 401371 - chromium - IME should never be enabled in Chromoting window - An open-source project to help move the web forward. - Google Project Hosting

仕事で Chrome Remote Desktop (内部コードネーム Chromoting) を使うことが良くあるのですが，IME 関係で不満があったので変更を提案して対応してもらったというものです．
Windows 環境から Linux 環境に Chrome Remote Desktop で接続するケースを考えてみます．このとき，Chrome Remote Desktop のウィンドウ上でクライアント側 (Windows 側) の IME を有効にすることができてしまっていました．しかし，確定した文字列は単に捨てられてしまうという状況でした．

これは，特に機能として役立っていないだけではなく，パスワードを意図せず IME に学習させてしまうなど望ましくない動作でした．そこで，クライアント側の IME を完全にオフにするという提案をしてみた次第です．
以前 Pepper SDK の IME 周りを担当されていた kinaba@ さんの的確なアドバイスのおかげで，数日のうちに対応していただくことができました．

Time::EnableHighResolutionTimer(false) が無視されることがある

http://t.co/JTur7YYQ3y これ，Chromiumのソースを読むと若干印象が違うんですよね． timeBeginPeriodは気を付けろ的な長いコメントは実際書いてあるし，バッテリー駆動時にはtimeBeginPeriod(1)呼ぶのを避けようとしてたり．
— NyaRuRu (@NyaRuRu) July 15, 2014

かなり初期からそうなっていたはず．2009年1月のGoogle Chrome Out of Beta Partyにお呼ばれしたときにこのネタでLTした記憶が…… http://t.co/8jPmv2kGHo
— NyaRuRu (@NyaRuRu) July 15, 2014

んで，まずいのは実はこの辺の挙動が継続的にテストされていないということかなぁと．実際，2009年1月当時LTしたときも，実は電源抜き差しイベントのモニタリングの実装が壊れていてなんかずっと電源つながっている状態と誤認されていました的な状態だったと．
— NyaRuRu (@NyaRuRu) July 15, 2014

2013年にも，WM_POWERBROADCASTイベントのモニタリングが８ヶ月ぐらい壊れたままだったのに誰も気づかなかった事件とか． https://t.co/2je9isJfdJ
— NyaRuRu (@NyaRuRu) July 15, 2014

教訓としては，継続的テストの実行環境の中に，バッテリーモード動作をテストするための環境をちゃんと作るのが重要，というあたりでしょうか．でないと，バッテリーモードで動作するとき特有の挙動がテストできないですよ，と．
— NyaRuRu (@NyaRuRu) July 15, 2014

2014 年 7 月頃，ネットメディアを中心に Windows 版 Chrome の電力消費量が話題になったことがありました．報道に関して色々言いたいことはあったものの，実際うまく動作しないケースが存在することも知っていたので，念のため知っていることを Issue Tracker にコメントしておきました．実際には他にも色々問題があったらしく，しばらくしてまとめて修正していただきました．マルチスレッド絡みバグがたくさん見つかったそうです．

Issue 153139 - chromium - System clock rate: Chrome is not battery friendly on Windows - An open-source project to help move the web forward. - Google Project Hosting

base::PowerMonitor::AddObserver と base::PowerMonitor::RemoveObserver が同じスレッドで呼ばれないことによる use-after-free

たまたま自分の目の前で Google Chrome Canary がクラッシュしたので，クラッシュダンプを頼りに Issue Tracker 上で原因究明に協力したものです．Issue としては以下のものになります．(Chromium ではクラッシュバグは原則セキュリティバグ扱いのため，特定アカウントでログインしていない限り以下のページは表示されません．面倒な仕組みですみません)

Chromium Issue 404767

仮想関数呼び出しで EXCEPTION_ACCESS_VIOLATION_EXEC という一見不可思議なクラッシュだったのですが，イベントリスナーとして使われている仮想関数だったことから use-after-free を疑って関連コードを読んでいくと，以下のようなコードを発見．これ，AddObserver と RemoveObserver が同じスレッドで呼ばれないと，RemoveObserver はサイレントに何もしないという実装だったという．
http://src.chromium.org/viewvc/chrome/trunk/src/base/observer_list_threadsafe.h?revision=212281#l125

  // Remove an observer from the list if it is in the list.
  // If there are pending notifications in-transit to the observer, they will
  // be aborted.
  // If the observer to be removed is in the list, RemoveObserver MUST
  // be called from the same thread which called AddObserver.
  void RemoveObserver(ObserverType* obs) {

「このせいじゃね?」とコメントしておいたところ，直前にコミットされていた Issue 482333003: Reland r290125: Close all active PeerConnections upon OS suspend - Code Review がまさにこの問題を踏んでいたことを特定していただきました．これにコードレビューで気付けというのはちょっと無理ですかね．ライブラリの設計ミスとでも言うべきか．

Google Cloud Messaging クライアントの exponential backoff が約 7 日でオーバーフローする

Issue 373181 - chromium - Chromium packet storm on port 5228 - An open-source project to help move the web forward. - Google Project Hosting

利用者からバグ報告に担当者が割り当てられていなかったので，関係しそうな人々を CC しただけ仕事です．Chrome が特定条件で (Google のサーバーの?) port 5228 に大量のパケットを送信する，という問題．原因だけは気になっていたのでその後もやりとりをウォッチしていたのですが，exponential backoff の計算方法に問題があって，約 7 日送信失敗し続けると double の精度を超えてしまっていたというオチでした．

Windows 10 Technical Preview 上で動く Chromium の User Agent が "Windows NT 6.3" と返す

Issue 420629 - chromium - User agent string reports "Windows NT 6.3" on Windows 10 Technical Preview - An open-source project to help move the web forward. - Google Project Hosting

Windows 8.1 のときにもあった，GetVersionEx 嘘つき問題です．マニフェストファイルに GUID を追加すれば解決する話ではあるのですが，実際手を出してみたら大量の yak shaving に付き合わされたのが前回．今回は Issue として登録して直してもらいました．

感想

何となくそうではないかと予想していましたが，Issue Tracker で人に作業を振ったりあれこれ意見を述べるだけってのはだいぶ楽ですねこれ．チームを移ったこともあり，基本的に休日や通勤中の空き時間でできる作業に専念していたのですが，これぐらいの作業なら空き時間との相談で続けてもいいかなというところです．
一方で Chromium のコードを書く人の負担が半端なく大きいという問題は未解決のままと言えます．かなり厳しいコードレビュー，法外に高いクロスプラットフォーム対応コスト，不安定なテスト，コミット後忘れた頃にやってくる regression とクラッシュの報告．実際に問題を修正してくれている人たちは何故そんな面倒な仕事をしてくれているのか，そこをうまくシステム化していかないとブラウザ開発というプロジェクト自体の持続可能性が危ういんではないかなと．Issue Tracker であれこれ意見を言うだけの人が 100 人いても，大変めんどくさいコード変更作業に立ち上がってくれる人が 1 人現れない限り問題は解決しないという構造をプロジェクト運営にどう反映させていくのか．思うことは色々あるのですが，この辺についてはまた改めて別のエントリで書いてみたいと思います．
2015 年ですが，Android 5.0 の新 IME API 対応はさっさと終わせないとですね．その先はあんまり考えていないです．まあなるようになる感じで．

過去のエントリ

References

コミット一覧

レビューした CL 一覧

報告した Issue 一覧

コメントした Issue 一覧

2013年やったこと - Firefox, LibreOffice, Gyp 編

Sun, 05 Jan 2014 12:38:55 +0900

2013年やったこと - Firefox, LibreOffice, Gyp 編．

Firefox: TSF 無効時の HTML5 Forms のtype 指定と InputScope の対応作業

866736 – InputScope support for IMM32 with CUAS

TSF モードの Firefox は InputScope に対応既なのですが，IMM32 モードでは特に何も考慮されていませんでした．実は SetInputScopes API を使えばレガシー IMM32 アプリでも InputScope に対応できるので，Firefox でもやってみた，という変更です．以下のように InputScope 周りを重点的に見ていた時期だったので，タイミングが良かったというのもありました．

同様の方法で InputScope に対応するコードを Chromium 向けに書いていた
同時期に Mozc の InputScope 対応を実装していた

ゴールデンウィークに Mozilla Japan の六本木オフィスで行われたハッカソンで書き上げたものです．パッチの送り方も一緒に教えてもらえたので大変助かりました．
ビルドを壊しちゃったりコードに CRLF が混ざっていたりと，チェックイン後も色々ご迷惑をおかけすることに．中野さんをはじめフォローしていただいた Mozilla の皆様ありがとうございました．

LibreOffice: IMR_QUERYCHARPOSITION 対応

Bug 64298 – Support IMR_QUERYCHARPOSITION for better integration with IMEs
LibreOffice に IMR_QUERYCHARPOSITION サポートを追加して，各種 IME が適切な位置にサジェストウィンドウを表示できるようにするというパッチです．

LibreOffice Writer 4.0 (修正前)

LibreOffice Writer 4.1 (修正後)

この問題との付き合いは長く，Mozc リリース直後にOpenOffice.org でサジェストウィンドウの表示位置が変というレポートがたくさん来て以来となります．3 年半のときを経てやっと根本的に対処できました．

IMR_QUERYCHARPOSITION を (直接的または間接的に) 利用している全 IME で表示位置が改善されます．
このパッチもたしかゴールデンウィークを利用して書いています．パッチの送り方からチェックイン後のビルド失敗の後始末まで LibreOffice チームのみなさんにたくさんフォローしていただきました．この場をお借りして改めてお礼申しあげます．

Gyp Issue 385: ninja generator doesn't handle LinkTimeCodeGeneration/ProfileGuidedDatabase for PGO

Issue 385 - gyp - ninja generator doesn't handle LinkTimeCodeGeneration/ProfileGuidedDatabase for PGO - Generate Your Projects - Google Project Hosting
年末休暇で暇つぶしに適当に見つけた Gyp のバグを直してみたというもの．特に困ってはいなかったのですが，たまには Gyp コミッターらしいことでもしておくかという感じ．
Gyp の Ninja 向けジェネレータが PGO 設定の一部をサポートしていなかったので，対応してみました．実装自体は単に対応表を書くだけだったのですが，コードレビューで「実際に PGO ビルドするテストもあるといいね」という流れになってテストを書いてみたら予想を上回る大変さだったという．この体験がもとになって書いたのが次の記事です．

「ファイルの中身に依存しつつそのファイル自体を更新する」コマンドラインツールはビルドシステムと相性が悪い - NyaRuRuが地球にいたころ

Chromium で PGO が有効化される場合はもしかしたら意味があるかもしれません．もっとも，そのまえに Chromium のビルドシステムが Gyp から GN (Generate Ninja) に移行しちゃうかもしれませんが．

Gyp Issue 389: ninja generator is not aware of VCLinkerTool.GenerateManifest

Issue 389 - gyp - ninja generator is not aware of VCLinkerTool.GenerateManifest - Generate Your Projects - Google Project Hosting
上の Gyp Issue 385 のテストを書くのにどうしても必要になった機能です．

感想

メインプロジェクトと関連があるところを攻めつつ，みんなが便利になる方向の改良にもっていけたように思います．

今年の話とか

今年も隙を見て OSS プロジェクトにパッチを投げていきたいです．

2013年やったこと - Chromium 編

Sat, 04 Jan 2014 12:32:38 +0900

2013年やったこと - Chromium 編，いつもどおりコードが公開されている範囲で．

HTML5 Forms の type 指定と InputScope の対応作業

Issue 13768 - chromium - InputScope support on Windows (a better IME integration) - An open-source project to help move the web forward. - Google Project Hosting

HTML5 Forms の type 指定と Windows 環境での InputScope を連携させるという変更です．Windows 8 以降のオンスクリーンキーボードは InputScope でレイアウトを切り替えるため，IME を必要としない言語でも有効なのがポイントです．
変更自体はそれほど難しくなく，特にトラブルもないまま無事リリースされていきました．

メジャーブラウザの InputScope 対応状況については，以下の記事にまとめています．

HTML5 Forms の type 指定がデスクトップ IMEに影響するという話 - NyaRuRuが地球にいたころ

Omnibox フォント問題

Omnibox のフォントサイズが微妙に変わった/特定文字が□になったから直すべし，という案件．

なんでこのバグを担当する羽目になったかというと，Omnibox で使っていた RichEdit のバージョンを上げたのが私だったからです．なぜバージョンを上げる必要があったかというと，Immersive Mode で IME をサポートするためには TSF を使う必要があって，古い RichEdit は TSF をサポートしていなかったからです．欲しかったのは TSF の機能だけで，その他は前と同じように動いてほしかったのですが，そうはいかなかったようでした．
問題自体は i18n 対応でありふれたものです．様々な経験則を駆使しつつ複数フォントで文字をレンダリングしたいという需要があるのですが，それはそれでうまく動かないことがあるというもの．RichEdit ではいくつか制御フラグがあるものの (e.g., IMF_DUALFONT, IMF_AUTOFONT) あちらを立てればこちらが立たずで，直ったーと思ってリリースしてみると予想外の言語から「見た目が変わったー」「文字が□になるー」とバグが報告されるという．
ちなみに後で分かったのですが，Aura という UI フレームワークへの移行することがだいぶ前に決まっていて，その過程で RichEdit は使われなくなるとことも決定事項だったのでした．実際，このとき書いたコードは 1 年と経たず使われなくなりました．

破損 msftedit.dll 問題

Issue 161034 - chromium - Unable to type URL in the address bar, showing blank omnibox - An open-source project to help move the web forward. - Google Project Hosting

これも同じく RichEdit のバージョンを上げたら壊れた問題です．RichEdit 4.1 は msftedit.dll という DLL で提供されているのですが，どうも世の中には msftedit.dll が破損している環境というのが一定数あるらしく，その場合は Omnibox が真っ黒になって何も文字が入力できなくなってしまうとのこと．ユーザーフォーラムに多数問い合わせが来て発覚．議論の末 LoadLibrary("msftedit.dll") が失敗したらダイアログを出してヘルプページに誘導する，ということになりました．ダイアログを表示するような UI 周りのコードを書くのは初めてだったのでだいぶ苦労したのを憶えています．がその後数か月のうちに RichEdit は使われなくなるわけで，このコードも今は使われていません．(たぶんもう消されてるはず)

用語整理

以後のトピックを理解する上で必要になる用語整理をここで軽く済ませておきます．

Aura

Aura - The Chromium Projects

上の資料はだいぶ古くなっているのではないかと思いますがかといってあんまりいい資料もないかも．
一般的には「全てを GPU でレンダリングするための変更」という説明をされることが多い Aura ですが，何年もかけて移行していると関係者が増えすぎていて一言でいうのはもう無理なのではという印象もあります．
Chrome OS はとっくの昔に Aura に移行していて，現在 Windows と Linux で移行の最終段階です．Windows については次の Chrome M-32 で安定板にも Aura が投入されそうではありますが正式にリリースはまだなのでご注意を．
基本的には Chrome OS / Linux / Windows で共有されるコードが増える方向のプロジェクトです．ウィンドウを抽象化し，UI イベントを抽象化し，IME 処理も抽象化し，レンダリング API も抽象化し，という流れ．イベント処理周りのコールスタックは数割深くなる印象．また，いわゆる抽象化の漏れによるバグの比率が増えます．
一方，UI イベントの型と描画 API がプラットフォーム間で統一されることから，新規プラットフォームへの移植時に必要なコード量は確実に少なくなります．WebView として Chromium を使いたい人は特にこの点を重視している模様．たとえば Intel の人たちが中心になって行っている Chromium 派生プロジェクト Crosswalk は Aura が前提だったりします．
ちなみに，Aura は大規模にコードを入れ替えるため，ビルドオプションで有効無効を切り替えます．実行時スイッチで切り替えられず，安定性・互換性・パフォーマンスに関する影響は非常に大きいということで，リリースエンジニアリングの観点では非常に厄介なタイプの大規模変更です．

Ash (Aura Shell)

Aura のウィンドウモデルやイベントモデルの上に作られたウィンドウマネージャで，Chrome OS のために作られました．実際 Chrome OS では，はるか昔に投入済みです．
経緯は知りませんが Windows 8 以降の Immsersive Mode でも使われることになり，すでに開発版等ではリリースされています．Windows での実装は，ブラウザプロセス + レンダラプロセスで構成されている Chromium にさらに WinRT プロセスが追加されるという非常にトリッキーなマルチプロセス構成となっており，IME サポートもだいぶ面倒なことになりました．詳しくは後ほど．
後になって知ったのですが，Immsersive モードに Ash を投入するという構想自体はだいぶ前からあったようです．Windows 版での Ash モードで IME が動かないというバグ登録されたのは，2012 年12月7日のことでした．
Issue 164964 - chromium - Support basic functionality of IMEs in Chrome Metro ASH on Windows 8 - An open-source project to help move the web forward. - Google Project Hosting

Desktop Aura

ウィンドウマネージャは従来通り OS のものを使いつつ，独立した各ウィンドウの内側だけを Aura に置き換えるというもの．デスクトップモードの Windows と Linux で投入されます．現在の Chrome OS にこの動作形態はありません．
IME に関していえばウィンドウマネージャは OS のものを使うという点がやっぱり罠で，Ash 環境では表面化しなかったタイミングバグやイベント順序バグが沢山表面化することとなりました．
先ほど述べたように，予定通りいけば次の Chrome M-32 安定板からWindows 版でも有効化される見込みとなっています．IME に限らず，アクセシビリティ系ツールとの互換性，パフォーマンス，GPU ドライバとの互換性等，あちこち大変みたいです．

Native Textfield Views

従来ネイティブウィンドウを使って実装していたテキストフィールドを自前の Window-less コントロールに置き換えようというものです．なお Web コンテンツ領域はもともと自前のテキストフィールドだったので，ここで置き換えられるのは Omnibox 等外側の部分のテキストフィールドのみなことに注意．
Desktop Aura ではトップレベルウィンドウ以外はネイティブウィンドウを持たないので， Aura 移行のためには必須となります．Aura 移行が完了している Chrome OS 環境では当然のことながら置き換え済みです．
Native Textfield Views の実装自体は Aura から独立していて，Windows 版 Aura 投入にあたっては以下のように段階的な移行が行われました．

non-Aura + Native Textfield Views 無効
non-Aura + Native Textfield Views 有効
Aura + Native Textfield Views 有効

このいずれの構成でも IME は動作する必要があり，移行期には考慮すべきケースが増えてしまうので大変でした．
Aura と異なり，起動時のフラグで有効無効を切り替えるという特徴があります．上の 1 と 2 は同じバイナリで提供することが可能です．

構成

一時的にテストされたものも含むと，IME に関しては以下の 7 パターンの構成を見ることになりました．

IMM32 で動作する non-Aura モード (Windows XP, Vista, 7, 8, 8.1 のデスクトップモード)
- Native Textfield Views 有効の場合
- Native Textfield Views 無効の場合
TSFで動作する non-Aura モード (Windows 8, 8.1 の Immersive モード)
- Native Textfield Views 有効の場合
- Native Textfield Views 無効の場合
IMM32 で動作する Desktop-Aura モード (Windows XP, Vista, 7)
TSF で動作する Desktop-Aura モード (Windows 8, 8.1) [のちに不要だったことが判明]
TSFで動作する Ash モード (Windows 8, 8.1 の Immersive モード)

不運だったのは，この「TSF で動作する Desktop-Aura モード (Windows 8, 8.1)」が，非常に不安定だった割に，実際のところ全く不要だったとあとになって判明することです． 2013 年 4 月ごろ，将来の必要性を見越して Windows 向け Aura/Ash を担当しているチームから追加されたこのモードは，その後 5 か月にわたって安定化のためにエンジニアリングリソースを吸い込み続け，そして一度も安定板に投入されることなく削除されることになります．
なお，移行が概ね完了した Chromium M-33 以降では，以下の 2 つの構成にまで簡略化されています．

IMM32 で動作する Desktop-Aura モード (Windows XP, Vista, 7, 8, 8.1 のデスクトップモード)
TSFで動作する Ash モード (Windows 8, 8.1 の Immersive モード)

というわけで用語説明終わりです．

Native Textfield Views が IMR_QUERYCHARPOSITION をサポートしない

ゴールデンウィークの暇つぶしに軽い気持ちでパッチを投げたもの．Desktop Aura や Ash のリリースプランを当時の私は全く知らなくて，村の近くに出没したゴブリンでも退治する感じでパッチを投げてしまったのでした．ちなみにこの後どうなるかというと，

Native Textfield Views 導入編 (ゴブリンの巣)
Native Textfield Views + non-Aura完結編 (なんか最初の山場)
Desktop Aura 編 (魔王城)
Ash 編 (宇宙)

みたいな流れになります．
この時直したバグは，Native Textfield Views が有効だとサジェストウィンドウ位置が揃わないというものでした．

このパッチのせいで，Omnibox 上でカーソルが点滅しなくなるというバグを引き起こしてしまいあわてて直したりもしています．

Issue 238136 - chromium - Omnibox cursor doesn't show or blink reliably - An open-source project to help move the web forward. - Google Project Hosting

Native Textfield Views で変換中の文節区切りが分からない

Issue 164516 - chromium - Views Textfield: no segments are visible and no focus on the segments - An open-source project to help move the web forward. - Google Project Hosting

ゴールデンウィークのゴブリン退治その 2.
IME で入力中，文節区切りが分からないという問題の修正です．Chrome OS 版で発見されたまま直っていなかった問題ですが，さすがにこのまま Windows 版に出すのはまずかろうという気持ちで (特に担当だったわけではないのですが) 直してみました．

Native Textfield Views + non-Aura 環境での IME 対応

Issue 246534 - chromium - Upgrade ui::InputMethod for non-Aura environment on Windows - An open-source project to help move the web forward. - Google Project Hosting

6 月ごろだった気もしますがやや記憶があいまい．

既に一月は復活IMEバグと戦い続けていた．「このバグで最後のはずだ」「ん，なんだこのコピペされたコードは」「聞いてないぞ」「Ben Goodgerのレビューでコミットされてたんだ」「なんてこった，ここはIMEバグの巣だ！」今，IMEの平和をかけた最後の戦いが始まる．
— NyaRuRu (@NyaRuRu) May 31, 2013

思っていたより事態が深刻だと気付き始めます．というのも，既に Aura への移行を済ませてしまっている Chrome OS と違い，Windows 版では Native Textfield Views と non-Aura という組み合わせでも IME を完璧に動作させる必要があります．もちろん最終的には Windows での Aura ビルドでも IME サポートを行う必要もあります．ともあれ，Native Textfield Viewsの投入は近そうだということで，何とか 7 月末に Native Textfield Views + non-Aura という環境で概ね問題なく動くところまでこぎつけました．
コードだけでなく Design Doc もこのタイミングで書くことにもなりました．しかし既に Aura への移行を済ませた Chrome OS の IME 実装を大きく変えるわけにもいきません，必然的に Design Doc の大半は，既にコミットされているコードの説明に費やされました．

Desktop Aura 対応

8 月から 9 月にかけて．Native Textfield Views がひと段落したと思ったのもつかの間，すぐにも Desktop Aura が Windows に投入されそうと知らされ再び戦場へ．
ウィンドウのフォーカス処理を OS に任せるか Aura で行うかの違いは思った以上に大きく，Chrome OS では表面化しなかったイベント順序問題やタイミングバグが頻発します．
さらに IMM32 と TSF という異なる実装を同時に安定化させる作業は困難を極めました．また，コードが共有される関係上，変更が Chrome OS での IME サポートを壊すリスクもあり，頻繁にマニュアルテストを行う必要がありました．特定の操作でのみ発生する use-after-free バグが頻発し，GC が恋しくなった時期でもあります．
そして9 月中旬．ラスボスだと思っていたものがラスボスではなかったことを知ります．Immsersive モードで Ash を使用する予定であること，およびそれが WinRT プロセスとデスクトッププロセスが入り混じったものになることを初めて把握します．と同時に，4 月に Windows 版 Ash チームの人がデスクトップモードでも TSF を有効化したその意図をやっと理解したのでした．ここにきての伏線回収．結局それは Ash モードでの動作を見越して投機的に行われたものだったのでした．
が，改めて実験してみると，TSF ランタイムに嫌な制約があって，ブラウザプロセスで TSF を有効にしても Ash モードでの IME サポートの役には立たないことが明らかに．伏線を回収してみたら事件の真相は単にコミュニケーション不足だったという．人類はなんど同じネタを繰り返さなければならないのでしょうか．
最終的には，デスクトップモードでの TSF サポートをやめたことで，IME に関する Desktop Aura の安定化が急激に進むのでした．

Ash での IME サポート

Windows 環境での Ash モードは非常に特殊な動きをします．Win32 的なキーボードフォーカスは WinRT プロセスが保持する一方，UI イベントの処理は全てデスクトップで動いているブラウザプロセスに転送するという動作をします (ウェブコンテンツはさらにレンダラプロセスでレンダリングされます)．キーイベントに IME が絡まなければ，基本的にこれはうまく動作します．
さて IME ですが，WinRT プロセス内で IME を動かすか，ブラウザプロセス内で IME を動かすかという選択肢が考えられます．しかし，いくつかの実験から分かったのは，TSF ランタイムはフォアグラウンドプロセスかどうかを監視していて，バックグラウンドプロセスで動く IME は決してフォーカスイベントを受け取らない，という事実でした．消去法的に，WinRT プロセス内に TSF ベースのテキストストアを構築し，IPC を通じてブラウザプロセス内の既存コードと連携させる以外道がないということになります．このことをちゃんと調べられたのが 2013 年 9 月，Ash モードでの IME サポートに関するバグが登録されて実に 10 か月が経過してのことでした．
Issue 164964 - chromium - Support basic functionality of IMEs in Chrome Metro ASH on Windows 8 - An open-source project to help move the web forward. - Google Project Hosting
動作する最低限のコードは 10 月中には完成させたのですが，Desktop Aura の安定化を優先させたこと，変更が大きなことから，実際にチェックイン作業を始められたのは 11 月下旬でした．残念ながら M-32 には間に合わず，M-32 ベースの Ash モードでは IME は動作しません．
とはいえ遅れはしたものの，予定した変更の大半は無事 M-33 ブランチカット前にチェックインを終えることができました．M-34現在，Ashモードでニコニコ動画にコメント入力すら可能です．ニコニコ動画に IME で入力するときは，

WinRT プロセス
ブラウザプロセス
レンダラプロセス
プラグインコンテナプロセス

と 4 つのプロセスが非同期 IPC で連携しながら動作することになるのですが，その綱渡り具合を真に理解できる人がはたして世界に何人いるのかにも興味があるところ．

Ash モードの Flash 上で候補ウィンドウの位置が正しく設定されない問題は M-34 で直ります．

IME に関係なく行きがかり上担当することになったもの

User Agent 文字列が正しい OS バージョンを示さない

Issue 259228 - chromium - User agent string does not show the correct OS version on Windows 8.1 - An open-source project to help move the web forward. - Google Project Hosting

Windows 8.1 で動く Chromium の User Agent 文字列が

Mozilla/5.0 (Windows NT 6.2; WOW64)

みたいになっていました．いわゆる GetVersion(Ex) API 問題．ブラウザの User Agent 文字列から OS のシェア推定とかやっているところには影響があったはず．

@NyaRuRu FYI: http://t.co/Ary1YgDNhu
— なかのん -Nakanon- (@d_toybox) 2013, 7月 11

@NyaRuRu あー、確かに、Win8.1でUA名、6.2のままですね。
— なかのん -Nakanon- (@d_toybox) 2013, 7月 11

という感じの，のどかな会話から思いがけず発覚したのが印象的でした．Mozilla 側でも直後に修正されています．
まあついでということで Chromium にはパッチを投げてみました．メジャーブラウザの User Agent 文字列に影響する変更というのはなかなか貴重な体験でした．

全部の *.exe にアプリケーションマニフェストファイルを設定すべき

Issue 260692 - chromium - All executables should embed application manifest - An open-source project to help move the web forward. - Google Project Hosting

先ほどの GetVersion(Ex) API 問題を修正するために chrome.exe のマニフェストファイルをアップデートしたわけですが，コードレビューで「ユニットテストとプロダクションバイナリで動作が変わるのは良くないから，全部の *.exe に同じアプリケーションマニフェストを設定できないかな」的なコメントが付いたで急遽やることになった仕事です．
Mozc で培った Gyp 誰得ノウハウをいかんなく発揮して華麗に解決！といけばよかったのですが，実際全部の *.exe にマニフェストファイルを埋め込んでみたら今度は「ユニットテストのビルドが 30 倍遅くなった!」と怒られます．えー

Issue 276953 - chromium - unit_tests build regression by 30X - An open-source project to help move the web forward. - Google Project Hosting

結局いくつかのユニットテストではマニフェストファイルを埋め込まず隣に置く方式になりました．
後日談としては，Gyp r1813 でマニフェストファイルの扱いが大幅に見直されたので，パフォーマンスを悪化させずにマニフェストを埋め込むことができるようになりそうです．

Web MIDI: Windows 対応

社内 TechTalk で Toyoshima さんが Windows 版 Chromium 向け Web MIDI の実装者を募集していて，Mac 版が既に動いているならそれほど苦労せずに Windows 版も対応できるかなと思って手を上げました．
実際，10 月19日の Web Music ハッカソンにふらっと立ち寄って半日で単純な入出力までできたのですが，細かいところまで見てみると既にある共通部分のコードにも色々バグを見つけてしまい，基本部分からひとつずつバグを直していくことになりました．私にとっては Blink への初コミットが Web MIDI となります．
Aura/Ash の IME 実装がほんとに大変な時期だったというのもあって，コードレビューの待ち時間等を利用して少しずつ直しながら，一か月半後ぐらいの12月4日にやっと有効化となりました．

Windows で電源イベントのオブザーバーが動いていなかった

Issue 314477 - chromium - PowerMonitor is not functional on Windows - An open-source project to help move the web forward. - Google Project Hosting

Web MIDI 関連で調べているときにたまたま見つけてしまったバグです．Chromium の実装用のライブラリに，電源コードの抜き差しや，サスペンドへの移行・復帰時にコールバックを受けられる仕組みがあるのですが，これが数か月動いていませんでした．
タイマ割り込み精度の変更とか GPU ウォッチドッグタイマの設定とかネットワークのコネクションキャッシュがこれらのイベントに依存しているみたいですが，誰も気づいていなかったみたいですね．

その他社内コンサル業

W3C Working Draft: Input Method Editor API

http://www.w3.org/TR/ime-api/
W3C に提案中の Input Method Editor API について，社内で API 設計の議論をしたり，Chromium での実装に関してアドバイスをしたりしています．

chrome.input.ime

http://developer.chrome.com/extensions/input_ime.html
Chromium OS 専用の内部 API である，chrome.input.ime についてもたまに議論に参加したりしています．

感想

色々思うところのある1年でした．

今年の話とか

2014 年 1 月から社内の (Chromium 以外の) 別プロジェクトに移ることにしました．Web MIDI 等，趣味として参加できそうな部分は引き続きコミットしていければと思いますが，締め切りのあるバグを担当するほどの余裕はたぶんないと思います．社内コンサル業と，IME 周りのクリティカルな部分のコードレビューに費やす時間ぐらいはまあなんとか捻出したいところ．

過去編

2012年やったこと - Chromium 編 - NyaRuRuが地球にいたころ

2013年やったこと - Mozc 編

Thu, 02 Jan 2014 12:05:15 +0900

2013年やったこと - Mozc 編，いつもどおりコードが公開されている範囲で．

Mozc IPC の Windows 64-bit 対応

Windows 環境で動く Mozc は名前付きパイプ使ってプロセス間通信を行うのですが，いわゆる "Squatting Attack" 対策として，GetNamedPipeServerProcessId API で接続先のプロセス ID を取得し，さらにそのプロセス ID から GetModuleFileNameExW API で実行ファイル名を取得して検証しています．が，この仕組みが今は動いていても将来的にうまく動かないことがあるかもという問題．
このころ mozc_server や mozc_renderer を 64-bit で動かす実験を行っていて気付いたわけですが， 32-bit プロセスから 64-bit プロセスに対して GetModuleFileNameExW API を呼び出すと必ず失敗するようです．仕方ないので GetProcessImageFileNameW API を使うように変更して対処．これまで mozc_server と mozc_renderer は常に 32-bit プロセスだったので問題が表面化していなかったというわけでした．

TSF-Mozc 使用時に ImmNotifyIME(hIMC, NI_COMPOSITIONSTR, CPS_CANCEL, 0) が動作しない

IMM32 の頃には，アプリケーション側から進行中のコンポジションをキャンセルするという API が存在しました．TSF になってそういう API はなくなったのですが，CUAS はなにかしらの方法でこの IMM32 API をエミュレートする必要があります．実際これは「コンポジションの範囲を空にする」という形で行われています．ということで TSF-Mozc でも対応する必要があるというわけでした．
Excel が，インライン補完のためにこの機能に依存しているので割と重要だったりします．

TSF-Mozc で候補ウィンドウの候補をマウスで選択・決定できない問題の修正

経験上ほとんどの人はマウスで候補ウィンドウを選択しないのを知っていたので，TSF-Mozc ではマウス関係の処理を後回しにしていました．とはいえ，タッチイベントでも動作しないのはそろそろよろしくないというのもあって修正という感じです．

TSF-Mozc での InputScope のサポート

InputScope も登場後 10 年以上経っている仕組みで，いまさらという感もありますが，Windows 8 以降はだいぶ InputScopeへの移行が進んでいます．最近はブラウザの HTML Forms の種類が InputScope で通知されたり，Windows 8 以降でImmSetConversionStatus API が (デフォルト設定では) 実質廃止になったりで，IME 側も InputScope 対応が割と重要になってきています．というわけで TSF-Mozc でも対応してみました．
アプリケーション開発者様におかれましても，Windows 8 以降，ImmSetConversionStatus API は大多数のユーザー環境で期待通り動作していない可能性が高いため，この機会に InputScope に移行してしまうのが良いのではないかと思います．詳細については下記資料等を参照してください．

さて，デスクトップ IME の文脈で気を付けるべき点として，アプリケーション側からのモード変更リクエストを永続的なものとして扱うか，一時的な変更リクエストとして扱うかという問題があります．たとえば次のような順序でテキストフィールドを移動していったとしましょう．

通常のテキストフィールド
パスワードフィールド
通常のテキストフィールド

多くの場合，ステップ 1 で IME がオンの状態であれば，ステップ 3 でIME がオンの状態に復帰します．つまり，パスワードフィールドで IME が自動的にオフになるのは，永続的なモード変更ではなく一時的なモード変更というわけです．
では次の場合はどうなるべきでしょうか？

通常のテキストフィールド
全角カタカナが期待されるテキストフィールド
通常のテキストフィールド

ステップ 2 で IME の入力モードが「全角カタカナ」になるのはまあ良いとします．では，ステップ 3 に移動したときにも「全角カタカナ」のままであるべきでしょうか？それともステップ 1 のときのモードに復帰すべきでしょうか．
TSF-Mozc に関しては，InputScope によるモード変更リクエストはその場限りの一時的なものであるという解釈を行いました．したがって，上記ステップ 3 ではステップ 1 のときのモードに復帰します．簡単に Design Doc を書いていますので詳細についてはそちらを参照してください．

InputScope - mozc - DesignDoc - InputScope support - Mozc - Japanese Input Method for Chromium OS, Android, Windows, Mac and Linux - Google Project Hosting

Windows 版 Mozc での Mode Indicator のサポート

これ．

位置形状とフォントサイズの決定以外のほぼ全てを担当しました．個人的にはカーソル直下よりもカーソルに対して左揃えの方が良いんではないかとか，ちょっと大きすぎるんではないかとか色々思うところはあるのですが，まあデザイナーさんがそう言っているわけで案件．個人的にはもうちょっと作りこみたかったのですが，別の仕事が忙しくてあんまり専念できなかったのが心残りです．
InputScope で自動モード変更を行う以上，この種の視覚的フィードバックは必須ですね．というわけで InputScope 対応とセットで実装されました．

周辺文字列を利用した変換の (部分的) サポート

周辺文字列を利用した変換も十数年以上の歴史があるいまさら技術ではあります．前世紀の IMM32 時代から IMR_DOCUMENTFEED メッセージをサポートしたアプリケーションでは周辺文字列を利用した変換は可能でした．
さて，周辺文字列を利用した変換というのは実際のところあんまりコストパフォーマンスの良くないアプローチだと思っています．細切れ変換対策という意味では，変換エンジン側で前回コミットされた文字列を覚えておけばすむ話です．というわけで，今回注目したのは，IME をオフにして入力しがちな文字種，つまり半角英数です．
たとえば「明日1日」という文章を入力するのに，

「明日」を入力
IME をオフにする
「1」を入力
IME をオンにする
「日」を入力

という使い方をする人は一定いることが分かっています．以前の Mozc では，ステップ 4 実行時に内部ステートは「文頭」状態でした．というのも，IME がオフの状態で入力された内容はモニタリングしていないので，ステップ 5 で入力する内容がどういう文章に続くものなのか把握できません．今回救いたかったのはまさにこういうケースで，カーソル前にある文字種がアルファベットか数字かどうかだけを判定します．このあたりの詳細についても Design Doc を書いておきましたので詳細が気になる人はどうぞ．

SurroundingText - mozc - DesignDoc - Surrounding Text support - Mozc - Japanese Input Method for Chromium OS, Android, Windows, Mac and Linux - Google Project Hosting

imm32-mozc と tsf-mozc，ibus-mozc および mozc_server の実装を担当しました．
IMM32 版では IMR_DOCUMENTFEED を単純に使うだけですが，TSF では Transitory Extensions という拡張的な仕組みも使っていて，メモ帳や Internet Explorer にも対応しています．軽く調べてみた限り，ATOK 2013 も MS-IME 2013 も Transitory Extensions までは使っていないようなので，ちょっとしたアピールポイントではないかと思っております．
このとき書いたコードは別のオープンソースプロジェクトで使われたりもしているようです．

C++11 対応

最近社内コード規約的に C++11 が解禁されつつあるので Mozc でもいくつかコードのクリーンアップを行っています．具体的には，

自前 scoped_ptr から std::unique_ptr への置き換え
COMPILE_ASSERT マクロの static_assert への置き換え
auto での書き換え
NULL から nullptr への置き換え

あたりをちまちまやってます．
最近は Visual C++ の C++11 適応度合が上がってきていてだいぶ楽なのですが，意外に足を引っ張るのが Mac OS X だったり．というのも，libc++ の実行時ライブラリが標準で入るようになったのが Mac OS X 10.7 以降．未だに Snow Leopard をサポートしていたりすると C++11 の大部分の機能が使えないのでした．

UCS2 しかサポートできない内部関数の削除

Mozc コードベースに残っていた UCS2 専用関数をすべて削除しました．

TSF-Mozc でタッチに最適化されたオンスクリーンキーボードを表示するように

ITfFnGetPreferredTouchKeyboardLayout を実装するだけ，というわけでもなくて Windows のオンスクリーンキーボードは U+F003 と U+F004 に特別な意味を持たせたりしているのでその対応とか．詳しくは下記資料参照のこと．

Guidelines and checklist for IME development (Windows Store apps) (Windows)

可能なら LogicalToPhysicalPointForPerMonitorDPI API を使う

Mozc の候補ウィンドウや Mode Indicator は，入力中のプロセスとは別のプロセスで動いているので，DPI 仮想化にともなう座標変換が必要になることがあります．Windows 8.1 Preview で LogicalToPhysicalPoint API が動作しなくなっていたので，新しく追加された LogicalToPhysicalPointForPerMonitorDPI API が利用可能ならそちらを使う，といった修正を行っていました．Windows の DPI 周り，ほんと落ち着かないですね．
次の資料とかが詳しいです．
http://go.microsoft.com/fwlink/?LinkID=307061

アプリケーションマニフェストに Windows 8.1 対応宣言を追加

恒例行事．

ITfLangBarItemButton::GetIcon で返すモノクロフォントを実行時に描画

Accessibility (a11y) 案件．
Windows 版の Mozc は，控えめに言っても Accessibility 関係の機能が全然足りていないのですが，珍しく対応している機能のひとつに言語バーのテキストアイコン色があります．Windows では，デスクトップテーマをハイコントラストモード(背景色黒・文字色緑) に変更すると，言語バーのテキストアイコンも緑色に切り替わります．

ではこれどうやって実装するかですが，大まかに方法は 2 つ．
A. 実行時にアイコンを描画する．この場合，テーマカラーを実行時に取得できるので文字色は問題ない．テーマが変更されるたびにアイコンを再生成する必要がある．
B. モノクロアイコンを事前に生成しておき，言語バーAPI に TF_LBI_STYLE_TEXTCOLORICON フラグを渡す．この場合，言語バー側で色変更を行ってくれる．
Mozc はながらく B の方法を使っていました．が，最近になってビットマップハンドルのリークが発生しているという報告を受けて調べてみると驚きの事実が！ ITfLangBarItemButton::GetIcon にモノクロアイコンを渡すと，言語バー内部でビットマップハンドルのリークが発生するようです．というわけで方向 A で書き直しました．
この問題，原因の発見までがとにかく大変だったのが印象的でした．ハンドルリークが全然再現できず困っていたのですが，ユーザーの方からアップロードしていただいたスクリーンショットがクラシックテーマだったことが気になってテーマを変更してみたところやっと再現できた，というケースです．どういうやりとりが行われたか興味がある人は以下のスレッドをどうぞ．

Google グループ

TF_LBI_STYLE_TEXTCOLORICON を使用している IME 作者様はご注意ください．

Adobe Sandbox をサポート

@corvussolis さんから Adobe Flash および Adobe Acrobat Reader で使われている Sandbox の動作について教えてもらって Mozc でも対応してみたという話．これでやっと Firefox でも「保護モード」オンのままニコニコ動画にコメントを書けるようになりました．
ご協力いただいた皆様に感謝．

Windows 8 以降で MS-IME からのユーザー辞書インポートが動かなくなっていたのを修正

詳細については diff を参考にしてください．

Owner Rights SID を設定

Windows では，オブジェクト所有者に暗黙に WRITE_DAC および READ_CONTROL 権限が許可されるという仕様がありましたが，Vista 以降この挙動を拒否することが可能になりました．

AD DS: Owner Rights

というわけで Mozc でも不要な権限を削除してみたという話．追加すると権限が減る系の SID ですね．

Windows 版 Mozc のビルド時に Cygwin が不要になった

Mozc のビルドは，もともと Cygwin に依存しないように作られていました．しかし，Mozcのビルドシステムを SCons から gyp に変更したときに，gyp に引っ張られる形で Cygwin 依存が生まれてしまいました．
外部コマンドの呼び出しに時に色々気を付ければ Cygwin は不要というのは分かっていたのですが，とりあえず重要度は低いので後回しのままとなってはや数年，いい加減直すかということでやっと依存関係を解消したという話です．Windows 版 OSS Mozc のチェックアウトサイズもだいぶ減ったはず．
ちなみに Chromium も同様の問題があって，以下のようにビルド時の Cygwin 依存を取り除く努力が行われています (こっちも数年がかり)．

Issue 123026 - chromium - Remove cygwin as a build dependency on Windows - An open-source project to help move the web forward. - Google Project Hosting

以下 OSS Mozc 固有っぽいもの

Issue 42: get rid of absolute path in unix/ibus/gen_mozc_xml.py

https://code.google.com/p/mozc/issues/detail?id=41
ibus-mozc のバイナリとアイコンファイルのインストール先はカスタマイズできるべきだという案件．3 年ぐらい放置されていのですが (すみません) リファクタリングの一環として対応．

Issue 180: Mozc and IBus does not respect xinerama at all

https://code.google.com/p/mozc/issues/detail?id=180
マルチディスプレイ環境で mozc_renderer が画面境界の判定に失敗するというバグ．gdk_screen_get_monitor_at_point を使うことで解決．

Issue 182: mozc property titles are empty in gnome-shell

https://code.google.com/p/mozc/issues/detail?id=182
Red Hat で ibus-mozc をメンテナンスされている Tagoh さんから転送されてきたバグの対応．Gnome-Shell はいくつかの IBus メタデータに依存しているのですが，ibus-mozc がそれらを設定していないという問題．具体的には，

IBus 1.5 以降にのみ存在する symbol というプロパティをセットするようにする (これを行わないと現在の入力モードがアイコンとして表示されない)
Gnome Shell は "InputMode" という名前のプロパティに現在のモード (全角カタカナとか直接入力とか) が設定されていることを期待しているので，プロパティ名を変更

という感じです．ちなみにこのあたりの Gnome-Shell の仕様はどこにもドキュメント化されていません．自分でソースを読んで調べる必要があります．結果的に以下のような見た目になりました．

このパッチがあたっていないバージョンの Mozc (具体的には 1.6.1187.102 以前) では，入力中のモードは分かりませんし，入力モードを Gnome Shell から選択することもできません．

Issue 188: Add Session command for ConvertPrevPage and ConvertNextPage

https://code.google.com/p/mozc/issues/detail?id=188
Fcitx の開発者から来た機能追加リクエスト．Fcitx の候補ウィンドウには次頁・前頁に相当するボタンが存在するのですが，その動作に対応するメッセージが Mozc のプロトコルに存在しなかったという問題．たまたま Windows 8 のソフトウェアキーボード対応で似たような需要があったので合わせて対応となりました．

Issue 189: use_libprotobuf=1 does not work in Mozc 1.10.1390.102

https://code.google.com/p/mozc/issues/detail?id=189
Red Hat で ibus-mozc をメンテされている Tagoh さんから，システムにインストールされている libprotobuf を使用する場合のビルドが壊れているとの報告があったので粛々と修正．壊したのも私なのでマッチポンプ案件だったりします．

Issue 195: Candidate Popup is hidden by Cinnamon menu

https://code.google.com/p/mozc/issues/detail?id=195
Linux で Cinnamon を使っていると，mozc_renderer がメニューの後ろ側に行ってしまうという問題．修正は 2 行で済んだんですが，環境のセットアップやら調査やらで結局 1 日ぐらいかかっているという．ちなみにこのケースでは日曜日が消えました．

Issue 198: 'build_mozc.py gyp' fails when gyp r1667 or higher is used

https://code.google.com/p/mozc/issues/detail?id=198
Mozc 開発ではビルドに使用する gyp のリビジョンを固定しているのですが，OSS Mozc をビルドする人は推奨リビジョン以外の gyp と組み合わせている人もいるらしく，gyp 側の変更でビルドできなくなることがあります．
今回は，Mozc r171 以前と gyp の r1667 以降を組み合わせるとビルドに失敗するという問題でした．

Issue 199: ibus-mozc must be locked down on the Gnome Shell's locked screen

https://code.google.com/p/mozc/issues/detail?id=199
CVE-2013-4509 の ibus-mozc 側の対処を一通りやりました．
私も完全に背景を把握できているか怪しいのですが，概ね以下のような感じだと理解しております．

2013年1月4日，Gnome 3 環境で IME をオンにしたままスクリーンをロックし， Gnome-Shell のスクリーンロック解除画面からパスワードを入力してロック解除しようとすると，パスワードフィールドで IME がオンのままになっているというバグが Red Hat の Jens Petersen さんから報告される．Red Hat Bug 891835
2013年1月9日，Red Had の Ueno さんから，GTK の "input-purpose" と "input-hints" を，パスワードフィールドにセットすることで問題が回避したらよいのではという提案がなされる．Gnome Bug 691392
2013年1月10日，Red Hat の Ueno さん，ibus-gtk2 にパッチをコミット (927e9f58)．この変更は IBus 1.5.3 としてリリースされる．変更は ibus-gtk2 に対するもので，IM Engine 側では何もする必要がない．具体的には，"input-purpose" が password であれば，使用している IM Engine に関わらず IM Engine が無効化される．
2013年8月14日，Red Hat の Ueno さん，ibus-gtk にパッチをコミット (3b3a7cec)．この変更は IBus 1.5.4 としてリリースされる．この変更によりまたしても挙動が変わり，"input-purpose" が password のときの振る舞いは各 IM Engineの責任になる．具体的には，IM Engine が IBus 1.5.4 以降の環境で動作する場合のみ，このコミットで追加された ibus_engine_get_content_type 等の新しい API を使って IM Engine の動作を変更する必要がある．
2013年9月21日，Red Hat の Fujiwara さんから IBus 1.5.4 のリリースがアナウンスされる．この中で "Handle GTK+ input purose for gnome-shell password dialog and each engine need to implement it" として各 IM Engine 開発者向けにアナウンス．
2013年9月21日，俺のターン！ IBus 1.5.4 のリリースノートを受けて OSS Mozc Issue 199 をファイル．この時点では状況を完全に把握できていませんでした．
2013年9月30日，俺のターン！やっと状況を把握．急いでOSS Mozc Issue 199 へのパッチを公開．帰宅後色々弄っていて事態の深刻さに気付き急いで書き上げた感じの奴です．翌日ほんと眠かったです．
2013年10月1日，Red Hat の Mike FABIAN さんから，IBus 1.5.4 側の問題で "input-purpose" が正しく通知されないことがある問題が報告される．Red Hat Bug 1013948 この問題はすぐに修正されるものの，対応する IBus の安定板リリースは行われておらず，各ディストリビューションでは独自にパッチを取り込んで IBus 1.5.4 として配布している．
2013年10月25日，openSUSE のコミュニティメンバーの Takeyama さんから，Novel Bug 847718 がファイルされる．
2013年11月4日，Red Hat の Kurt Seifried さんにより今回の問題に CVE-2013-4509 が付与される．

この後 IBus を採用する各種ディストリビューションで色々対応が進んだようです．

Issue 201: making initial mode customizable for ibus-mozc

https://code.google.com/p/mozc/issues/detail?id=201
1.5.2 のころまでの IBus は，各 IM Engine は「直接入力 (いわゆる IME オフ)」というステートを持たないことを前提に設計されていました．従って，ibus-mozc は起動直後にひらがなモードである必要があります．
が，IBus 1.5.3 頃から，日本語 IME に関しては各 IM Engine 内部でオンオフ状態を切り替える方向に IBus 上流の人たちは心変わりしたようです．Red Hat の Fujiwara さんが ibus-anthy の挙動変更について下で説明されています．
https://code.google.com/p/ibus/issues/detail?id=747#c31
この変更にともない，以前の使い勝手を再現するためには，ibus-mozc が起動直後に「直接入力 (いわゆる IME オフ)」になって欲しいという要望が来たのが OSS Mozc Issue 201 です．
とはいえ Mozc は IBus 1.4 もまだ対応していますから，IBus のバージョンによらずデフォルトモードを変えてしまうと今度は IBus 1.4 ユーザーが困ることになります．また，デフォルトモードを選択する UI を追加しようにも，Mozc の設定画面は imm32-mozc, tsf-mozc, ibus-mozc, uim-mozc, fcitx-mozc, emacs-mozc, Mozc for IMKit で共有されているため，IBus 1.5.3 以降専用の項目を追加するのは躊躇するところです．
とりあえず初期状態をオフにするパッチだけは公開しましたが，以後のリリースでどうするかは未定です．
https://code.google.com/p/mozc/issues/detail?id=201#c8
ちなみに，初期値を変更するぐらい簡単だろうと思われる方もいらっしゃるかもしれません．が，実際は結構面倒です．事実，上のパッチを適用すると，mozc_server が予想外のクラッシュをした時のプレイバックの仕組みが壊れることが分かっています．初期値が変わっちゃったわけですね．

その他 OSS Mozc でメンテナンスしていたページ

その他 OSS Mozc 関係でやったこと

2013年4月ぐらいに fcitx-mozc のマニュアルテストを行って 6 件ぐらいバグを見つけたところ，作者様にものすごい勢いで修正していただきました．

Fcitx-mozc を試してみた - NyaRuRuが地球にいたころ

あと，fcitx-mozc の再変換には，ibus-mozc の再変換用に私が書いたコードが使われていたりするようです．

今年の話とか

入社後なんだかんだでずっと Mozc に関わってきましたが，2014 年 1 月から社内の別プロジェクトに移ることにしました．オープンな場で何をやったか話すのはいつも通り書いたコードが公開されてからにしようかと思います．
Windows 版 Mozc は 20% の枠内で今後も協力していきたいところですが，ibus-mozc のメンテナンスまでやる余裕はなさそうです．ibus-mozc の今後の開発・メンテナンスを引き継いでもいいという方がいらっしゃいましたら社内外問わずお知らせください．

Issue 194 - mozc - ibus-mozc is now in maintenance mode - Mozc - Japanese Input Method for Chromium OS, Android, Windows, Mac and Linux - Google Project Hosting

過去編

「ファイルの中身に依存しつつそのファイル自体を更新する」コマンドラインツールはビルドシステムと相性が悪い

Tue, 31 Dec 2013 10:14:13 +0900

関数型プログラミングのメリットについて語られることはあっても，「ファイルの中身に依存しつつそのファイル自体を更新する」コマンドラインツールがビルドシステムと相性が悪い，みたいな話をする人はあんまりいないようなので書いてみた．

Windows には signtool.exe というデジタル署名ツールがある．実行ファイル myapp.exeに署名したい場合は以下のようにする．

signtool sign /a myapp.exe

十分にシンプルなように見える．が，典型的なビルドシステムはこの処理がお気に召さない．試しに Chromium や node.js で使われているメタビルドシステムである Gyp で書いてみる．

{
  'targets': [
    {
      'target_name': 'myapp',
      'type': 'executable',
      'sources': [
        'main.cc',
      ],
    },
    {
      'target_name': 'sign',
      'type': 'none',
      'dependencies': [
        'myapp',
      ],
      'actions': [
        {
          'action_name': 'run_signtool',
          'inputs': [
            '<(PRODUCT_DIR)/myapp.exe',
          ],
          'outputs': [
            '<(PRODUCT_DIR)/myapp.exe',
          ],
          'action': ['signtool', 'sign', '/a', '<(PRODUCT_DIR)/myapp.exe'],
          'msvs_cygwin_shell': 0,
        },
      ],
    },
  ],
}

この Gyp ファイルから生成された Ninja 用ビルドファイルは，以下のようにビルド時にエラーとなる．

C:\work\dag>ninja -C out/Default sign
ninja: warning: multiple rules generate myapp.exe. builds involving this target will not be correct; continuing anyway
ninja: Entering directory `out/Default'
ninja: error: dependency cycle: myapp.exe -> myapp.exe

myapp.exe をビルドするのに myapp.exe が必要なのはけしからん，とのこと．
私の場合，ラッパースクリプトを書いて署名前後でファイルパスの一部が変わるようにして回避することが多い．
例1.

mysigntool --input=myapp.exe --output=myapp.signed.exe

例2.

mysigntool --input=unsigned/myapp.exe --output=signed/myapp.exe

デジタル署名に限らず，mt.exe を利用したマニフェストファイルの埋め込み，rebase.exe を利用した事前バインド，Profile Guided Optimization (PGO) などで，うっかり入力ファイルと出力ファイルを同一パスにすると同様の問題に直面する．

なんでこんな話を書く気になったかというと，暇つぶしに Gyp にパッチを書いていて突然気付いたからである．
https://codereview.chromium.org/82703007#msg3
Directed Acyclic Graph (DAG; 無閉路有向グラフ) を事前に構築できることを前提としているシステムというのは，ビルドシステムにしろ MapReduce にしろ，案外日常的にお世話になっている．そういうシステムで「ちょっとした処理」を行うとして，なんだかうまく書けないなぁという処理，実はそれ入力と出力に循環があったりしませんか，というまあただそれだけの話．
こうやって考えてみると，世間のビルドシステムというのはファイルシステムと割とべったりくっついているということに気付かされる．

まとめ

入力パス名と出力パス名が同じになる操作は，一般的にビルドシステムと相性が悪い．典型的なビルドシステムでは，ファイルの内容ではなくパス名だけを用いて依存関係を記述する必要があることに注意．

Windows の IME を変換エンジンとして使う

Wed, 18 Dec 2013 05:26:16 +0900

プロセス分離型の IME の開発に携わった以上，一度は試してみたいと思っていた奴，の基礎実証実験っぽいのをやってみた．Windows向け IME を (とくに個人規模で) 作っている人にはもしかしたら役に立つかも．

テーマ

メインテーマは，Windows で IME を実装するとして，バックグラウンドで別 IME を有効化し，その IME に対してクエリを投げ，返ってきた結果を利用するための技術的な枠組みについて．ここではプロセスモデル的に Windows で可能かどうかという点のみを考える．

大まかな流れ

今回試した手法では，Windows 8 で TSF に追加された ITfFnSearchCandidateProvider という仕組みを活用する．このインターフェイスは，複雑なことはできない反面，1) 文字列を投げて文字列のリストが返ってくるというシンプルな仕組みである，2) ステートを持たず，IME でユーザーが入力中かどうかに関わらず自由に使える，という点で大変使いやすい．ただしすべての IME が実装しているわけではない．これについては後述．
また，このインターフェイスには "Windows 8 [desktop apps only]" と注釈がついている．ここで，プロセス分離型の IME 実装を前提とするのが生きてくる．プロセス分離型の実装では，好きにデスクトッププロセスと連携できるのでこれは特に問題にはならない．

具体的な流れ

以下の手順で，キーボードフォーカスを持たないバックグラウンドプロセス内で，ITfFnSearchCandidateProvider をサポートした IME を変換エンジンとして使用できる．

バックグラウンドスレッドを作る
スレッド内で COM を初期化する (STA 推奨)
ITfInputProcessorProfileMgr.ActivateProfile を使用して，使用したい IME を有効化する．
ITfThreadMgr2.ActivateEx を呼んで IME に初期化処理を行わせる．
ITfThreadMgr2.GetFunctionProvider に，対象 IME の CLSID を渡して ITfFunctionProvider を取得
GetFunctionProvider.GetFunction 経由で ITfFnSearchCandidateProvider を取得
ITfFnSearchCandidateProvider.GetSearchCandidates で任意のクエリを行う

罠ポイント

上記手順の 3 が問題． Windows 8 以降はデスクトッププロセス間で IME 関係の設定を共有するようになったため，うかつに別 IME を選択すると他スレッド/他プロセスにも影響が及んでしまう．これについては， API を使って一時的にこの挙動に関する設定そのものを変更することで回避できそう．具体的には，SystemParametersInfo API に SPI_GETTHREADLOCALINPUTSETTINGS/ SETTHREADLOCALINPUTSETTINGS を指定して，以前の「スレッドごとに IME 関係の設定を保持」に変更する．変更は永続的である必要はなくて，IME を変更するごく短い間だけで十分なようだ．というわけで先ほどの手順をもう少し改良する．

バックグラウンドスレッドを作る
スレッド内で COM を初期化する (STA 推奨)
「スレッドごとに IME 関係の設定を保持」が有効でなければ SETTHREADLOCALINPUTSETTINGS を使って有効にする
ITfInputProcessorProfileMgr.ActivateProfile を使用して，使用したい IME を有効化する．
ITfThreadMgr2.ActivateEx を呼んで IME に初期化処理を行わせる．
ITfThreadMgr2.GetFunctionProvider に，対象 IME の CLSID を渡して ITfFunctionProvider を取得
GetFunctionProvider.GetFunction 経由で ITfFnSearchCandidateProvider を取得
「スレッドごとに IME 関係の設定を保持」を変更していれば，SETTHREADLOCALINPUTSETTINGS で元に戻す
ITfFnSearchCandidateProvider.GetSearchCandidates で任意のクエリを行う

実際には「スレッドごとの IME 設定」を元に戻すのはもう少し手前でも問題ないかもしれない．
また，ユーザーが「アプリウィンドウごとに異なる入力方式を設定する」を有効にしている場合，GETTHREADLOCALINPUTSETTINGS は TRUE を返す．この場合はスレッドごとに異なる IME を有効化できるため何もしなくてよい．

応用

上の罠ポイントさえ回避できれば，複数のバックグラウンドスレッドを用意し，それぞれに別 IME をロードして構わない．つまり，複数の IME に対して同時にクエリを行うことができる．

ITfFnSearchCandidateProvider をサポートしている IME はどれぐらいあるのか?

手元の Windows 8.1 環境でしらべたところ，MS-IME 日本語版と ATOK 2013 はサポートしている．Google 日本語入力 / OSS Mozc は1.12.1599.102 の時点で未サポート．以下，実験したい人のための GUID 一覧．

{
  name: "MS-IME Japanese (Windows 8.1)",
  langid: 0x0411,
  clsid: "03B5835F-F03C-411B-9CE2-AA23E1171E36",
  profile: "A76C93D9-5523-4E90-AAFA-4DB112F9AC76",
},
{
  name: "ATOK 2013",
  langid: 0x0411,
  clsid: "E7602D3E-204C-4662-B92F-78DF0DE5752D",
  profile: "3C4DB511-189A-4168-B6EA-BFD0B4C85615",
},
{
  name: "Google Japanese Input",
  langid: 0x0411,
  clsid: "D5A86FD5-5308-47EA-AD16-9C4EB160EC3C",
  profile "773EB24E-CA1D-4B1B-B420-FA985BB0B80D",
},
{
  name: "OSS Mozc",
  langid: 0x0411,
  clsid: "10A67BC8-22FA-4A59-90DC-2546652C56BF",
  profile: "186F700C-71CF-43FE-A00E-AACB1D9E6D3D",
},
{
  name: "Corvus-skk",
  langid: 0x0411,
  clsid: "EAEA0E29-AA1E-48ef-B2DF-46F4E24C6265",
  profile: "956F14B3-5310-4cef-9651-26710EB72F3A",
},

まとめ

Windows 8.1 環境で ITfFnSearchCandidateProvider を利用すると，MS-IME 日本語版と ATOK 2013 を(同時に)フォールバックエンジンとして使う IME が作成可能．

速度とか所感

MS-IME Japanese は大体 10 msec 以内で返ってくるのでサジェストでも大丈夫かも．ATOK 2013 はクエリが返ってくるまで 100 msec 以上かかっていて，リアルタイムのサジェストに使うのはちょっときついかも．

サンプルコード

次のコードは，現在使用中の IME からのみ ITfFnSearchCandidateProvider を取得することで色々処理を簡略化したもの．起動後に何か入力すると，その入力を ITfFnSearchCandidateProvider.GetSearchCandidates に渡した結果が返ってくる．空行入力で終了．
ビルドには要 NuGet．Package Manager から TSF.SearchCandidateProvider を追加．

PM > Install-Package TSF.SearchCandidateProvider

using System;
using System.Linq;
using TSF;

static class Program {
  static void Main(string[] args) {
    using (var provider = SearchCandidateProvider.FromCurrentProfile().Result) {
      if (provider == null) {
        Console.WriteLine("No provider found.");
        return;
      }
      Console.WriteLine("{0} is found", provider.Profile.Name);
      while (true) {
        var line = Console.ReadLine();
        if (string.IsNullOrEmpty(line)) {
          return;
        }
        var result = provider.GetSearchCandidates(line).Result;
        Console.WriteLine("Elapsed time: {0} msec", result.Elaplsed.TotalMilliseconds);
        result.Candidates.ToList().ForEach(s => Console.WriteLine("  " + s));
        Console.WriteLine();
      }
    }
  }
}

ビルドするのは面倒なのでビルド済みファイルが欲しいという人はこちら．
http://d.hatena.ne.jp/NyaRuRu/files/SearchCandidateProviderSample.zip

TSF.SearchCandidateProvider のコードが見たい人はこちらから．
NyaRuRu/TSF-SearchCandidateProvider · GitHub

類似研究

アレ用の何か
ITfFnReconversion を使う例．

HTML5 Forms の type 指定がデスクトップ IMEに影響するという話

Sun, 07 Jul 2013 21:01:50 +0900

最近やっていた仕事について，一通りリリースが終わって誰でも試せる段階になったので書いてみる．Web アプリ開発者の人や，IME 作成者の人には影響があるかも知れない．ただし Windows デスクトップを相手にしていなければ，ここで読むのをやめてもなんら問題はない．

最近 Chromium と Firefox にパッチを書いて，HTML5 Forms の type 指定が InputScope として TSF ベースの IME (いわゆる Text Input Processors; TIP) やソフトウェアキーボードに通知されるようにした．これは，基本的に Windows 8 上での Internet Explorer 10 の動作に合わせたものである．具体的には，以下の環境で，各種ブラウザが InputScope をサポートするようになった．

Microsoft Internet Explorer 10以降 (ただし Windows 8以降)
Google Chrome 26以降 (ただし Windows Vista以降)
Mozilla Firefox 23以降 (ただし Windows Vista以降)

なぜこれが問題になるのか．それは，一部の InputScope が指定されたとき，(Windows Vista 以降の) MS-IME は自動的に自分自身をオフにするからだ．
モダンなブラウザの実装では，HTML5 Forms input 要素の type 属性に，number, email, tel, time (Firefox 23+ の場合のみ), url のいずれかを指定したときこの「一部の InputScope」に該当する．結果として，対応する InputScope を受け取った MS-IME は自分自身のモードをオフに設定する．

ポイントは，これが IME 自身の判断によって行われるモード変更ということだ．この挙動についてブラウザベンダーを責めるのは難しい．ブラウザは単に対応する InputScope を IME に伝えているだけである．この点で，非標準の CSS に存在する ime-mode とは大きく異なる (ただし，type = password だけは以前からブラウザ自身が IME をオフにしている)．

影響を受けないのは，

TSF 非対応の IME を使っている場合
InputScope を無視する IME を使っている場合 (たとえば ATOK 2013 とそれ以前)
Windows XP で上記ブラウザを使っている場合

である．なお，各 InputScope に対する挙動は各 IME にゆだねられているため，今後のアップデートで振る舞いが変化する可能性もある．

まとめ

InputScope に対応したデスクトップブラウザ

Microsoft Internet Explorer 10以降 (ただし Windows 8以降)
Google Chrome 26以降 (ただし Windows Vista以降)
Mozilla Firefox 23以降 (ただし Windows Vista以降)

InputScope に対応した IME

Microsoft IME (Windows Vista以降)
Mozc / Google 日本語入力 1.11.x 以降 (TSF モードのみ)

HTML5 Forms の input 要素の type

number
email
tel
time (Firefox 23+ の場合のみ)
url

の組み合わせで，(結果として) IME がオフになる．これは IME が自主的に行っているもので，ブラウザ側から IME のオフを設定しているわけではない．この動作に関して意見がある場合，基本的には IME ベンダーへどうぞということになる．

謝辞

Mozilla Firefox への InputScope 対応パッチについて，Mozilla Japan の中野さんにレビュー等たいへんお世話になりました．この場をお借りしてお礼申し上げます．

余談 0

各ブラウザでの Forms の type と InputScope の対応については Mozc のデザインドキュメントでまとめておいた．詳細についてはそちらを参考にしてほしい．
https://code.google.com/p/mozc/wiki/InputScope#Scope

余談 1

Windows 8 の Immersive モードで，MS-IME 2012 は入力モードをカーソル周辺に表示するようになった．今後，自動モード変更が受け入れられていくためには，このようなモード表示は必須と考えられる．

余談 2

InputScope に応じて，IME は変換に関する挙動を最適化することができる．たとえば，InputScope が「サーチ」のときに名詞中心のサジェストを行う，といった最適化が考えられる．実際すでに MS-IME 2012 は InputScope が「サーチ」のときに，挙動を変えている．

余談 3

現在 W3C で (主にデスクトップ向けの) IME API が議論されている．その流れの中で Microsoft から inputmode という追加の属性が提案されている．
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#inputmode-attribute
この属性を使うと，ひらがなモードやカタカナモードといった，より日本人になじみが深い入力モードを指定できるようになる．InputScope にはこういったモードが既に存在するため，将来的には「半角カタカナモード」が期待される入力フィールド，といったものが HTML5 で実現可能になる可能性がある．興味がある人が議論に参加して欲しい．

余談 4

Tablet PC の時代に InputScope が設計され，10 年以上たってようやく HTML と InputScope が結びついたわけであるが，ブラウザでの InputScope への取り組み自体は以前から存在する．
たとえば Google Summer of Code 2008 では，Mozilla に対して -moz-input-scope という拡張が試みられた．
https://wiki.mozilla.org/Community:SummerOfCode08:TSF

余談 5

Input 要素の type 指定だが，実際のところモバイル用途の方が需要は高い．理由として，ソフトウェアキーボードのレイアウトが Input 要素の typeによって変化すると便利であること，CJK以外の国でもソフトウェアキーボードが使用されること，が挙げられる．

Fcitx-mozc を試してみた

Sat, 06 Apr 2013 21:34:23 +0900

(4/7 追記) fcitx-mozc の master branch では下記の問題は修正されたようです．Great!

Fcitxのテストのお願い - いくやの斬鉄日記というのがあったので，軽く動作を見てみました．環境はこんな感じ．

Ubuntu 13.04 Final Beta 64-bit
VMWare 9.0.2
Mozc / fcitx は 2013年4月6日午後8時(日本時間)の時点で，ppa:ikuya-fruitsbasket/fcitx に登録されていたバージョン

以下，ibus-mozc から後退する部分で気付いたものを列挙してみます．

一部の Ctrl 付きのショートカットが動作しない

Open gedit
Enable Mozc
type "kyouha"
hit Ctrl+H

Expected: "きょう"
Actual: "きょうは"

Mozc (というか Windows の代表的な IME は)，F7 キー，F8 キー，F9 キーの代わりにそれぞれ Ctrl+i，Ctrl+o，Ctrl+p という感じのショートカットが用意されています (QWERTY 配列では横に並んでいることに注目)．また，IME での入力中は Ctrl+h によってバックスペース相当の動作をすることも可能です．これらが fcitx-mozc では使えないようです．ibus-mozc 1.6.1187.102 では動作するはずです．
Mozc プロトコルでのモディファイアキーの扱いについては commands.proto で解説されています．Windows 版 Mozc の keyevent_handler_test.cc にも大量にテストケースがあります．

ひらがな/カタカナキーが常にカタカナキーとして振る舞う

(On 109 Japanese keyboard)

Open gedit
Enable Mozc
Type "a"
Hit Shift+Hiragana/Katakana
Type "i"
Hit Hiragana/Katakana
Type "u"

Expected: "あイう"
Actual: "あイウ"

期待される実装方法については ibus-mozc の以下のコードあたりが参考になるかと．
https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/key_translator.cc?r=131#57

  {IBUS_Hiragana, mozc::commands::KeyEvent::KANA},
  {IBUS_Hiragana_Katakana, mozc::commands::KeyEvent::KANA},
  {IBUS_Katakana, mozc::commands::KeyEvent::KATAKANA},

https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/key_translator.cc?r=124#377

  // Due to historical reasons, many linux ditributions set Hiragana_Katakana
  // key as Hiragana key (which is Katkana key with shift modifier). So, we
  // translate Hiragana_Katanaka key as Hiragana key by mapping table, and
  // Shift + Hiragana_Katakana key as Katakana key by functionally.
  // TODO(nona): Fix process modifier to handle right shift
  if (IsHiraganaKatakanaKeyWithShift(keyval, keycode, modifiers)) {
    modifiers &= ~IBUS_SHIFT_MASK;
    keyval = IBUS_Katakana;
  }

一時的な英数モードからシフトキーで復帰しない

Unset "L_SHIFT" from "Extra key for trigger input method" in the Fcitx global config.
Open gedit
Enable Mozc
Hit key as follows
1. Down Shift key
2. Hit a key
3. Up Shift key
4. Hit i key
5. Hit u key
6. Down Shift key
7. Up Shift key
8. Hit a key
9. Hit i key
10. Hit u key

Expected: "Aiuあいう"
Actual: "Aiuaiu"

MS-IME のローマ字モードには，Shift キーと共に入力を行うことで一時的に英数モードに入るという機能があるのですが、この入力状態はシフトキーを単独で押すことで解除できます。fcitx-mozc ではこの機能が働かないようです。ibus-mozc 1.6.1187.102 では動作するはずです．

ツールを起動する系のショートカットが動作しない

Open the config tool of Mozc
Enter key customize mode
Add an entry as "Precomposition/F2/Launch word register dialog"
Open gedit
Enable Mozc
Hit F2

Expected: word register dialog is launched
Actual: nothing happens

Mozc (というか Windows の代表的な IME )はショートカットキーで設定ダイアログを起動したり単語登録ダイアログを起動したりできるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

gedit で確定取り消しが動作しない

Open gedit
Enable Mozc
Type "kyouha"
Hit enter to commit
Hit Ctrl+BackSpace

Expected: commit action is canceled
Actual: nothing happens

Mozc (というか Windows の代表的な IME )は直前の確定動作を取り消せるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

gedit で再変換が動作しない

(On 109 Japanese keyboard)

Open gedit
Type something
Enable Mozc
Select some text
Hit Henkan key

Expected: The selected text is reconverted by Mozc
Actual: nothing happens

Mozc (というか Windows の代表的な IME は)選択した単語を再変換できるのですが，fcitx-mozc では機能していないようです．ibus-mozc 1.6.1187.102 では動作するはずです．

冒頭にも追記したとおり，ここに挙げた問題は全て master branch では修正済みのようです．良かった良かった．

2012年他にやったこと - Mozc 編

Sun, 31 Mar 2013 17:26:27 +0900

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 が使われることになったため，たぶんこの修正は無意味なはず……

https://code.google.com/p/mozc/issues/detail?id=177

プロセス間通信の 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 月頃せっせとパッチをアップストリームしている姿を以下に見ることができる．

http://www.ohloh.net/p/gyp/contributors/1359664239828870

移行は無事予定していた期間で終わり，現在の Mozc のビルドサーバーは gyp + Ninja + Visual C++ 2010 で動いている．

その名は「新しい (Windows) UI の…」

Wed, 20 Mar 2013 01:05:38 +0900

発端

マイクロソフト社がIEの舵取りに迷っている。同社は先週、Windows 8の“Windows ストアアプリ”として動作する「Internet Explorer 10」でFlashコンテンツを表示する際の方針を変更すると発表した。この方針転換が意味することを理解するためには、Windows 8が発売される前までさかのぼる必要がある。
【＃モリトーク】第50話：IEのジレンマ - 窓の杜

という記事を読んだのだけど，どうも用語の使い方が危なっかしい．枝葉の部分ならともかく記事の論点に直結する部分だけに余計に気になる．というわけでちょっとだけ書いてみたのが以下．

Windows 8 向けブラウザの 3 分類

Windows 8 でウェブブラウザというと，大きく 3 種類に分けられる．

いわゆる Windows ストアアプリであって，標準ブラウザコンポーネントを利用するもの
いわゆるデスクトップアプリケーションとして動作するブラウザ
Windows ストアアプリではないものの，Windows ストアアプリと同様の没入型 UI で動作するブラウザ

単独製品としての「Internet Explorer 10」が該当するのは 2 と 3 である．この厳密な定義に従えば，元記事にあった，

“Windows ストアアプリ”として動作する「Internet Explorer 10」

なるものは，実は存在しない．元記事に登場する Google Chrome も同様で，“Windows ストアアプリ”として動作する Google Chrome というものは存在しない．Chrome もタイプ 2 とタイプ 3 で動作する．
なぜこの区別が重要かというと，タイプ 3 のブラウザは，没入型 UI で動作するという点ではタイプ 1 に近いものの，開発者視点ではむしろタイプ 2 のデスクトップアプリケーションとしてのブラウザに近いからだ．タイプ 1 ブラウザと対照的な，タイプ 3 のブラウザの特徴を挙げてみよう．

AppContainer サンドボックスが強制されず，Integrity Level Medium で起動される
WinRT に縛られず，デスクトップアプリケーションとほぼ同等の Win32 API にアクセスできる
Windows ストアを経由せずにインストールできる

このように，タイプ 3 ブラウザは，実際にはデスクトップブラウザと同じ技術で作られている．プラグイン的な実行時ライブラリの使用や，JIT コンパイルのような実行時コード生成についても特に技術的な制約はない．
もう一点強調しておくと，Windows 8 で没入型 UI が導入されるにあたって，こんな動作モードが許されたのはブラウザだけである．この動作モードが許されるのはデフォルトブラウザに限定され，その他のブラウザには許されないというところからも，今回の措置が例外的なものであることが透けて見える．

参考資料

Windows 8 のサードパーティー製ブラウザ事情については，Microsoft がブラウザ開発者向けに公開している Developing a new experience enabled desktop browser という資料に詳しい．なかでは，Windows 8 で動作するタイプ 3 のブラウザを開発する方法について解説されている．プロセス分離型ブラウザについても言及されているあたり個人的には好感度が高い．
ちなみにこの資料で，タイプ 1, 2, 3 ブラウザはそれぞれ以下のように呼ばれている．

Windows Store app
Desktop browsers.
New experience enabled desktop browser

3 については，"New experience enabled" のあたりに没入型 UI を，"desktop browser" のあたりに API 的な側面を感じるとよいのではなかろうか．

きみの名は……

さて，以上の話を理解してから見る次のツイートは味わい深い．

Windows 8 の IE10 ですが、新しい UI の方をただの「Internet Explorer」、デスクトップから起動する方は「デスクトップ版 Internet Explorer」と呼びます。
— 日本マイクロソフト IE Teamさん (@IE_Japan) 2013年3月18日

ただし前者はわかりづらいので、"新しい (Windows) UI の IE"、"Windows 8 スタイルの IE" と言うのが一応ルールになっています。
— 日本マイクロソフト IE Teamさん (@IE_Japan) 2013年3月18日

背景事情が分かってしまえば簡単な話である．つまり，開発者向け資料で New experience enabled desktop browser と呼ばれる動作モードの IE が，ユーザー向けには "新しい (Windows) UI の IE"、"Windows 8 スタイルの IE" と紹介されているわけだ．まあ他に呼びようなかったのやもしれず．

Dell の個人向け商品で領収書をもらう方法 (または，まともなタッチ対応ディスプレイを経費で買う方法)

Sat, 09 Mar 2013 19:21:05 +0900

まとめ

Dell の 10 点タッチ外付け 23 インチディスプレイ S2340T は，個人向けサイトにしか載っていないけど，経費購入に必要な領収書も用意してもらえるので必要な人は迷わず買うと良いよ．

S2340T

Windows 8 に起因するタッチ対応案件は第一弾が一段落したころでしょうか．「Windows 7 のときに済ませた」という人から，「まだ対応していない」，「テストすらしていない」，「積み残しタスクがある」，という方まで，色々いらっしゃることかと思います．
そんななか，まだタッチ対応アプリケーションの開発体制を整えていなくて機材を探しているという場合におすすめなのが Dell の 23 インチディスプレイ S2340T．この製品，Full HD (1,920 x 1,080)，10 点タッチに対応しつつ，59,980 円という Windows 8 前のタッチ対応外付けディスクプレイからは考えられない低価格で．半年前に発表されるやいなや注文が積み上がり，一時期は通常納期 + 14 週間というすさまじいバックオーダーが生じていました．それが最近は需給が釣り合ってきたらしく，ついに通常納期まで改善したようなのでおすすめしてみる次第であります．

(参考) 製品紹介記事:

さて，この製品を経費で買おう思ったあなたに一点アドバイス．S2340T は Dell の個人向けサイトにのみ掲載されており，法人向けサイトには掲載されていません．これで困るのが領収書．通常の注文フローだと会社名・事業者名宛ての領収書が作れないっぽく見えるため，経費で買おう企んでいた人はそこで諦めてしまいかねません．私の場合，諦めきれなかったので Dell のサポートの人に聞いてみたのですが，実は個人向け製品でも領収書は作れるとのこと．

Q 領収書を発行可能ですか？
A 領収書は、現金払いでのご注文の場合原則”お振込票の控え”等をもって代えさせて頂いております。現金以外のお支払方法ご利用の場合、お客様よりご希望のあった場合のみ発行しております。ご希望の場合はこちらのフォームよりご連絡いただけますようお願い申し上げます。
※個人のお客様で現金前払いのお客様には弊社にて入金確認後「入金確認書兼領収書」を郵送させていただいておりますのでそちらを領収書としてご利用いただけます。
※領収日は現金前振込の場合はご入金の確認がとれた日・クレジットカードの場合はカード会社より引き落としを承認された日になります。(領収日の変更は承ることが出来ません。)
※領収書のお届けは納品後となり、お時間がかかることもございます。また商品には同梱できませんので、予めご了承ください。
よくあるご質問

流れとしては，以下のようになるようです．
1. 個人向けページから購入する．
2. 領収書発行フォームから領収書を請求する．

というわけで，S2340T の納期も改善してきたタイミングでの，タッチ対応 Windows アプリケーション / Web アプリ開発者向け情報でしたー

看板の話

Mon, 04 Feb 2013 19:38:03 +0900

【注意】I'm not a lawyer だよ! This is not legal advice だもんね!

Piro さんが長文を書かれていたので一部だけ切り出してつまみ食い．ただし GPL vs BSDL の話ではなくて看板の話．

自分の作った物が誰にどう使われようとも構わない、極端な話、誰かが看板だけ掛け替えた「改良版」を作って商売していようとも全く構わない、という事であれば、パブリックドメインにしたり、あるいはBSDスタイルのライセンスを選択して問題ないでしょう。

自分の作った物が看板を掛け替えただけの「改良版」として勝手に商売に使われるのは我慢ならない、やるならこっちにも分け前をよこせ、それが嫌なら無償で同じ条件でソースも含めて公開しろ、という事であれば、コピーレフトなライセンスを選択した方がいいでしょう。

自分の作った物がアイデアだけ引き継がれるのはいいけど、自分の血と汗と涙の結晶であるソースコードが他人にそのまま利用されるのは腹立たしい。アイデアを同じように具現化したかったら、自分で同じだけの血と汗と涙を投じて実装し直して欲しい。という事であれば、ソースコードを公開しないクローズドライセンスにした方がいいでしょう。

自分の作った物がソースコードも含めて引き継がれていって欲しい、他の人が自分と同じような苦労をしなくてもいいようにしたい、人類共有の財産にしたい、という時に、コピーレフトにするべきなのか、それともBSDスタイルにするべきなのか。そこが問題です。

Latest topics > 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - outsider reflex

これを読んで看板の方に反応しちゃったというか，つまり，ソフトウェアに十分以上の思い入れがあるなら，商標とるのも選択肢に入れるべきですかねと．

自分の作ったソフトウェアに対するブランドイメージが，第三者の「改良版」で勝手に使われたり左右されたりするのは我慢ならない．ブランドに影響する活動はぜんぶうちを通してもらうし，新たに何か立ち上げるならブランド構築はゼロからスタートしてもらう → 商標取ろう
自分の作ったソフトウェアに対するブランドイメージが，第三者の活動によってどう利用され・変化しようとかまわない．勝手にやってくれ． → なにもしない or 商標のとれない名前 (地名とか?) を使おう？

て感じなんですかね．
前者の例は，プロプライエタリなソフトウェアはもちろん，OSS の世界でも大手 Linux ディストリビューター (Debian, Fedora, Ubuntu, ...) や Mozilla，Arduino にしろ企業っぽいところはたいていそうです．仮に「改良版」で何か活動しようとしたい場合でも，看板の付け替えはほぼ確実に要求されています．仮に OSS のライセンスを守って著作権をクリアしても，あなたは Debian Lite とか Fedora Lite とか Firefox Lite という名前を使えないことになります．たぶんね．
後者としては，「～ごった煮版」「私家製～」「偽～」「Patched ～」「～版○○」とか煮え切らない名前で公開されているたくさんのソフトウェアの周辺にいくつもの例を見つけることができるでしょう．fork の盛んな OSS の世界ではこういった例もたくさん見ることができます．
つまるところ，あなたが活動を行う上で，ブランドに対する姿勢によっては，商標が必要になるケースがあります．これはOSS・プロプライエタリどちらでも行われていることで，いずれの場合であっても世に先例を見つけることができるでしょう．

2012年やったこと - Chromium 編

Thu, 03 Jan 2013 21:40:30 +0900

前回に引き続き今度は Chromium 編．chromium.org のアカウントを作ってもらったはいいものの，メールアドレスの 1 文字目を大文字にされて激しく凹むということもあった一年．

Windows 8 向け TSF 対応

Chromium を Windows 8 向けに TSF 対応させるというミッション．いやな予感はしていたものの，Mozc の TSF 対応もあるのであまり積極的に手を出せずにいたら，結局ぎりぎりになって火消し案件として振ってきた，という感じの一件．

http://code.google.com/p/chromium/issues/detail?id=137627

Windows 8 では IME の TSF 対応が注目されていたりするわけだけど，実は Immersive Mode で動作するブラウザの方も TSF に対応させる必要がある．対応させないと Immersive Mode で CJK の入力ができない．それはまずいというわけで TSF を扱ったことのある Mozc チーム (もっとも Mozc で TSF 経験者といっても私ぐらいだけど) に話が回ってきた．のが 7 月終わりから 8 月頭にかけて．Windows 8 の MSDN 向けリリースは 8 月 15 日．一般リリースは 10 月 26 日．
「どうしてこんなになるまで放っておいたんですかー！」……といっても始まらないので一時期は Mozc チームから 5 人ぐらいヘルプに回しつつ，6 週間 (これは Chromium の平均的なリリースサイクルでもある) でどうにか動くものをでっち上げる．結局細かいバグまで全部取り除くにはもう 1 サイクル (6週間) かかったけど．
この間 Mozilla 方面からはこういう声も聞こえてきたり．

jim martins何いってんだ。 (jimm) they had a problem with tsf and input imes, so they assinged five people from their japan office to it
— Makoto Kato (@makoto_kato) September 11, 2012

だよねー (jimm) man, google has unlimited resources
— Makoto Kato (@makoto_kato) September 11, 2012

まあ実際は 5 人全員が働きっぱなしということはなくって，内容が専門的になってくるにつれ段階的に人数を減らしていく感じで．戦力の逐次投入の逆ができたという点では満足．
ちなみに自分はリードエンジニアとして参加しつつ，コードを書くよりは主に設計と裏方に注力 (TSF 未経験者ばっかりなので，こうする方がむしろスケールすると判断)．全コードのレビューをしたり，ドキュメントをメンテしたり，TSF についての軽い Tech Talk をしたり，Windows のデバッグテクニックのレクチャーをしたり．あとはアーキテクチャ上の最終決定を行ったり (これは胃が痛かった…)．同僚がもりもりコードを書いてくれたのでほんと助かった．ぺこり．
もちろん反省点も色々ある．一番大きな反省点は，Chromium のコードレビューに不慣れな人間 (自分含む) がいることを考慮していなかったところ．アプリケーションの TSF 対応では，メッセージポンプやテキストウィジットに手を入れる必要がある．もちろんこれらは重要コンポーネント，大物レビュアーが出てくるし自然とレビューの目も厳しくなる．もうちょっとコミットログや事前の根回しに注意していれば，レビュー期間は半分以下に収まったんじゃないかと思う．最初のキックオフの時にレビュー対策を盛り込んでおけば…… このあたりの文化的背景については @omo2009 先生がすばらしい記事を書いていらっしゃるので興味がある人はこちらをどうぞ．

下から目線のコードレビュー

Handle IMR_QUERYCHARPOSITION even when there is no composition

コンポジション文字列が存在しない時でも IMR_QUERYCHARPOSITION に応答するという変更．実際には単にカーソル位置を返すだけ．

https://chromiumcodereview.appspot.com/11233028/

Mozc の TSF 対応を行なっている時に気づいた問題で，空文字列に対するITfContextView::GetTextExt でカーソル位置を取得するためにはこうなっていたほうが都合が良い，という変更．
ブラウザと IME 両方に手を出していると，楽な側で直せるというのは便利．具体的には以下の差が現れる．

Chromium 24 にてリリース予定．

2012年やったこと - Mozc 編

Tue, 01 Jan 2013 13:40:11 +0900

いままで仕事で書いたコード (Chromium とか Mozc とか) については基本的に言及しないようにしていたんですが，ソースコードが公開されている内容についてはまあいいかということでまとめてみます (もちろんソースコードが公開されていないことについても色々やってますが)．とりあえず Mozc 編*1．順序は概ね時系列．

Visual C++ 2010 対応

ちまちまとコンパイルエラーに対処．ビルドスクリプトを vcbuild に加えて msbuild にも対応させたぐらい．あとは gyp にも問題を見つけたので一件パッチを upstream．

http://code.google.com/p/gyp/issues/detail?id=244

1.3.975.10x にてリリース．

SHOW_INFOLIST_IMMEDIATELY compatibility flag

Windows 環境でのバグ．
Meadow 3.0 や NTEmacs 22 で Mozc を利用していると，用例ウィンドウが表示されないというバグ．Mozc 開発チーム内で発見されて回ってきたもの．
これの原因がなんというか脱力系．もともと用例ウィンドウは「最後の UI 更新から 500 ミリ秒経って何のアクションも起きていなければ表示する」というロジックで動いていた．ところが，Meadow 3.0 や NTEmacs 22 はポーリングを行っていて，より短い間隔で IME の UI 更新通知を送ってくる (実際には更新する必要がないケースでも)．これをトリガーとして候補ウィンドウの再レイアウトが行われるため，永遠に「最後の UI 更新から 500 ミリ秒経過」という条件が成立しない．
これらのアプリケーションではディレイなしに用例ウィンドウを表示するようにして対処．

http://code.google.com/p/mozc/source/diff?spec=svn96&r=96&format=side&path=/trunk/src/renderer/win32/win32_renderer_util.h&old_path=/trunk/src/renderer/win32/win32_renderer_util.h&old=93

1.3.975.102 にてリリース．

「半角空白を入力」が動作しないバグの修正

たまには変換エンジン側のバグも直してみようキャンペーン第一弾．
カスタムキーマップにて「半角空白を入力」「全角空白を入力」というコマンドが選択可能であるにも関わらず，特定条件でうまく動作しないという問題，の修正．

http://productforums.google.com/d/topic/ime-ja/uazENEhWlnQ/discussion

1.4.1003.10x にてリリース．

キャンセル後 IME を無効化

たまには変換エンジン側のバグも直してみようキャンペーン第二弾．
ATOK と MS-IME のデフォルト設定の違いのひとつに，IME をオフにしたときに未確定の入力文字列を確定させるかそれともキャンセルさせるか，というものがある (MS-IME では確定，ATOK の ATOK キーマップではキャンセルさせるのがデフォルト)．
これまでのバージョンの Mozc では MS-IME にあわせて確定させていたのだけど，やっぱり ATOK スタイルが良いという人もいる．そういう人のためにカスタマイズの幅を増やしてみたという変更．
といっても，これ以上コンフィグオプションを増やしたくはないよねということで，「キャンセル後 IME を無効化」というキーコマンド側を追加することで対処してみた．この方法だと，ATOK キー設定に自然に対応させられるのもよし．

ATOK (キーマップ) 派の人向けに実装しただけのつもりが，なぜか vim 方面の人に受けるという不思議な経験もした．

SSHを介してVimを使う人に感動的なESCキーを押すとESCキーが効きつつIMEがオフになる設定 - しふーのブログ

バージョン 1.4.1003.10x にてリリース．

サロゲートペア対応

クライアント側と変換エンジン側両方の修正．
Windows クライアントに関しては，実際サロゲートペア対応をサボっていたのでその対応を粛々と．再変換とか確定取り消し周りが地味にめんどくさかった．
変換エンジン側は，UTF-8 を UCS2 に変換して処理している箇所がいくつか残っていたのでその残党狩り．
この変更のおかげで，後の Unicode 絵文字対応がそこそこ楽になる．
バージョン 1.4.1003.10x にてリリース．

Mozc Issue 14

uim-mozc の開発者の人からのレポートで，Protocol Buffers のライブラリと動的リンクしていると，起動時にエラーになるので静的リンクに変更して欲しい，というもの．レポートから 1 年半以上放置されていたので見かねて修正．
ちなみに Debian/Ubuntu/Fedora/Vineはこの辺まるっと無視して今も動的リンクしていたはず．ほんと静的リンク嫌いますよね……

http://code.google.com/p/mozc/issues/detail?id=14

1.4.1003.10x にてリリース．

GCC 4.7 環境での warning つぶし

Linux 向け修正．
タイトル通り．
1.4.1003.10x にてリリース．

ibus_engine_delete_surrounding_text 対応

Linux の IBus 環境向け変更．IBus の比較的新しい API である ibus_engine_delete_surrounding_text を使用して，確定取り消し・再変換を実装するというもの．これ以前は Windows のようにバックスペースキーイベントを送っていた．
ちょうど Firefox 側に関連バグが登録されていたのだけど，Mozc 側の問題ということで対処できた感じになる．

1.4.1003.10x にてリリース．

gtest なしでのビルドのサポート

openSUSE のパッケージで，Mozc が gtest に依存するのを独自パッチをあててまで回避しているっぽかったので，そういうことをしなくて良いように上流側で対処してみた，というもの．
1.4.1033.10x にてリリース．

compiler_specific.h 導入

コンパイラ依存コードの便利マクロ集．Chromium の同名のファイルにインスパイアされたもの．この頃から Clang 対応を考え始める．

1.5.1053.10x にてリリース

cURL 依存の排除

Linux 向け変更．
OSS Mozc ではネットワーク機能を一切有効にしていないにもかかわらず，ビルドに cURL が必要という状態だったので，cURL なしでビルドできるようにしたというもの．
1.5.1053.10x にてリリース

QTBUG-25536 対策

Qt QString::toUcs4() がサロゲートペア領域の文字に対してうまく動かない，という問題に対する Mozc 側のワークアラウンド．

const uint kData[] = { 0x10000 };
QString test = QString::fromUcs4(kData, 1);
const QVector<uint> ucs4s = test.toUcs4();
if (ucs4s.size() == 1) {
    qDebug() << "correct";
} else {
    qDebug() << "wrong";
}

このコード，最新の Qt 5.0.0 でも正しく動かない．ので，Mozc から QString::toUcs4() の呼び出しを削除する方向で対処．

1.5.1053.10x にてリリース

X11 Selection monitor

Linux 向け．
ibus-mozc が GtkTextView でしか再変換ができなかったのを，もうちょっと対応環境を増やした，という変更．
諸悪の根源は，Gtk IM Module の get_surrounding_text がしょぼいことである．この API，カーソル周辺文字列 + カーソル位置しか取得できない．アンカー位置が取得できないため，現在選択されているテキストというのが分からない状態で再変換を実装しなければならない．
今回とった workaround は，xcb-xfixes を利用して，X11 のセレクションイベントをモニターするというもの．セレクションイベント経由で現在選択されているテキストを記録しておいて，get_surrounding_text で取得された周辺文字列 + カーソル位置と比較し，矛盾がないように選択領域を再構築する．
xcb とかはじめて使ったのでなかなかにおもしろかった．

あと，このコードを書いているときに Linux 版 Firefox にサロゲートペア絡みのバグを見つけたので，Bugzilla に報告したところ，Mozilla Japan の中野さんに直して頂けました．感謝．

https://bugzilla.mozilla.org/show_bug.cgi?id=757049

1.6.1187.102 にてリリース．

Mac OS X Lion でのビルド対応

対応したつもりになって 1 年近く放置してしまったバグの対処．

http://code.google.com/p/mozc/issues/detail?id=91

1.6.1187.102 にてリリース．

scim-mozc is removed

予告通り scim-mozc をリポジトリから削除．
直接の原因は内部のメンテナの不在．
まあ今更 SCIM もないでしょう．(Tizen を除く)

http://code.google.com/p/mozc/issues/detail?id=131

1.6.1187.102 にてリリース．

Debian-specific files are removed

Mozc のリポジトリに存在する Debian パッケージ定義ファイルがメンテナンスされていないので削除した，というもの．
ちょうど Debian 本家でメンテナンスされているパッケージ定義ファイルとの乖離が激しくなってきたところだったというのも理由のひとつ．

http://code.google.com/p/mozc/issues/detail?id=132

1.6.1187.102 にてリリース．

IBus 1.4.1 未満のサポート停止

IBUS_CHECK_VERSION マクロがあちこちに散らばっていたので，一カ所にまとめた上，旧バージョンのサポートと停止．だいぶコードが綺麗になる．

1.6.1187.102 にてリリース．

Clang 対応開始

Clang revision 159409 を使用して発生する warning を全て解消 (または suppress)．
1.6.1187.102 にてリリース．

Visual C++ 2012 対応

ちなちまとコンパイルエラーに対処．
1.6.1187.102 にてリリース．

#include <Windows.h> 撲滅運動

実に多くのヘッダファイルが不必要に #include <Windows.h> していることに気付きあちこち改良した，というもの．logging.h が <Windows.h> に依存するとかどうかと思う．

http://code.google.com/p/mozc/source/diff?spec=svn124&r=124&format=side&path=/trunk/src/base/logging.h&old_path=/trunk/src/base/logging.h&old=111

これでビルドがちょっとは速くなってくれるといいなぁと思いつつやったものの，目立っては高速化しなかった．残念．
1.6.1187.102 にてリリース．

Ack-less IPC

Windows の IPC レイヤの改善．いままでの IPC クライアントは，
1. メッセージ送信
2. 応答受信
3. Ack 送信
という手順を踏んでいたのを，3. でいきなり名前付きパイプを切断するように変更．切断イベントはどちらにしろサーバ側で検知可能なので，これを Ack イベントの代用とする．
実際これでレイテンシが数パーセント減ったのだから儲けものである．

http://code.google.com/p/mozc/source/diff?spec=svn124&r=124&format=side&path=/trunk/src/ipc/win32_ipc.cc

1.6.1187.102 にてリリース．

StringPiece の移植

Mozc の portable library に StringPiece がないのが気になっていたので，えいやっと用意した一品．StringPiece については hamaji さんの解説記事とか参照のこと．

http://code.google.com/p/mozc/source/browse/trunk/src/base/string_piece.h

1.6.1187.102 にてリリース．

テンキーにあるコンマに対応

Apple 日本語キーボードのテンキーには，ピリオドキーだけでなくコンマキーもあるのですが，これに対応できていなかったという問題の修正．
Mac では kVK_JIS_KeypadComma を使えば良いのですが，困ったのが Windows．
なんと Brazilian キーボードにはテンキーにコンマがあるらしく，その仮想キーコードは VK_ABNT_C2 (0xC2) とのこと．実際，Apple 日本語キーボードを Windows 7 につなげてテンキーのコンマを押してもこの仮想キーコードが返ってきました．互換性への執念恐るべし．
https://code.google.com/p/mozc/source/browse/trunk/src/win32/ime/ime_keyevent_handler.cc?r=124#253

  // The numpad comma on the Apple Japanese 109 keyboard is somehow mapped into
  // VK_ABNT_C2, which is only defined in kbd.h.
  // See also http://blogs.msdn.com/b/michkap/archive/2006/10/07/799605.aspx
  // See also b/6639635.
  KeyEvent::COMMA,                // 0xC2: VK_ABNT_C2

http://productforums.google.com/d/msg/ime-ja/7OWCjtKpssg/FS-PHlmxvagJ

1.6.1187.102 にてリリース．

2012年他にやったこと - Mozc 編 - NyaRuRuが地球にいたころに続く．

Chromium に関しては 2012年やったこと - Chromium 編 - NyaRuRuが地球にいたころに続く．

*1:ここでは OSS Mozc に限らず，いわゆる code-name Mozc についての活動

apt-get upgrade gcc considered harmful

Mon, 31 Dec 2012 22:04:00 +0900

いまの仕事に就いたことで触れることのできた興味深いソフトウェア開発手法のひとつに，成果物に関するものであれば何であれ"ソースコード"のバージョン管理システムに関連づけるというものがある．使用するライブラリは言うに及ばず，ビルドに使用するコンパイラのバージョンまでもを，ソースコードと同列にバージョン管理するわけだ．
このような環境で仕事を続けることしばし，ふと気付けば，多くの Linux ディストリビューションで喧伝されるうたい文句，「依存関係を賢く管理し，多数のユーザーによってテストされ，コマンド一発でインストールもアップデートもできる多数の開発ツール！」，というものは酷く色あせて聞こえるようになっていた．
むしろ逆だ．ソースコードのバージョン管理システムとは異なるコマンドによってコンパイラやライブラリのバージョンが変化する!? そんなものは悪い冗談にしか聞こえない．そこにはコミットログも存在しなければ，コミット前のスモークテストも存在しない．ブランチを切ることもできなければ，不具合を見つけてもソースコードのようにはロールバックすることもできない．

などというようなことを『継続的デリバリー』を読みつつうなずいていた年末．いやー，本に書いてあるようなお手本運用を間近で見つつ仕事できるってのは刺激になっていいですねー．それではみなさま，来年も良いビルドを．

サービスを最小特権で実行する

Mon, 15 Oct 2012 01:09:25 +0900

今回は Windows サービスを作成する上でのセキュリティ上のポイントを軽く紹介する．
Windows Vista では，サービスをより安全に実行するために Service Control Manager (SCM) の改善が行われている．ポイントとなるのは，必要特権リストの指定が可能になったこと，および制限された SID を割り当てられるようになったことだ．
たとえば，特定ファイルを物理メモリ上に保持し続けるサービスを作りたいとする．この処理をサービスにする必要があるのは，それが特権を必要とするからだ．VirtualLock API でロック可能なメモリ領域は通常 30 ページに制限されており，SetProcessWorkingSetSize API でその制限を拡大するには，SE_INC_BASE_PRIORITY_NAME 特権が必要である．しかし，単純に System アカウントで動くサービスを作ったのでは，余分な特権まで有効にされてしまう．これは最小特権の原則に反する．
ここで，以下のように ChangeServiceConfig2 API を利用することで，サービスに付与される特権を制限できる．

SERVICE_REQUIRED_PRIVILEGES_INFO privileges_info = {};
privileges_info.pmszRequiredPrivileges = SE_INC_BASE_PRIORITY_NAME _T("\0");
ChangeServiceConfig2(service_handle, SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO,
                     &privileges_info);

また，このサービスはファイルやレジストリに書き込む必要がない．そこで，以下のように設定することで，意図せずファイルやレジストリに書き込もうとしたときに失敗するように構成できる．

SERVICE_SID_INFO sid_info = {};
sid_info.dwServiceSidType = SERVICE_SID_TYPE_RESTRICTED;
ChangeServiceConfig2(service_handle, SERVICE_CONFIG_SERVICE_SID_INFO,
                     &sid_info);

このように設定したサービスを起動し，Process Explorer でセキュリティ情報を見てみる．

Restricted SID が設定されていること，"NT AUTHORITY\WRITE RESTRICTED" SID が設定されていること，特権が大幅に削除されていることなどがわかる．
実際，OS 標準のサービスは概ね最小特権で実行されている一方で，(残念ながら Microsoft Office を含む) OS 非標準のサービスは，デフォルトの特権を持ったまま動作しているものがほとんどだ．例えば，Office 2010 に付属する ImeDictUpdateService (Microsoft IME Dictionary Update) のセキュリティ属性は以下のようになる．

デフォルトで付与される全ての特権を持ったまま実行されていることが分かる．これが本当に IME の辞書アップデートサービスであるなら，SeDebugPrivilege (スーパー特権のひとつ．プロセスのセキュリティ設定を無視して，(保護されたプロセスをのぞく) すべてのプロセスを開くことができる．) や，SeTimeZonePrivilege (文字通りタイムゾーンを設定するための特権) をはじめとした，多くの特権を削除しても恐らく動作は可能だろう．

参考

インサイドWindows 第6版上 (マイクロソフト公式解説書) であれば，P.352 「4.2.2 サービスアカウント/最小特権」あたりに詳しい．その他の参考資料については以下など．

AppContainer 導入による Windows 開発への影響

Mon, 08 Oct 2012 18:58:04 +0900

Windows 8 では，AppContainer と呼ばれる新たな Sandbox メカニズムが導入される．Windows ストアアプリ (旧名: Windows Metro アプリ) や，Immersive モードの Internet Explorer のレンダリングプロセスなどが AppContainer で動作するプロセスの代表格だ．Windows ストアアプリ制作者にとって AppContainer が重要になるのはもちろんのこと，Windows ストアアプリ内で動作する必要のある IME やアクセシビリティ系ツールの制作者も，AppContainer について理解する必要がでてくる．

AppContainer プロセスを確認する

Process Explorer 15.23 を用いて，AppContainer プロセスの特徴を確認してみよう．以下は Windows 8 付属の「ミュージック」アプリを起動し，Process Explorer にて表示してみたところだ．
まず目に付く点として，WWAHost.exe プロセスの Integrity 欄に AppContainer と表示されていることが挙げられる．

次に WWAHost.exe プロセスのプロパティを表示し，Security Tab を選択してみる．プロセスのグループ一覧に，AppContainer と Capability という見慣れないグループがある．

前者は Windows ストアアプリごとに割り当てられるユニークな SID である．Android 環境でアプリケーションごとに User ID が割り当てられるのと似ている．後者の Capability は，この Windows ストアアプリに許可された動作と対応している．「ミュージック」アプリは，

インターネット接続へのアクセス
ミュージックライブラリへのアクセス

が許可されているようだ．
このように，AppContainer は，従来のトークン/SIDによるアクセス制御の拡張として実装されていることが分かる．例としては，Windows ストアアプリごとに SID が付与されることから，ある Windows ストアアプリにだけ，特定ディレクトリ以下へのアクセスを許すようなポリシーを設定することも可能である．

あるプロセスが AppContainer に属しているかどうかをプログラム的に判定する

あるプロセスが AppContainer に属しているかどうかをプログラム的に判定するには，プロセスのトークンハンドルに対して GetTokenInformation API を使用する．Windows 8 (SDK) 以降では TokenIsAppContainer フラグが使用でき，ここで 0 が返ってこなければプロセスは AppContainer で動作している．

あるプロセスが Immersive Mode かどうかをプログラム的に判定する

あるプロセスが没入型 UI を使用しているかどうかの判定には IsImmersiveProcess API を用いる．この用途で GetTokenInformation/TokenIsAppContainer フラグを使用するべきではない．なぜか？
それは Windows ストアアプリ風アプリケーション全てが AppContainer 内で動作するわけではないからだ．ブラウザという大きな例外がある．
「Metro スタイル対応デスクトップブラウザーの開発」というホワイトペーパーに解説されているとおり，Windows 8 対応のブラウザには以下の 3 種類が存在する．

Windows Store app: AppContainer 内で動作する
Desktop browsers: Windows 7 までと同様のモデルで動作する．Win32 API にフルアクセスが可能で，JIT コンパイルや様々なマルチプロセス技術が利用可能．
New experience enabled desktop browser: Windows ストアアプリ風の没入型 UI を備えつつ，Win32 API にフルアクセスが可能で，JIT コンパイルや様々なマルチプロセス技術が利用可能．

この 3 つ目が問題だ．結果として，没入型 UI かどうかの判定と AppContainer で動いているかどうかの判定は分けて考える必要がある．

AppContainer の SID を取得する

プロセスのトークンハンドルに対して GetTokenInformation API を使用する．Windows 8 (SDK) 以降では TokenAppContainerSid フラグが使用でき，ここで返ってきたものが AppContainer の SID である．

AppContainer プロセスのオブジェクト名前空間

引き続き，Process Explorer で AppContainer の動作を調べてみる．「View」→「Lower Pane View」から「Handles」を選択し，プロセス内で開かれているハンドル情報を調べてみよう．
開かれているハンドル名を見ていくと，セッション名前空間にさらに AppContainer SID が接頭辞として付加されていることに気付く．

\Sessions\1\AppContainerNamedObjects\S-1-15-2-43664394-2685677502-394080391-3933305958-4167273977-1510959782-2102270723\RPC Control\OLE36E12F064548B659D96055B91BF5

これに対応すると考えられる GetAppContainerNamedObjectPath API の Remarks が興味深い．この Remarks は，アクセシビリティ系など，別プロセス内で動作するツールに向けて書かれたものだ．

For assistive technology tools that work across Windows Store apps and desktop applications and have features that get loaded in the context of Windows Store apps, at times it may be necessary for the in-context feature to synchronize with the tool. Typically such synchronization is accomplished by establishing a named object in the user's session. Windows Store apps pose a challenge for this mechanism because, by default, named objects in the user's or global session are not accessible to Windows Store apps. We recommend that you update assistive technology tools to use UI Automation APIs or Magnification APIs to avoid such pitfalls. In the interim, it may be necessary to continue using named objects.
GetAppContainerNamedObjectPath

デフォルトでは Windows Store アプリからは従来の名前付きオブジェクトにアクセスできないものの，アクセス権を設定しさえすればデスクトップアプリと Windows Store アプリの間で名前付きオブジェクトを共有することが依然として可能であることが示唆されている．なお，これは暫定的な措置であり，本来は UI Automation API や拡大鏡 API を用いて対処して欲しいようだ．

All Application Packages グループを利用したアクセス制御

実は，Windows 8 では ALL APPLICATION PACKAGES と呼ばれる特殊なグループが追加されている．このグループへのアクセス許可を設定することで，Windows Store アプリに一括して動作の許可や拒否を設定することができる．
これについては，ファイルシステムの例がわかりやすい．%SystemRoot% や %ProgramFiles% のセキュリティ設定を見てみよう．Windows 8 では，デフォルトで ALL APPLICATION PACKAGES グループに対する「読み取りと実行」「フォルダーの内容の一覧表示」「読み取り」アクセスが許可されている．

仮に IME を開発するのであれば，仮に AppContainer 内で動作する場合であっても，ACL 的にはこれらのディレクトリ (以下) に配置された設定ファイルや辞書データは自由に読み取りできるものと考えられる．
また，試したわけではないが，AppContainer 内で動作する Windows Store アプリであっても，%ProgramFiles% 以下にインストールされたアプリケーション一覧や置かれたファイルの内容を取得することぐらいは可能なのかもしれない．これらの領域にセキュリティやプライバシーに関わるデータが置かれる場合は，悪意のある Windows Store アプリに読み取られる恐れがないか改めて確認されたい．
さて，ALL APPLICATION PACKAGES だが，ファイルオブジェクト以外にも当然利用されているようだ．
以下は，TSF が利用していると思われる Mutex オブジェクトのセキュリティ情報である．

ALL APPLICATION PACKAGES に同期とクエリ許可が与えられていることが分かる．このように，DACL を設定することで，Windows Store アプリとデスクトップアプリの間で名前付きオブジェクトを共有することが可能になるのだろう．
Windows Store アプリとデスクトップアプリの間のプロセス間通信についてもいずれいくつか書いてみたい．

参考

Accessing named objects from an AppContainer
- AppContainer から名前付きオブジェクトにアクセスしたいというそのものずばりな質問
Research, Develop, Assess, Consult & Educate | Recx: Windows 8 App Container Security Notes - Part 1
- AppContainer まとめ
Managing Client Access to the Windows Store

Google Chrome をデバッグする (1)

Sun, 30 Sep 2012 01:51:28 +0900

Google Chrome のデイリーリリースバージョンは，炭鉱にて危険をいち早く察知するカナリアにたとえられ Canary 版と呼ばれている．
(炭鉱で戦うものたちの熱い物語については『炭鉱の庭師』を参照されたい)
Google Chrome Canary 版は以下のページからインストールできる．
https://tools.google.com/dlpage/chromesxs
Canary 版と安定版は，インストール先フォルダから使用するプロファイルまで異なる別アプリケーションである (Side-by-side インストールと呼ばれている)．両者を同時に起動することももちろん可能だ．また，Canary 版であっても Google Update の対象になることから，一度インストールしてしまえば後は自動で trunk を追いかけてくれる．
実は，Canary 版にはもうひとつ大きな特徴がある．それは，ビルドの副産物であるデバッグシンボルが公開されていることだ．ここで，デバッグシンボルが公開されていることで何が可能になるかについて，数回にわたって紹介してみたい．

シンボルサーバの登録

Windows エコシステムでのシンボルサーバの登録には，環境変数 _NT_SYMBOL_PATH を使用するのが一般的だ．Microsoft のシンボルサーバと Chrome のシンボルサーバを登録する場合，_NT_SYMBOL_PATH は次のように設定することになる．

_NT_SYMBOL_PATH=srv*c:\SymCache*http://msdl.microsoft.com/download/symbols;srv*C:\SymCache*http://chromium-browser-symsrv.commondatastorage.googleapis.com

"C:\SymCache" は別の名前に変更することも可能である．このフォルダにダウンロードされたシンボルデータがキャッシュされるので，なるべく高速なドライブを設定すると良い．
次に，よく利用する Sysinternals のツール群についてもシンボルパスを設定する．

Process Explorer と Process Monitor それぞれで，Options から Configure Symbols を選択する．Dbghelp.dll path については，Windows SDK 付属のものを選ぶとよい．64-bit 環境では x64 版の Dbghelp.dll を選択しよう．Symbol paths については先ほど同様に以下を設定する．

srv*c:\SymCache*http://msdl.microsoft.com/download/symbols;srv*C:\SymCache*http://chromium-browser-symsrv.commondatastorage.googleapis.com

Process Explorer を利用したハングアップ解析

Google Chrome Canary 版が無反応になったなら，Process Explorer を起動してみよう．デバッグシンボルが完備されていればその場でスレッドのコールスタックを見るのも容易である．(ただし，ここで最も慎重な次の一手はプロセスダンプをとることだ)
状況の保全のため，プロセスの全スレッドを中断させてみよう．一般的に，Chrome のウィンドウが無反応になったときには Chrome のブラウザプロセスの問題である．Process Explorer の "Process" 欄を何度かクリックして，表示モードをプロセスツリーに変更しよう．ここでルートに当たる chrome プロセスがブラウザプロセスである．(別の識別法として，プロセスの起動引数に --type オプションが付いていないプロセスを選ぶという方法もある)

ブラウザプロセスを見つけたら，コンテキストメニューから Suspend を選択する．これでブラウザプロセスの動作が中断する．動作を中断させたら，コンテキストメニューから Properties を選択し，Threads タブに移動する．

ここでスレッドを選択し Stack ボタンをクリックすると，該当スレッドのコールスタックが表示される．

コールスタックを表示すると，非同期でシンボルのダウンロードが始まる．しばらくすると，Chrome のどういった関数が呼び出されていたのかが表示されるだろう．UI スレッドを探し出し，そのコールスタックを探し当てたら，それがハングアップの現場である．

Process Monitor を利用した I/O モニタリング

Process Monitor を利用することで，以下のような動作のモニタリングが可能になる．

任意のファイルアクセス
任意のレジストリアクセス
任意のプロセス起動/スレッドイベント/DLL のロードとアンロード
任意のネットワークアクセス

シンボルがセットされていると，これらの各イベント発生時のコールスタックが取得できるようになる．また，Tools メニューの各 Summary 項目から，選択したイベントの集計やクロス集計も可能である．例えば，プロセス起動時から終了時までの間にあるファイルへ行われた全てのファイルアクセスについて，コールスタックごとにその割合を分析するといったことが可能だ．

Chrome を起動してあるページをブラウズし，終了するまでの間に行われた約 2000 回のファイル読み取りアクセスを，コールスタックを用いてブレイクダウンしている図

Process Monitor を用いた解析テクニックについては，例えば次の記事などが参考になる．

次回，API モニタ編に続く．

SSD なら動作を変えるアプリケーションを作る

Sat, 29 Sep 2012 06:38:29 +0900

Windows 7 以降の OS では，SSD 上のボリュームに対してデフラグがスケジューリングされません．これと同様に，ドライブ特性に応じた動作戦略の変更をアプリケーションでも行いたいこともあるでしょう．そのような場合にアプリケーションに組み込めるように，簡単なサンプルコードを書いてみます．
元ネタは，
Windows 7 Disk Defragmenter User Interface Overview - The Storage Team at Microsoft - File Cabinet Blog - Site Home - TechNet Blogs
で解説されているアルゴリズムです．

以下，物理ドライブ "\\.\PhysicalDrive0" について，"no seek penalty" かどうかと，"nominal media rotation rate" かどうかの取得を行います．なお，前者はディスクポートドライバの動作に依存するため，Windows 7 以降でなければ使用できませんが，管理者権限なしで動作するというメリットがあります．後者は ATA8-ACS に対応したデバイスであれば，Windows 7 より前の OS でも動作しますが，動作には管理者権限が必要です．
上記記事に解説されているように，これらの関数を組み合わせて使ってもよいですし，どちらか一方のみを使いある程度の false negative は諦めるという手もあります．

#include <Windows.h>
#include <WinIoCtl.h>
#include <Ntddscsi.h>
#include <Setupapi.h>

#include <iostream>
#include <string>

using std::wstring;
using std::wcout;
using std::endl;

// Returns S_OK if |physical_drive_path| has no seek penalty.
// Returns S_FALSE otherwise.
// Returns E_FAIL if fails to retrieve the status.
// |physical_drive_path| should be something like
// "\\\\.\\PhysicalDrive0".
HRESULT HasNoSeekPenalty(const wstring& physical_drive_path) {
    // We do not need write permission.
  const HANDLE handle = ::CreateFileW(
      physical_drive_path.c_str(), FILE_READ_ATTRIBUTES, 
      FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
      OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  if (handle == INVALID_HANDLE_VALUE) {
    return E_FAIL;
  }

  STORAGE_PROPERTY_QUERY query_seek_penalty = {
    StorageDeviceSeekPenaltyProperty,  // PropertyId
    PropertyStandardQuery,             // QueryType,
  };
  DEVICE_SEEK_PENALTY_DESCRIPTOR query_seek_penalty_desc = {};
  DWORD returned_query_seek_penalty_size = 0;
  const BOOL query_seek_penalty_result = DeviceIoControl(
    handle, IOCTL_STORAGE_QUERY_PROPERTY,
    &query_seek_penalty, sizeof(query_seek_penalty),
    &query_seek_penalty_desc,
    sizeof(query_seek_penalty_desc),
    &returned_query_seek_penalty_size, NULL);
  CloseHandle(handle);
  if (!query_seek_penalty_result) {
    // failed to retrieve data.
    return E_FAIL;
  }

  return !query_seek_penalty_desc.IncursSeekPenalty ?
      S_OK : S_FALSE;
}

// Returns S_OK if |physical_drive_path| has nominal media
// rotation rate in terms of ATA8-ACS specification.
// http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4-ATA8-ACS.pdf#Page=179
// Returns S_FALSE otherwise.
// Returns E_FAIL if fails to retrieve the status.
// |physical_drive_path| should be something like
// "\\\\.\\PhysicalDrive0".
HRESULT HasNominalMediaRotationRate(
    const wstring& physical_drive_path) {
  // In order to use IOCTL_ATA_PASS_THROUGH,
  // We *do* need read/write permission, which means
  // that the caller has admin privilege.
  const HANDLE handle = CreateFileW(
    physical_drive_path.c_str(),
    GENERIC_READ | GENERIC_WRITE, 
    FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
    OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
  if (handle == INVALID_HANDLE_VALUE) {
    return E_FAIL;
  }

  struct ATAIdentifyDeviceQuery {
    ATA_PASS_THROUGH_EX header;
    WORD data[256];
  };

  ATAIdentifyDeviceQuery id_query = {};
  id_query.header.Length = sizeof(id_query.header);
  id_query.header.AtaFlags = ATA_FLAGS_DATA_IN;
  id_query.header.DataTransferLength =
      sizeof(id_query.data);
  id_query.header.TimeOutValue = 3;  // sec
  id_query.header.DataBufferOffset =
      sizeof(id_query.header);
  id_query.header.CurrentTaskFile[6] =
      0xec;  // ATA IDENTIFY DEVICE command

  DWORD retval_size = 0;
  const BOOL result = DeviceIoControl( 
    handle, IOCTL_ATA_PASS_THROUGH,
    &id_query, id_query.header.DataTransferLength,
    &id_query, id_query.header.DataTransferLength,
    &retval_size, NULL);
  if (!result) {
    return E_FAIL;
  }
  const int kNominalMediaRotRateWordIndex = 217;
  // RPM == 1 means this is non-rotate device
  return id_query.data[kNominalMediaRotRateWordIndex] == 1 ?
      S_OK : S_FALSE;
}

int main() {
  const wstring kDrive = L"\\\\.\\PhysicalDrive0";

  switch (HasNoSeekPenalty(kDrive)) {
    case S_OK:
      wcout << kDrive << L" has no seek penalty." << endl;
      break;
    case S_FALSE:
      wcout << kDrive << L" has seek penalty." << endl;
      break;
    default:
      wcout << L"failed to retrieve the status." << endl;
      break;
  }
 
  switch (HasNominalMediaRotationRate(kDrive)) {
    case S_OK:
      wcout << kDrive << L" has no seek penalty." << endl;
      break;
    case S_FALSE:
      wcout << kDrive << L" has seek penalty." << endl;
      break;
    default:
      wcout << L"failed to retrieve the status." << endl;
      break;
  } 

  return 0;
}

さて，"C:\Windows\System32\calc.exe" のようなパス名から，そのファイルが存在する物理ドライブ名を取得するにはどうすればよいでしょうか？
これには，

GetVolumePathName API を利用してパスからマウントポイントを取得する
GetVolumeNameForVolumeMountPoint API を利用して，論理ボリューム名を取得する
IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS IO Control を利用して，物理ドライブの番号を取得する

という手順を踏みます．後は，得られた番号を "\\.\PhysicalDrive" の末尾に付ければ，物理ボリューム名が判明します．
なお，ダイナミックボリュームでは，複数の物理ドライブにまたがった論理ボリュームが作成可能なことに注意してください．以下の関数は，指定されたパスに対応する物理ドライブ番号を返します．

vector<int> GetExtentsFromPath(const wstring& path) {
  vector<int> extents;

  wchar_t mount_point[1024];
  if (!GetVolumePathNameW(
        path.c_str(), mount_point, ARRAYSIZE(mount_point))) {
    return extents;
  }

  wchar_t volume_name[1024];
  if (!GetVolumeNameForVolumeMountPointW(
          mount_point, volume_name, ARRAYSIZE(volume_name))) {
    return extents;
  }

  wstring volume = volume_name;

  // remove trailing '\\'
  volume.resize(volume.size() - 1);

  // We do not need write permission (nor admin rights).
  const HANDLE volume_handle = CreateFileW(
      volume.c_str(), FILE_READ_ATTRIBUTES, 
      FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
      FILE_ATTRIBUTE_NORMAL, NULL);

  VOLUME_DISK_EXTENTS initial_buffer = {};
  DWORD returned_size = 0;
  const BOOL get_volume_disk_result = DeviceIoControl(
      volume_handle, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS,
      NULL, 0, &initial_buffer, sizeof(initial_buffer),
      &returned_size, NULL);
  const DWORD query_size_error = GetLastError();
  if (get_volume_disk_result != FALSE &&
      initial_buffer.NumberOfDiskExtents == 1) {
    extents.push_back(initial_buffer.Extents[0].DiskNumber);
    return extents;
  }
  if (query_size_error != ERROR_MORE_DATA) {
    return extents;
  }

  const size_t buffer_size =
      sizeof(initial_buffer.NumberOfDiskExtents) + 
      sizeof(initial_buffer.Extents) *
      initial_buffer.NumberOfDiskExtents;
  char* underlaying_buffer = new char[buffer_size];
  VOLUME_DISK_EXTENTS* query_buffer =
      reinterpret_cast<VOLUME_DISK_EXTENTS *>(
          &underlaying_buffer[0]);
  const BOOL devide_ioc_result = DeviceIoControl(
      volume_handle, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS,
      NULL, 0, 
      query_buffer, buffer_size, &returned_size, NULL);
  const DWORD device_detail_result_error = ::GetLastError();
  if (!!devide_ioc_result) {
    for (DWORD i = 0;
         i < query_buffer->NumberOfDiskExtents; ++i) {
      extents.push_back(query_buffer->Extents[i].DiskNumber);
    }
  }
  delete[] underlaying_buffer;
  CloseHandle(volume_handle);
  return extents;
}

幸いなことに，上記処理は管理者権限なしでも動作します．Windows 7 以降では，管理者に昇格する必要なしに，SSD 上で動作しているらしいかどうかをアプリケーションが判別できるということになります．

Metro スタイルアプリケーションと IME

Tue, 19 Jun 2012 00:00:03 +0900

Metro では，AppContainer という特殊な環境でアプリケーションが実行されます．IME DLL は *1，対象の Metro スタイルアプリケーションプロセスに読み込まれ，AppContainer の管理下で動作することが求められます．

実際，Microsoft は Windows 8 Release Preview の公開に合わせ，Guidelines and checklist for IME development (Metro style apps) というガイドラインの提供を開始しました*2．同ドキュメントには，AppContainer 内で IME の機能を実装する上で，次のようなケースに注意せよとあります．

辞書ファイルの置き場所
インターネットを利用したアップデート
学習機能
プロセス間での(設定や学習)情報の共有

同ドキュメントには，IME の学習機能や，プロセス間での(設定や学習)情報の共有機能の実装方法として，その AppContainer で可能であればウェブサービスを経由してこれらの機能を実装するよう書かれています．Mac や Android のように IME プロセスを分離してくれていれば，IME 単体に別のアクセスコントロールを適用することも可能だったのでしょうが……

なお，Metro アプリケーションとデスクトップアプリケーションでは，利用可能なテクノロジに違いがあります．詳細については API reference for Metro style apps から辿ることができます．Metro 対応 IME では IMM32 ではなく TSF を使う必要があることはガイドラインで明記されていましたが，その他の API についてははっきりとは書かれていません．公開されると言われている Metro 対応 IME サンプルでも読まないとはっきりしない予感がします．
なお，こうして作られた IME DLL は，従来のデスクトップアプリケーションに読み込まれても動作する必要があります．まさに Run Anywhere，Universal Binary というわけです．

*1:Metro スタイルアプリケーションは，TSF のみのサポートとなりますから，IME というより Text Input Processor; TIP DLL と呼ぶ方が適切かもしれませんが

*2:一方で，予定されていた Metro アプリ用 IME サンプルに関する情報は[http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/6abc8b91-110c-4d60-b5b7-e113144902d9:title=削除されました]．

NyaRuRuが地球にいたころ

Android 9.0 に追加した API

Android 8.1 に追加した API

Android 8.0 Oreo に追加した API

2015 年やったこと - Mozc 編

コミット単位でみる作業まとめ

Windows XP 向けコードの削除

Android 版の不要なコードの削除

Visual C++ 2013 への移行

Visual C++ 2015 への移行準備

C++ 11 対応

実験的コードの削除

ibus-mozc 廃止に向けた下準備

GitHub への移行と Continuous Integration (CI) の整備

Travis CI のセットアップ

AppVeyor のセットアップ

gclient から git submodule への移行

Windows 10 対応

不安定なテストの改善

透明度付き PNG ファイルを PBGRA32 形式の Bitmap ファイルの変換するツールを作成

雑感

過去の関連エントリ

Android 7.1 に追加した API

Android 7.0 Nougat に追加した API

Windows 10 Insider Preview Build 14332 実験ノート: ブラウザと IME のプライベートモード連携

疑問点

今回の調査結果

そもそも Internet Explorer / Edge と MS-IME はどのようなプロトコルでこの動作を行っているのか?

サードパーティ製のブラウザと MS-IME の組み合わせで同じことができるか?

Internet Explorer / Edge とサードパーティー製の IME で同じことができるか?

調べたこと

得られた知見

フィードバックアイディア

関連事例

(同一プロセスで動く IME で使うことを前提とした) Accessibility API を利用したプライベートモード検出

Chromium Bug 311180: Chrome OS: Incognito window is not really incognito for IME users

Chromium Bug 601951: Android keyboard suggestions leak information typed in incognito window

改定履歴

My OSS Wish List

OSS Mozc 関係

[Mozc] Windows 版向けのインストーラーをビルドできるようにする

[Mozc] DirectWrite を使うと真っ白になる問題を再現させる

[Mozc] ソースコードのチェックアウトプロセスから Subversion 依存を取り除く

[Mozc] 依存する外部リポジトリの管理を gclient から Git submodule に変更

[Mozc] ibus-mozc の削除

[Mozc] tsf-mozc の Windows 10 関係の互換性問題の調査

[Mozc] Windows 環境での縦書きサポート

[Mozc] Qt 5.x への移行

[Mozc] Linux および Android 向け Continuous Build / Test 環境の整備．

[Mozc] その他溜まっている OSS Mozc の更新

GYP 関係

[GYP] Revert された 540e4b1e665 の再有効化

Chromium 関係

[Chromium] Web MIDI の実装に Windows 10 の新 MIDI API が使えるか調査

[Chromium] その他 Chromium の Web MIDI サポートで担当者募集中バグの修正

[Chromium] Android Lollipop で追加された新 IME API のサポート

Firefox 関係

[Firefox] Android Lollipop で追加された新 IME API のサポート

Docker 上に IPython Notebook 実行環境を作って DeepDream を動かす

Deep Neural Network 素人であるところの筆者が理解できた範囲の話の背景

なぜ Docker を使うのか

(Docker) ホスト Linux

Docker コンテナのダウンロードとインストール

Docker コンテナの実行

DeepDream IPython Notebook チュートリアルの実行

さらに DeepDream を楽しむために

パラメータを変える

ホスト環境のディレクトリを Docker コンテナ内に見せる

その他の実装

Future Work

2014 年やったこと - Mozc 編

実は 2013 年にやっていたこと

Windows 版での候補ウィンドウのカラー絵文字対応

候補ウィンドウの DirectWrite 対応

ITfFnReconversion::GetReconversion 対応

2014 年にやったこと

TF_E_NOLAYOUT 問題

TSF を有効にした Firefox がフォーカスを失ったとき候補ウィンドウが表示されたままになる

Issue 206: 特定ロケールの Windows 環境で prediction/dictionary_predictor.cc をビルドすると C2065 エラーで失敗する

Issue 215: mozc::Encryptor 実装のポータブル化