サードパーティ製IMEは、Web Browserのプライベート・シークレットウィンドウなんて考えてくれない

最近のブラウザは、プライベート・シークレットモードが搭載されている。このモードになれば、ブラウザはCookieを保存しないとかいろいろプライバシーを考慮された動作になる。 ただ、いくつかの言語 (とAndroidのようなソフトウェアキーボードを使う場合)、IMEというものを仲介して文字を入力するため、プライベートモードであっても入力履歴はIMEが保存してしまうかもしれない。そのため、入力履歴を学習しないようにするのを通知する機能というのがある。

Androidで言えば、InputMethods.IME_FLAG_NO_PERSONALIZED_LEARNING、Windows 10 20H1以降のText Service FrameでのIS_PRIVATEがそれだ (IS_PRIVATEの話は以前のブログ参照)。なお、GTKも4以降で機能を追加してもらった。この機能を使うことでプライベートモードであれば入力履歴を学習しないようになる。ChromiumやFirefoxではこれを使っているのでプライベートモードでは学習しないようにしてる。

ただ、この機能が動作する条件がもう一つあって、IME側でも対処が必要であるということ。この機能をちゃんと使うのは純正IME (Androidで言えばGBoardとかGooglen日本語入力、Windowsで言えばMicrosoft IME) くらいしかない。Androidの場合だとサードパーティ製IMEでこれを使っているのはあるかもしれないけど、どうも徳島にある某社のATOK (Windows版、Android版) はこの機能を使ってない模様。自分としては (毎月330円払っているユーザーとして)直してほしいのだけど、彼等はこういうところに興味がないから言ったとしても難しそうな気がする。

なお、ここで触れてない (本社がクパチーノにある) 某OS は未だに存在しない機能の模様なのだが、プライバシーとかを最近重視しているのであれば、実装してほしい。

IS_PRIVATE on Windows 10 20H1

昔書いたHow to use Microsoft IME's private mode on not IE/Edigeの続きの話。

このとき調べたようにMicrosoft IMEにおけるPrivate Mode (変換情報を学習しない) という機能は、Microsoft IMEがIE内部の隠しAPIを呼ぶことで実現してた。そのためMicrosoft EdgeやInternet Explorerでのみ使える機能で他社のWeb Browserでは使うことができなかった (というかWeb Browserに限定しないけど)。

で時は過ぎ、Microsoft EdgeがChromiumベースになることになった。Chromiumベースになったということでこれで晴れて公開APIができると思ったけど、全くそんなことはなかった。ただ、非常に面白いパッチがChromiumに入った。

For TSF1 on Windows 10, we need to set input scope to IS_PRIVATE if we
are in "Incognito" or "guest" mode.

Bug: 958054
Change-Id: I35e4adec0fd1800cff1ec2fcfe7983e2a65540e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1591886
Commit-Queue: Siye Liu 
Reviewed-by: Yohei Yukawa 
Cr-Commit-Position: refs/heads/master@{#657438}

この修正を見たところ、「以前Microsoft IMEはIS_PRIVATEを見てないはずなのに。もしかしてWindows Insiderビルドで直ってたの？」と思ったのだけど、ダウンロード可能なWindows Insiderビルド+Chrome Canaryで全然直ってない。あれ？ということで、MicrosoftのIMEチームへ直接コンタクトしてみたところ、「IMEチームのバグリストには存在してるんですが。。。」的な回答が返ってきた。さすが自分がいたころ (10年以上前) と一緒で、縦割りすぎて横連携できない会社のままだなぁと思ったのだが、それで放置しても誰も得をしないので、IMEチームの人といろいろやり取りして、Windows 10 20H1のMicrosoft IMEではInputScopeのIS_PRIVATEを見るようにしてもらいました。IS_PRIVATEをつけてる場合は、IMEは学習しないようになっているため、もしアプリケーションでIMEの学習機能を無効にしたいのであれば、IS_PRIVATEを使ってください。FirefoxでもWindows 10 20H1を使えばプライベートモードであれば学習しないようにしてます。

Edge/ARM64の出来をみると、Windows on ARMのx86エミュレーターは結構速い

WebCrypto APIのベンチマークというのは結構難しくて、そもそも現在のWebCrypto APIはPromiseベースの実装のため、下手をするとWebブラウザに実装されたマイクロタスクをテストするだけのものになることもある (≒なのでベンチマークを取るとったとしても正確なデータかというと、、、な時がある。WebCryptoを使ったベンチマークを説明する時にPromiseの話を触れない人は正しいマイクロベンチマークを書くことが出来ない人なのかもしれない)。Promiseで結果を返すようなAPIはベンチマークが正しい結果を出すとは限らないのだが、それを抜きにしても面白いデータが取れたのでここに書いておく。

jsperf.comに簡単なWeb Cryptoのベンチが置いてあったのだけど、まずx86版ChromeをWindows 10 on ARMで動かしたデータが以下になる。

これをARM64版Edgeで実行すると以下になる。

なんとx86版のほうがAESのベンチマークが圧倒的に速いという結果になる。これはx86版はAES-NIをちゃんと使っていて、x86エミュレーターがちゃんとAES-NIをARM専用命令に置き換えているからと思われる。

ARM64にもAESは専用命令があるのだが、OpenSSL/BoringSSLでは、アセンブラで書かれているコードでARMの専用命令を使っていて、これはGNU AS用のアセンブラコードなので、MicrosoftのARM RealView形式のアセンブラと互換性がないから、おそらく無効にされているのだろう。

なお、ARM64版Firefoxだとこういう結果になる

これはちゃんとしたネイティブ実装 (by 自分) をしており、AESとSHA2はARM Crypto Extensionを使った実装になっているので、ちゃんとネイティブの方が速い。

ネイティブ版でも必ずしもエミュレーターよりも常に速いわけではない。というよりも、もっとARMに対してやる気出せよ、Microsoftと。

Windows 10 + Snapdragon 835を採用したASUS NovaGoを手に入れてみた

これはWindows/arm64 (Windows on Arm) を採用し、Snapdragon 835を搭載したラップトップ。まずこのarm64を採用したWindowsの最初のリリースはHP Envy x2とこのASUS NovaGoとLenovo Miix 630はこの3機種。HPのは3月リリース、Lenovoのは6月。ASUSは4月くらいにはリリースされてたようなんだけど、6月になってやっと手に入りやすくなった。NovaGoがAmazon.com (US)で入手可能になったので手に入れてみた。なおUSのMicrosoft Storeでもオーダー可能になってる (日本へ発送可能かは知らない)

お値段は、本体価格が699ドル+送料で、781.08ドル。輸入コストも考えると比較的安く手に入った。(ホントは6月にアメリカ行ってる時に現地で入手したかったけどどこにもなかった)

普通に起動 & セットアップして、Windows Sモードを解除 (Microsoft StoreでWindows 10 Proを入手すればいいだけ。無償) した後、いろいろテストしてみた。

アプリケーション

• Edgeは当然のことながらネイティブアプリケーション
• x86なアプリケーションを動かすためのJITはXTCACHEというプロセスがやっている模様
• arm64なネイティブアプリ以外にも、arm 32bit (ARMNTと呼ばれるThumb2モードのみのもの。Surface RTとかWindows Phone 8以降で使ってたモード。これもネイティブで動作可能)、x86 (これはJIT使って動的にarm64へ変換してるはず)、と3つのアーキテクチャをサポートしてる
• \Windows\SysWow64、\Windows\SysArm32、\Windows\System32と各CPUモード毎にSystem32ディレクトリがある。なお、\Program Filesも\Program Files (Arm)とか\Program Files (x86)とか存在する
• Windows Subsystem for Linuxはversion 1803に上げると使える。
  
• Internet Explorer 11も含まれているけど、どうもx86版のみ
  
• Firefox (x86)は動作するけど、Chrome (x86)はVersion 1709だとちょくちょくクラッシュする。Version 1803にすれば安定するし、パフォーマンスもちょっとよくなる

WebブラウザのJITで生成されたコードをJITでarm64に変換するのはよりコストがかかる (モジュールだったら一回コンパイルした後キャッシュ持てばいいだけだし) ので、もっと遅いかと思ったら、まぁこんな程度でしょう的な感じ。これはFirefoxでSunSpiderを実行した結果

Edgeだと

開発環境

• Visual Studioはx86なら動くのでインストール可能。x86_arm64なクロスコンパイラがあるので、これでクロス環境でなくてもネイティブアプリを作ることはできる (amd64_arm64なコンパイラだと起動できないため)
• デバッガ (cdb、windbg) はネイティブ版 (arm64) がWindows SDKに含まれているので、それを使えばネイティブアプリをデバッグ可能
• 生成コードを見る限りUNIXなAArch64 ABIと同様。ARMNT (Thumb2) の時と同様これはarmの定義したABIをそのまま使ってる

ファーストインプレッションはこのような感じです。

How to use Microsoft IME's private mode on not IE/Edige

Windows 10 Anniversary updateに含まれるMicrosoft IMEの新機能でInternet ExplorerやEdgeを利用している場合にプライベートブラウジングモードに連動してIMEもプライベートモードにできるという機能が入ってる。ブラウザベンダーで働くブラウザ開発者してはこの機能を是非つけたいと思ったのだけど、どうもAPIが公開されていないということなので調べた。Nyaruruさんも軽く調査してたけど、その続き編みたいなものです。

どうもこんな感じのコールスタックでプライベートモードを見に来る。

ChildEBP RetAddr
0591d22c 6fab49e1 imjptip!PrivateDetector::PrivateDetector
0591d270 6fad9a58 imjptip!CTipFnPrivateModeManager::CTipFnPrivateModeManager+0x7e
0591d2a8 6fac9a16 imjptip!CTipFnPrivateModeManager::CreateInstance+0x35
0591d34c 6f63d614 imjptip!CTipProfileJPN::InitializeContextEditor+0x2556
0591d38c 6f62bb95 imetip!CTipContextEditor::Initialize+0x74
0591d3c4 6f62b55a imetip!CTipContextEditorMgr::InitContextEditor+0x53
0591d420 6f661404 imetip!CTipContextEditorMgr::OnProfileMgrEvent+0x44
0591d45c 6f6230ac imetip!CTipContextEditorMgr::_OnProfileMgrEvent+0x44
0591d478 6f623b54 imetip!Tiputil::CTipProfileMgrEventSink::OnProfileActivated+0x5c
0591d4c4 6f623c3d imetip!CTipProfileMgr::CallOnProfileActivated+0xc4
0591d4e0 6f6239b4 imetip!CTipProfileMgr::ActivateProfileProc+0x80
0591d554 6f6591e6 imetip!CTipProfileMgr::OnActivated+0x124
0591d568 6f61c795 imetip!Tiputil::TextInputProcessorActivateSink::OnActivated+0x61
0591d5a8 6f61ca02 imetip!CTextInputProcessor::CallOnActivated+0x45
0591d5d4 6f61d43f imetip!CTextInputProcessor::ActivateProc+0x6c
0591d608 769048f9 imetip!CTextInputProcessor::ActivateEx+0x4f
0591d63c 7691db53 MSCTF!CTip::Activate+0x63

このPrivateDetectorというクラスでInternet ExplorerとEdge用に専用コードが存在してる。FirefoxはUWPではないので、Internet Explorerを見ると、Internet Explorerの時だけ (判定にIERTUTIL.DLLのIEConfiguration_GetDWORDを利用)、IERTUTIL.DLLに存在する特別な関数 (LCIEIsCurrentProcessInPrivate) を呼び出して、それの値でプライベートブラウジングモードかどうかを判別してるぽい。

まぁIERTUTIL.DLLの関数ってエクスポート名前を公開してないのでMAKEINTRESOURCEか何かで無理やり関数エントリを取ってきて、これをフックしてしまえば他のブラウザでもプライベートモードが使えるんじゃないかと。

ただ、IMEベンダが同じことしたくてもできないってのが本当にダメなAPI設計だなと思う。

追記 (8/6)

なお実際にテスト実装してみたところ、LCIEIsCurrentProcessInPrivateのフックだけでプライベートモードとかの切り替えできた。

Microsoft Location Serviceの動作

とある諸事象でMicrosoftのLocation APIの動作について調べてた。ちなみにBingのAPIとは別らしい。

Windows 8以降のLocation APIは、Windows Phoneと同じようにWiFi情報を元にして位置情報を決定することができる。Orionという呼ばれる位置情報サーバーにSOAPでリクエストを投げるとデータが返ってくる仕組みだ。2011年から稼働しているのにSOAPでAPIにアクセスする。

これだったらGoogleとかの位置情報サービスと変わらないのだけど、Windows 8以降のLocation Providerはサーバーから取ってきたデータを内部データベース (\ProgramData\Microsoft\Windows\LocationProvider\LocationCache.dat) にキャッシュしておく。そのためLocation APIを呼び出しても常にサーバーへ問合せはされない仕組みになってる。これはただのキャッシュというよりも、ある程度な範囲 (300m? くらい) の位置情報データベースを内部でも構築するような仕組みになっているため、インターネットの接続が切れた後であっても自分の位置が変更 (=WiFiのブロードキャストリストやシグナル情報が変更) になれば、Location APIが位置情報を推測して返すことが可能になってる (どうもドライバ内で計算してるっぽい)。

実際のデータに関しては、inference.location.live.netというSOAPサーバーにHTTPSで接続してデータを取得してる。そのためこのサイトをブロックしてしまえばおそらく位置情報の取得ができなくなる。

この位置情報サービスのデータについては、Windows Phoneのサイト (http://www.windowsphone.com/ja-JP/how-to/wp7/web/location-and-my-privacy) を見るとデータポリシーとかは書いてある。いろんな情報をまとめると、Windows 8でも同じサーバーにアクセスしてるのはわかってる (でもAPIは微妙に違うみたい)。

このページを読む限りそもそもデータ収集にWindows Phoneも使われていたそうなので、Microsoftの位置情報サービスは日本での精度に期待できないということはよくわかったし、_nomapとSSIDにつけても無視するということもよくわかった (https://www.windowsphone.com/en-us/support/location-block-listで申請しろってことらしい)。

そのデータ収集だけど、どうもBing Map版ストリートビュー車も使ってるということらしいけど、日本ではそのサービスがされていないので日本での情報量が少ないこともよくわかるオチでした。

Rendering Color Emoji using Glyph with DirectWrite 1.2

Windows 8.1でカラー絵文字を表示するサンプルでTranslateColorGlyphRunを使ってグリフベースで書く方法が存在してないのでサンプルを書いた。



適当に書いたものなので動かないとは思うけど、使い方は参考になるはず。というか、Microsoft、TranslateColorGlyphRunを使ったサンプルくらい公開してよ。

emoji hell

絵文字は昔Emoticonsとか言ってたのにいつの間に世界標準語でemojiと呼ばれるようになったんだが、このフォント仕様のカオスさが面白い。たまに調べることがあるので自分用にまとめてみた。

現在主流のプラットフォームだと大体はカラー絵文字をサポートしてるのだが、すべてでサポートする仕様が異なる。どのプラットフォームもOpenTypeに新しいテーブルを追加することでサポートするようになってる。

Windows 8.1

COLRテーブルとCPALテーブルを利用。
http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/

ただしカラー絵文字を描画するには、DirectWriteのID2D1RenderTarget::DrawTextまたは、ID2D1RenderTarget::DrawTextLayout必須 (えっDrawGlyphRunではサポートしないの？) なため、IE11でもサポートされず。

なお、Glyphベースで描画するには、DWRITE_COLOR_GLYPH_RUN使えばいいらしいが。

Apple iOS / OSX 10.7

sbixテーブルを利用。そのままPNGが入ってる
http://typographica.org/typeface-reviews/apple-color-emoji/

10.7から追加されたCTFontDrawGlyphsを使うことで描画可能。CGContextShowGlyphsWithAdvancesの使用からCTFontDrawGlyphsに変えることで対応可能。

Google Android

CBDTテーブルとCBLCテーブルを利用。PNGとか非圧縮のビットマップが格納可能
https://color-emoji.googlecode.com/git/specification/v1.html

ただし、FreeType 2.5でサポートが入ってるため (from Google)、FreeTypeでレンダリングするようなアプリだとOS問わずサポート可能 (ビルドオプションの変更は必要)

ATOK 2013をWindows 8.1で使うと仮想マシン接続が終了時にハングアップする

最近Hyper-Vクライアントを試しに使っているのだが、終了時にハングアップするんでちょっとだけ困ってる。

でなんでハングしてんだろと思って軽く見てみた。

メインスレッドの状況。mstscatかな？原因は。

0:016> ~0k
Child-SP          RetAddr           Call Site
000000d5`aa80b778 00007ffb`93431148 ntdll!NtWaitForSingleObject+0xa
000000d5`aa80b780 00007ffb`69814e92 KERNELBASE!WaitForSingleObjectEx+0x94
000000d5`aa80b820 00007ffb`69819ce4 mstscax!DllUnregisterServer+0x166726
000000d5`aa80b850 00007ffb`69aa5205 mstscax!DllUnregisterServer+0x16b578
000000d5`aa80b890 00007ffb`69aa2bbf mstscax!DllUnregisterServer+0x3f6a99
000000d5`aa80b930 00007ffb`699bfaed mstscax!DllUnregisterServer+0x3f4453
000000d5`aa80b980 00007ffb`699b7d68 mstscax!DllUnregisterServer+0x311381
000000d5`aa80b9e0 00007ffb`698b756c mstscax!DllUnregisterServer+0x3095fc
000000d5`aa80ba20 00007ffb`698a8715 mstscax!DllUnregisterServer+0x208e00
000000d5`aa80ba80 00007ffb`698aac69 mstscax!DllUnregisterServer+0x1f9fa9
000000d5`aa80bb00 00007ffb`93fe2524 mstscax!DllUnregisterServer+0x1fc4fd
000000d5`aa80bb90 00007ffb`93fe6773 USER32!UserCallWinProcCheckWow+0x140
000000d5`aa80bc50 00007ffb`776c52cb USER32!CallWindowProcW+0x93
000000d5`aa80bcb0 00007ffb`776bfeb6 System_Windows_Forms_ni+0x9052cb
000000d5`aa80bde0 00007ffb`77031e63 System_Windows_Forms_ni+0x8ffeb6
000000d5`aa80beb0 00007ffb`77651447 System_Windows_Forms_ni+0x271e63
000000d5`aa80bf80 00007ffb`7cba3ebe System_Windows_Forms_ni+0x891447
000000d5`aa80c010 00007ffb`93fe2524 clr!UMThunkStub+0x6e
000000d5`aa80c0a0 00007ffb`93fe3812 USER32!UserCallWinProcCheckWow+0x140
000000d5`aa80c160 00007ffb`93fe38cd USER32!DispatchClientMessage+0xa2
000000d5`aa80c1c0 00007ffb`9609838f USER32!_fnDWORD+0x2d
000000d5`aa80c220 00007ffb`93fe129a ntdll!KiUserCallbackDispatcherContinue
000000d5`aa80c2a8 00007ffb`698a6701 USER32!NtUserDestroyWindow+0xa
000000d5`aa80c2b0 00007ffb`77635883 mstscax!DllUnregisterServer+0x1f7f95
000000d5`aa80c2e0 00007ffb`776c328f System_Windows_Forms_ni+0x875883
000000d5`aa80c3e0 00007ffb`776c2c91 System_Windows_Forms_ni+0x90328f
000000d5`aa80c440 00007ffb`776c024e System_Windows_Forms_ni+0x902c91
000000d5`aa80c4a0 00007ffb`78e11cf8 System_Windows_Forms_ni+0x90024e
000000d5`aa80c4e0 00007ffb`802950fa System_ni+0x291cf8
000000d5`aa80c510 00007ffb`80296d32 vmconnect_ni!COM+_Entry_Point <PERF> (vmconnect_ni+0xc50fa)
000000d5`aa80c5a0 00007ffb`7cb84113 vmconnect_ni!COM+_Entry_Point <PERF> (vmconnect_ni+0xc6d32)
000000d5`aa80c670 00007ffb`7cb83fde clr!CallDescrWorkerInternal+0x83
000000d5`aa80c6b0 00007ffb`7caeee66 clr!CallDescrWorkerWithHandler+0x4a
000000d5`aa80c6f0 00007ffb`7caeeba6 clr!CallDescrWorkerReflectionWrapper+0x1a
000000d5`aa80c740 00007ffb`79c76bac clr!RuntimeMethodHandle::InvokeMethod+0x46a
000000d5`aa80cd40 00007ffb`79c7f3b3 mscorlib_ni+0x486bac
000000d5`aa80cdb0 00007ffb`7cb84113 mscorlib_ni+0x48f3b3
000000d5`aa80ce30 00007ffb`7cb83fde clr!CallDescrWorkerInternal+0x83
000000d5`aa80ce80 00007ffb`7cb889a3 clr!CallDescrWorkerWithHandler+0x4a
000000d5`aa80cec0 00007ffb`7cc53a2e clr!MethodDescCallSite::CallTargetWorker+0x251
000000d5`aa80d080 00007ffb`7cc53596 clr!DispatchInfo::InvokeMemberWorker+0xebe
000000d5`aa80dc30 00007ffb`7cc5332f clr!DispatchInfo::InvokeMemberDebuggerWrapper+0x1c6
000000d5`aa80dd90 00007ffb`7cc52f02 clr!DispatchInfo::InvokeMember+0x461
000000d5`aa80e080 00007ffb`7cc52d6c clr!InternalDispatchImpl_Invoke+0x1ed
000000d5`aa80e1a0 00007ffb`7cc52cae clr!InternalDispatchImpl_Invoke_CallBack+0xb2
000000d5`aa80e200 00007ffb`698af574 clr!InternalDispatchImpl_Invoke_Wrapper+0xf8
000000d5`aa80e2a0 00007ffb`698af771 mstscax!DllUnregisterServer+0x200e08
000000d5`aa80e350 00007ffb`698b27ff mstscax!DllUnregisterServer+0x201005
000000d5`aa80e3a0 00007ffb`699c2f26 mstscax!DllUnregisterServer+0x204093
000000d5`aa80e420 00007ffb`69aa37b5 mstscax!DllUnregisterServer+0x3147ba
000000d5`aa80e450 00007ffb`69aa3fbf mstscax!DllUnregisterServer+0x3f5049
000000d5`aa80e480 00007ffb`69aa3d70 mstscax!DllUnregisterServer+0x3f5853
000000d5`aa80e4e0 00007ffb`69aa388a mstscax!DllUnregisterServer+0x3f5604
000000d5`aa80e540 00007ffb`69aa38dd mstscax!DllUnregisterServer+0x3f511e
000000d5`aa80e580 00007ffb`696e3f05 mstscax!DllUnregisterServer+0x3f5171
000000d5`aa80e5b0 00007ffb`93fe2524 mstscax!DllUnregisterServer+0x35799
000000d5`aa80e5e0 00007ffb`93fe2387 USER32!UserCallWinProcCheckWow+0x140
000000d5`aa80e6a0 00007ffb`770c7170 USER32!DispatchMessageWorker+0x1a7
000000d5`aa80e720 00007ffb`7704b1a1 System_Windows_Forms_ni+0x307170
000000d5`aa80e7f0 00007ffb`7704a97f System_Windows_Forms_ni+0x28b1a1
000000d5`aa80e9f0 00007ffb`7704a33f System_Windows_Forms_ni+0x28a97f
000000d5`aa80eb40 00007ffb`802ab599 System_Windows_Forms_ni+0x28a33f
000000d5`aa80ebd0 00007ffb`7cb84113 vmconnect_ni!COM+_Entry_Point <PERF> (vmconnect_ni+0xdb599)
000000d5`aa80ed30 00007ffb`7cb83fde clr!CallDescrWorkerInternal+0x83
000000d5`aa80ed70 00007ffb`7cb889a3 clr!CallDescrWorkerWithHandler+0x4a
000000d5`aa80edb0 00007ffb`7cc591aa clr!MethodDescCallSite::CallTargetWorker+0x251
000000d5`aa80ef60 00007ffb`7cc5999a clr!RunMain+0x1e7
000000d5`aa80f140 00007ffb`7cc59893 clr!Assembly::ExecuteMainMethod+0xb6
000000d5`aa80f430 00007ffb`7cc59372 clr!SystemDomain::ExecuteMainMethod+0x506
000000d5`aa80fa40 00007ffb`7cc592c6 clr!ExecuteEXE+0x3f
000000d5`aa80fab0 00007ffb`7cc59d84 clr!_CorExeMainInternal+0xae
000000d5`aa80fb40 00007ffb`7e487ced clr!CorExeMain+0x14
000000d5`aa80fb80 00007ffb`84ebea5b mscoreei!CorExeMain+0xe0
000000d5`aa80fbd0 00007ffb`95e815cd MSCOREE!CorExeMain_Exported+0xcb
000000d5`aa80fc00 00007ffb`960743d1 KERNEL32!BaseThreadInitThunk+0xd
000000d5`aa80fc30 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

ということでmstscax.dllが何者かというと

0:016> lmvm mstscax
start             end                 module name
00007ffb`695f0000 00007ffb`69c52000   mstscax    (export symbols)       C:\WINDO
WS\system32\mstscax.dll
    Loaded symbol image file: C:\WINDOWS\system32\mstscax.dll
    Image path: C:\WINDOWS\system32\mstscax.dll
    Image name: mstscax.dll
    Timestamp:        Sat Oct 05 16:36:30 2013 (524FC17E)
    CheckSum:         0066305A
    ImageSize:        00662000
    File version:     6.3.9600.16421
    Product version:  6.3.9600.16421
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      MicrosoftR WindowsR Operating System
    InternalName:     mstscax.dll
    OriginalFilename: mstscax.dll
    ProductVersion:   6.3.9600.16421
    FileVersion:      6.3.9600.16421 (winblue_gdr.131004-2100)
    FileDescription:  Remote Desktop Services ActiveX Client
    LegalCopyright:   c Microsoft Corporation. All rights reserved.

Hyper-Vクライアントで使ってるモジュールすね (RDPのやつ)

ハングアップはこのメインスレッド上のウィンドウプロシージャ上でこのActiveXコントロールへの呼び出しが帰ってこないからってことが原因。ただ、たぶんこれが待ってるイベントオブジェクトがなんだって話なんだけど、

0:016> ~9k
Child-SP          RetAddr           Call Site
000000d5`ce28cda8 00007ffb`934312ee ntdll!NtWaitForMultipleObjects+0xa
000000d5`ce28cdb0 00007ffb`93fe2a7f KERNELBASE!WaitForMultipleObjectsEx+0xe1
000000d5`ce28d090 00007ffb`93c81506 USER32!MsgWaitForMultipleObjectsEx+0x13f
000000d5`ce28d140 00007ffb`93caefae combase!CCliModalLoop::BlockFn+0x12a
000000d5`ce28d1a0 00007ffb`93de5cc0 combase!ClassicSTAThreadDispatchCrossApartmentCall+0x1de
000000d5`ce28d210 00007ffb`93c7e930 combase!CRpcChannelBuffer::SendReceive2+0x656
000000d5`ce28d450 00007ffb`93de27a7 combase!CCtxComChnl::SendReceive+0x2e0
000000d5`ce28d630 00007ffb`93c3bf3d combase!NdrExtpProxySendReceive+0x47
000000d5`ce28d660 00007ffb`93de1d2b RPCRT4!NdrpClientCall3+0x374
000000d5`ce28da20 00007ffb`93c71b22 combase!ObjectStublessClient+0x12b
000000d5`ce28dda0 00007ffb`93caf27c combase!ObjectStubless+0x42
000000d5`ce28ddf0 00007ffb`93caf33e combase!CStdMarshal::RemoteAddRef+0xe8
000000d5`ce28de80 00007ffb`93cb6db7 combase!CStdMarshal::ConnectCliIPIDEntry+0xb0d
000000d5`ce28df50 00007ffb`93cb4cf2 combase!CStdMarshal::UnmarshalIPID+0x2f3
000000d5`ce28e050 00007ffb`93cb4f9f combase!CStdMarshal::UnmarshalObjRef+0x142
000000d5`ce28e120 00007ffb`93cb901e combase!UnmarshalObjRef+0x136
000000d5`ce28e1a0 00007ffb`87a4f879 combase!_CoUnmarshalInterface+0xc2
000000d5`ce28e280 00007ffb`87a5290f twinapi_appcore!ValidateStreamAndUnmarshalInterface+0x9d
000000d5`ce28e340 00007ffb`8862cfff twinapi_appcore!CoreQueryWindowService+0x34f
000000d5`ce28e3f0 00007ffb`88632f92 twinapi!CInputPaneEventSource_GetInstance+0x2b
000000d5`ce28e420 00000000`67df484e twinapi!CImmersiveFrameworkInputPane::Unadvise+0xaa
000000d5`ce28e470 00000000`67df48c4 ATOK26TIP!DllInstall+0x13841e
000000d5`ce28e4b0 00000000`67cbee7f ATOK26TIP!DllInstall+0x138494
000000d5`ce28e4e0 00007ffb`95c024cd ATOK26TIP!DllInstall+0x2a4f
000000d5`ce28e520 00007ffb`95c023fb MSCTF!CThreadInputMgr::_DeactivateTip+0xc9
000000d5`ce28e600 00007ffb`95c022b7 MSCTF!CThreadInputMgr::ActivateInputProfile+0x363
000000d5`ce28e6c0 00007ffb`95c02196 MSCTF!CThreadInputMgr::OnCleanupContextsEnded+0xaf
000000d5`ce28e740 00007ffb`95c02159 MSCTF!CCleanupShared::`scalar deleting destructor'+0x26
000000d5`ce28e770 00007ffb`95bff6c5 MSCTF!CCleanupShared::_Release+0x19
000000d5`ce28e7a0 00007ffb`95bfdbc4 MSCTF!CThreadInputMgr::_CleanupContexts+0xd5
000000d5`ce28e7e0 00007ffb`95bfdacf MSCTF!CThreadInputMgr::Suspend+0x74
000000d5`ce28e810 00007ffb`95c00054 MSCTF!CThreadInputMgr::OnActivationChange+0xc6
000000d5`ce28e8a0 00007ffb`95c0123a MSCTF!CThreadInputMgr::Deactivate+0x54
000000d5`ce28e8f0 00007ffb`95c01e81 MSCTF!CicBridge::DeactivateIMMX+0x9b
000000d5`ce28e940 00007ffb`95c01de0 MSCTF!_CtfImeDestroyThreadMgr+0x79
000000d5`ce28e970 00007ffb`95fc43a8 MSCTF!CtfImeDestroyThreadMgr+0x30
000000d5`ce28e9a0 00007ffb`95c01efd IMM32!ActivateOrDeactivateTIM+0x64
000000d5`ce28e9d0 00007ffb`93fe485d MSCTF!TF_Notify+0x207
000000d5`ce28f190 00007ffb`93fe3a85 USER32!CtfHookProcWorker+0x19
000000d5`ce28f1c0 00007ffb`93fe99b2 USER32!CallHookWithSEH+0x25
000000d5`ce28f200 00007ffb`9609838f USER32!_fnHkINDWORD+0x1e
000000d5`ce28f250 00007ffb`93fe129a ntdll!KiUserCallbackDispatcherContinue
000000d5`ce28f2d8 00007ffb`6983593b USER32!NtUserDestroyWindow+0xa
000000d5`ce28f2e0 00007ffb`699bfdbd mstscax!DllUnregisterServer+0x1871cf
000000d5`ce28f320 00007ffb`69aa37b5 mstscax!DllUnregisterServer+0x311651
000000d5`ce28f3a0 00007ffb`69aa3fbf mstscax!DllUnregisterServer+0x3f5049
000000d5`ce28f3d0 00007ffb`69aa3d70 mstscax!DllUnregisterServer+0x3f5853
000000d5`ce28f430 00007ffb`69aa5406 mstscax!DllUnregisterServer+0x3f5604
000000d5`ce28f490 00007ffb`69aa5626 mstscax!DllUnregisterServer+0x3f6c9a
000000d5`ce28f4f0 00007ffb`69aa4c38 mstscax!DllUnregisterServer+0x3f6eba
000000d5`ce28f750 00007ffb`699c5454 mstscax!DllUnregisterServer+0x3f64cc
000000d5`ce28f790 00007ffb`69aa4806 mstscax!DllUnregisterServer+0x316ce8
000000d5`ce28f7f0 00007ffb`698157ed mstscax!DllUnregisterServer+0x3f609a
000000d5`ce28f850 00007ffb`95e815cd mstscax!DllUnregisterServer+0x167081
000000d5`ce28f880 00007ffb`960743d1 KERNEL32!BaseThreadInitThunk+0xd
000000d5`ce28f8b0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

これがおそらく待ってるスレッド。TSF/CiceroのDeactiveTIPから呼ばれたATOKがUnadvise呼ぶんだけど、こいつがTSFが抱えてるCOMオブジェクトを破棄する際にマーシャラー経由 (別スレッドがオーナーかな?。おそらくメインスレッド) で破棄しようとするんだけど、メインスレッドがこのスレッド待ってるから固まってる。

解決方法はATOK使うの止めろってことか、VMWareに戻せってことですね。ATOK側がUnadviseの呼び方変更すれば直る気がするけどさ。

結局のところCOMを使う時によくあるデッドロックの事例だった。

Windows RTがJailbreak可能になったらしい

Windows RTは実行モジュールのシグネチャを見てて、それが署名されたものじゃないと動かなったわけだけど、そこらをどうにかすればJailbreakできるだろうなってのは思ってた。

ということは、当然こういうことやるよね。SpiderMonkeyだけど。

Surfaceを買った

普通の世の中だと、Nexus 7とかiPad Miniとかが話題だけど、まったく地雷度が足りなくて面白くない。地雷度MAXな気がしてSurfaceを買った (1shopmobile経由送料込みで約5万円強)。

以下感想

• 外箱も含めてMicrosoftらしくないデザイン。マニュアルも必要最小限
• 電源アダプタもデザインちゃんとしてる。MacBookのように磁石でくっつくタイプ。某東芝のAndroidタブレットなんてノートPCでありきたりのデザイン性ゼロの電源アダプタだったよね
• 今持ってる東芝のタブレット(AT700)に比べたら重いんだけど、造りが安っぽくないから、別に重くて納得できるデザイン
• メトロで完結できるんだったらタブレットとしてはなかなかいいと思う。でも細かい設定しようとするとデスクトップ開いて、コントロールパネル開かないといけないんだよね。
• ちゃんとデスクトップアプリは存在する。Office 2013もそうだけど、OneNoteは2013じゃなくて、メトロ版でよかったんじゃないの?

結論的に言えば、ソフトがねぇぇって感じ。メトロで完結できるようにソフトウェアの作りこみが足りないって感じにしか思えない。。。残念感ありあり。

やっつけにも程があると思ったこと - Microsoft SDK編

Windows 8 SDKとWindows Phone 8 SDKを調査してるんだけど、Windows Phone 8はカトラー様のNTカーネルを使ってるため、WinCEのころに比べてSDKにある程度は互換性がある。CEの頃と一緒でリンクするライブラリが違うってのはあるんだけどね。調査してて、一番やっつけすぎて倒れそうなことを発見した。

Windows 8 SDK

/*
 *  Windows APIs can be placed in a partition represented by one of the below bits.   The 
 *  WINAPI_FAMILY value determines which partitions are available to the client code.
 */

#define WINAPI_PARTITION_DESKTOP   0x00000001
#define WINAPI_PARTITION_APP       0x00000002    

/*
 * A family may be defined as the union of multiple families. WINAPI_FAMILY should be set
 * to one of these values.
 */
#define WINAPI_FAMILY_APP          WINAPI_PARTITION_APP
#define WINAPI_FAMILY_DESKTOP_APP  (WINAPI_PARTITION_DESKTOP | WINAPI_PARTITION_APP)

一方、こっちはWindows Phone 8 SDK

/*
 * WINAPI_FAMILY should be set to be one of these.
 */
#define WINAPI_FAMILY_APP         1
#define WINAPI_FAMILY_DESKTOP_APP 2
#define WINAPI_FAMILY_PHONE_APP   3

やっつけにも程があるでしょ、これ。なんでヘッダの内容別にしちゃうかなぁ。SDKのヘッダくらい同期してくださいってマジ思う。

Metro APIをコンソールアプリに使おう

何も考えることなく簡単だった。

#include <windows.h>
#include <stdio.h>

int main(Platform::Array<Platform::String^>^ args)
{
  auto calendar = ref new Windows::Globalization::Calendar();
  caledar->SetToNow();
  printf("%lld\n", calendar->GetDateTime().UniversalTime);
  return 0;
}

Metro世代でも、タイマの精度は従来のWindowsと変わらなかった。カーネルはHPET使ってるから低コストで高精度タイマを使えるのにユーザーモードは相変わらずのダメっぷり。タイマが15msじゃないと互換性の低下が発生するとかがあるのかな？

本当にWindows RTにブラウザをインストールできないのか？

これはちょい細かく説明すると、

• Desktop onlyとMSDNに書かれているものは、WinRTアプリで使っちゃダメよと言ってるが、メトロアプリでも使おうと思えば使える。実際メトロなFirefoxの試作版ではDesktop onlyと書かれたAPIも使ってるけど、xamlのラッパー経由で画面描画してるから、メトロとしてアプリが動く
  
• Windows RTは、WinRT APIにアクセス可能。Windowsなんだから、内部的にはWin32 APIもアクセス可能(すべてではないとは思うけど)
  
• IEのメトロ版は、Win32 APIを普通に使ってる。Desktop onlyってAPIもね
  
• OfficeのWindows RT(arm)版はただのデスクトップアプリ。ということは、普通にWin32 APIもWindows RT上でもアクセス可能
  
• Windows RTは、アプリケーションのインストールは "Windows Store" 経由。ということは、Windows Storeに掲載可能なスタイルのアプリケーションでなければいけない
  
• Windows Storeは、メトロスタイルのアプリのみ掲載可能。審査付き。
  
• VirtualAlloc系APIがメトロスタイルからは利用不可 (動的にロードすればこのAPI使うことができるけど、これを使うと審査に落ちる) なので、JITを動かすことはまず不可能。
  

なので、すべてメトロ(WinRT)で書き直せばブラウザ自体を掲載することはできるかもしれないけど、実質それだと無理じゃね？って話。Opera Miniのようなものだとおそらく簡単に持ってこれると思うけどね。（Operaさんはもうやってるんじゃないかな？たぶん。知らないけど）

そもそもだな、Windows RTはメトロアプリしか受け付けないといいながら、MFCのディレクトリにちゃっかりARMのライブラリが入ってて、しかもSDKに含まれいないライブラリ(wsock32.libとか)をリンクしている時点で、Microsoftシネな感じだけどね。

Visual Studio 11のARMターゲットを遊んでみた

Windows 8でarmがサポートされるんだけど、早速Visual Studio 11のC++で試してみたところ、

• armターゲットのとき、当然_M_ARMが定義される
• arm_neon.hが入ってるので当然NEONサポート
• デフォルトでthumb2のコードを吐く。だから、ARMV6T2ってかARMV7以降のコードを吐く。Windows CE 7のコンパイラと違って、CPUターゲットのオプションが/?で出てこないから、ARMv6以前のCPUサポートはない可能性が
• コンパイラがインラインアセンブラをサポートしてないのに、アセンブラが入ってない。たぶんarmasm.exeの入れ忘れ
• どうもABIはEABIっぽい
• DDKはそもそもarmのターゲット入ってなかった
• いくつかのインポートライブラリが入ってない。wsock32.libとか。ということで全く使えん

そんなところ。gccとの生成コードの質を比べてみたいなぁ。時間があったらやろう

25MB程度のDLLをPGOで作ろうとするとLINK.EXEがクラッシュしてしまう

25MB程度ってのは、FirefoxのコアモジュールであるXUL.DLL。Mozillaでは現在Win32 (x86)はVC8を使ってて、Win64 (x64)はVC9を使ってるんだけど (なんでWin64だけVC9使ってるかというとコンパイラのバグのせいで生成したコードが正しくないから)、現在ビルドチームでVC10に移行することを計画してる。

FirefoxというかGeckoでは、メモリ関連のモジュールは、VCのCRT内部のメモリ関数じゃなくて、jemallocというFreeBSD由来のモジュールを差し替えてる。VC8とかVC9だと、CRT (MSVCRT*.DLL) のソースコードがコンパイラに付属しているので、それをコンパイルしてメモリ関連だけ置き換えて使ってるんだけど、VC10からはビルド可能なソースコードが付かなくなった。その関係で未だにVC8とかVC9を使ってたんだけど、Kyleがハッキーな方法を見つけたんで、VC10を使ってもjemallocが動くようになった。そのため、今VC10で動く (=自動テストがちゃんと通る) ように一部のメンバでいろいろと動いてる。

Win64版はVC9を使ってビルドしてて未だオフィシャルではないけど (Nightlyはある)、自動テストが毎回走ってて、JavaScript周りの一部のIssueを残して問題なくはなってる (多分GC周りっぽいんだけど、手元で再現できなくてホント困ってる)。当然Win64版もVC10に移行する計画があって、ビルドチームのArmenはツール周りで、その他はほぼ僕の仕事でもあるんだけど、最近というか今週テストしてみて、PGOを有効にした状態でビルドができないという問題にぶち当たった。

でなんでかとそのデータを見てみると、Win64版のリンカ (LINK.EXE) がクラッシュして内部エラーで終了してる。でさ、Win32版のリンカ (Win32版のリンカでもWin64の実行イメージは生成できる) で試すと問題なくパスする訳だ。

ということで、mozilla-buildを直せばビルドは可能にはなるんでとりあえず回避方法は見つかったけど、これって直してもらえないかなぁってホント思う。関数のエントリ探しにいって、Access Violation起きてるみたいだけどさ。

Desktop Heap

スラド見てたら、デスクトップヒープの話があったんだけど、これといえば、こんなこといつも思い出すなぁと

-oオプション(どのプロセスがどのTCP/IPのセッションを利用しているかを表示するオプション)が使えるnetstatのWindows 2000版(XP版は-o使えるけど、2000版は使えないんだよ。その-oオプションを使うためにカーネルドライバをバイナリに隠して、それを動的ロードして、必要なメモリを読み込むという荒技をしてるツールだったはず)を作ってたIさんが、同じテクニックで必要な構造体のデータを読み込んでそれを計算すれば、大体のデスクトップヒープの使用量がわかるんじゃない？ってことに気付いて、同じようなツールのカーネルデバッガのエクステンションを作ってたNさん(or Mさん?)に相談。2日か3日くらいでコンソール版デスクトップヒープモニタを作りあげてた話を思い出す。結構裏では使われていた記憶が。

問題はWIN32K(だっけ?)のプライベートシンボルが必要なんでそれを外に出せなかった。今はそこら辺の解析の結果が、Desktop Heap Monitorにいかされてるんだけどね。今のパブリックシンボルにはそこらの情報をいれるようにしてもらっているから、プライベートシンボルが必要ということはないけど。

また、デスクトップヒープが枯渇した時くらい何かメッセージださんかいということで、バグファイルしてYさんに直してもらったんだけど、イベントログにちょっとしたメッセージ（気付くはずねーよ）出すしょぼいコード(確かWindows Server 2003以降だけだったと思う)があるだとか。

ちなみにいうと、64-bit OS上で32-bitプロセスを実行した場合は、それはWOWによって、64-bitコールに変更されるため、64-bit OSを使っている場合にはこの心配は無用。

今思うと結構昔の話だなぁ。っていうか年取った。

Windows 7を入れてみた

開発用に使っているノートPC (Dell XPS M1210) に、最近公開されているWindows 7のパブリックベータを入れてみた。

壊してもいい環境だったんで、アップグレードインストールした雑感。

• アップグレードに4.5時間ほどかかった
• 英語キーボードの環境だったのに、日本語キーボードに変えられた
• Intel GM945のドライバがWindows Updateから入れられない

思ったよりは、いい感じかも。

Windowsユーザーは64ビット版に移行すべき

会社の環境でも自宅の開発環境も基本はUbuntu or Fedoraの64ビット版を使っているのだけど、持ち運び用のPCはDellのXPS M1210にWindows Vista 64ビット版をインストールしている。ドライバが対応しているのに64ビット版を使わない人はたぶん人生でちょっとロスしていると個人的には思っている。(テレビでも見ない限り、普通のデバイスは64ビットドライバが存在するはず)

64ビットで一番の効果というのはメモリ容量とか言われているけれども、Windowsの場合は別にある。デスクトップヒープだ。32ビット版のWindowsではデスクトップヒープの量にはきびしい制限があり、60個くらいのNOTEPAD.EXEを起動すればデスクトップヒープが枯渇する

デスクトップヒープが枯渇すると何がおきるかというと、ウィンドウの文字が表示されない、ウィンドウ自体の作成に失敗するなど、画面の表示まわりに問題が発生する。Windows 95的に言えば、GDIリソースとUSERリソースの枯渇と同じことが起きる。

デバッグとかしている時には、秀丸エディタのウィンドウを30個開いている状態とかはよくあることだったんだけど、そんな状態だとデスクトップヒープが枯渇して、文字が表示されなくなってくる。それで必要のないウィンドウを探してクローズってことをしょっちゅうしてた。

そんなやっかいなことが64ビット版のWindowsで解決するんだから、速攻移行すべきだろう、特に開発やっているような人は。Vistaが嫌なら、XPの64ビット版(Server 2003と同一ソースコードのやつ)をインストールすればいいだけ。

ちなみに、Server版使っている人の場合は、Terminal Serviceを使っている場合は必ず移行すべき。セッションプールの制限値が明らかに違うので。

NSSの最適化 (x86_64)

NSSの最適化でもしよとバグを開いた。x64環境で使っているので、x86より遅いと嫌だしね。

Bug 431958 – Improve DES and SHA512 for x86_64 platform