HTML5 Forms の type 指定がデスクトップ IMEに影響するという話 - NyaRuRuが地球にいたころ
最近やっていた仕事について，一通りリリースが終わって誰でも試せる段階になったので書いてみる．Web アプリ開発者の人や，IME 作成者の人には影響があるかも知れない．ただし Windows デスクトップを相手にしていなければ，ここで読むのをやめてもなんら問題はない． 最近 Chromium と Firefox にパッチを書いて，HTML5 Forms の type 指定が InputScope として TSF ベースの IME (いわゆる Text Input Processors; TIP) やソフトウェアキーボードに通知されるようにした．これは，基本的に Windows 8 上での Internet Explorer 10 の動作に合わせたものである．具体的には，以下の環境で，各種ブラウザが InputScope をサポートするようになった． Microsoft Internet Ex
DirectX Graphics フルスクリーンモードと窓使いの憂鬱: 解決編 - NyaRuRuが地球にいたころ
サークルで作成しているゲームについて「フルスクリーン環境で実行した後にゲームを終了すると一般保護違反が発生する」という症状が報告されて，色々調べてみたところ原因は『窓使いの憂鬱』にありました．どおりでこちらの環境で再現しなかったわけです．実際『窓使いの憂鬱 Ver.3.30』を常駐させることで問題を再現できることを確認しました． 多くの場合こういう現象は「相性問題」という便利な言葉で真実に蓋をされてしまいがちですが…たまには「解」でもご覧あれ． すんません，これ「相性問題」でした．今更ながらにコールスタックを眺め直していたら，こちらのゲーム側に Win32 ウィンドウのリークがありそうな気がしてきて実際ソースを読み直したらまさにその通りだったという…… 『窓使いの憂鬱』を一方的に原因扱いしてしまって申し訳ありません．また，以前質問を受けたときに気付けていれば id:applet_at_h
Windows における例外ハンドリングとか 64-bit プロセス固有のあれそれとか - NyaRuRuが地球にいたころ
Windows における例外ハンドリング - @a4lg の準技術的日記 すごくまとまってました．個人的に印象深かったのはこの辺． 実は、x64 版 Windows 用のバイナリにおいては、fs:[0] に例外ハンドリング構造体へのポインタを設定するなどという行為は一切行いません。というより、コード上には、例外をハンドルする如何なる追加コードも存在しません。これは、例外ハンドリングを行わない場合のプログラムには一切オーバーヘッドが存在しないということを意味します。 Windows の細かい部分まで見てみると，64-bit プロセスのみ影響を受ける仕様というのがいくつかあって，今回のケースもそのひとつですかね．64-bit アプリケーションの場合，「従来から存在するバイナリ」というのが存在しないので，互換性に悩まされることなく 32-bit 時代の仕様をリセットできる，と． Windows
Windows 7 時代のスクリーンショットの撮り方 - NyaRuRuが地球にいたころ
といっても私の場合は Vista 時代と変化無し．Window Clippings を愛用しています．$18 のシェアウェアです． Windows Vista や Windows 7 標準のスクリーンショットで困るのが，ウィンドウの透過部分にある背景イメージがそのままキャプチャされてしまうことです．この点，Window Clippings で撮るスクリーンショットはウィンドウの背景に影響されず，しかも透過色のままキャプチャすることができます．この透過色は，上記のように背景画像と重ねたり，PowerPoint に張り込んだりするときに活躍します．上記イメージ背景の格子模様は CSS で表示位置を固定しているものです．ウィンドウをスクロールさせると，Aero の透過部分がよく分かると思います． Windows 7 で初めて Aero 環境に触れるという方も今後増えてくるでしょうから，改めて紹介
Windows 7 のグラフィックスの変更点を整理する - NyaRuRuが地球にいたころ
(2009年2月9日追記) 『GDI アクセラレーションについて整理する - NyaRuRu の日記』にて，公開された WDK のドキュメントを元に追加の考察を行っています． 基本的にはプレビュー版のWindows 7においても、日本語を利用することは可能だった。しかし、1つだけ大きな問題がある。それはAero Glassと日本語表示が必ずしも共存しないことだ。 図5はおなじみの日本語エディタ、秀丸をWindows 7のプレビュー版で起動したところだ。見れば分かるように、メニューの表示がおかしい。「その他」のメニューの途中から日本語表示が普通なのは、まだカーソルがこのエリアまで至っていないことを意味している。カーソルを下に持って行くと、それに連れてメニュー上部のように日本語表示がおかしくなっていく。なお、この画面はBlue Badgeを適用した後のものだが、この現象はBlue Badgeの
Chromium (Chrome) のソースを読む - NyaRuRuが地球にいたころ
Chromium (Chrome) のソースを読んでみた． まず Chromium の位置づけがややこしい． Google 発のオープンソースなブラウザである Chromium があって，Google Chrome はこれをカスタムビルドしたもの，という位置付けらしい．まあ大多数の人間にとっては，Google Chrome のソースを読めるという認識で問題ないんだろう． ソースをダウンロードしてビルドまで，の手順はここにまとまっている． Getting Started - Chromium Developer Documentation 推奨ビルド環境は Visual C++ 2005 SP1．ソリューションファイル同梱なので，Windows っ子も安心． 巨大な tar ファイルの展開が終わると，Visual C++のプロジェクトファイルが大量に現れる．各プロジェクトの概要はこちら． G
Secure coding は Microsoft からイノベーションを奪っているか？ - NyaRuRuが地球にいたころ
Re: WPFでHLSLが使えることの持つ意味 id:tetsutalow せんせーのところより． CPUの性能が伸びなくなってしまった今、GPUは当面の伸びしろとして期待されているわけですから、この動き自体は自然でしょう。ですが、一般的に言って、ネット越しに落ちてくるコードが高い計算能力を持つことは、それだけで凶器になり得ます。SilverlightのSandboxの細かい仕様をまだちゃんと調べていないので詳しいことは言えませんが、私の頭の中にはいくつかの、この技術を凶器として使うシナリオがあるので、その実現可能性をちゃんと調べないといけないなぁと思っています。そのことを忘れないうちにここに書いておきます・・・・他の専門家の方も、もしよろしければご検討願えませんか。 あー Silverlight だとまだ当面 Shader は使えないんじゃないでしょうかね．というか Silverligh
ユーザの感情に作用する遅延書き込みの仕組みを暴け - 記事紹介: Inside Vista SP1 File Copy Improvements (3) - NyaRuRuが地球にいたころ
過去の関連記事 Vista のファイルコピーが遅い件について 前回記事 記事紹介: Inside Vista SP1 File Copy Improvements (1) 記事紹介: Inside Vista SP1 File Copy Improvements (2) それではいよいよ最終回にしてメインディッシュ．記事紹介から離れてこの件を深く掘り下げていきます． Cached I/O vs Non-Cached I/O revisit Cached I/O をオートマ車に喩えるなら，Non-Cached I/O はまさにマニュアル車です． 両者の大きな違いは，どれぐらいのサイズのデータを，どれぐらいの期間メモリ上に保持するかを自動で決めるか手動で決めるかというところです．もちろん後者の方が「理想的な状況」でのパフォーマンスは上になります．似たような対立軸はあちこちにありますね． Cac
あなたが漢字変換候補を覗き込むとき，Google もまた選択された候補を覗いている - NyaRuRuが地球にいたころ
古川さんの書かれていたコメントを読んでいて，もう一点思い出したので書いてみます． 楠さんの指摘は当たっているけれど、ハズレでもあるのは..私はIEにおいてもユーザー辞書を参照できるようにいじっているはずで...銀行の口座番号や航空会社のマイレージ番号をユーザー辞書登録していたのが、IE下では使えないので、FirFoxを使ってアクセスしていた...それも、IEで辞書登録をすると[Windowsが認めた正規アプリではないので、ユーザー登録ができません」というお馬鹿のエラーが出るのに辟易して、パッチを当ててユーザー辞書が使えるようにしているのでありました。というわけで、IE環境とWindows のアプリで変換効率の結果が異なることは、ユーザー辞書の禁止と菅家ないと思われます。 確かに，ユーザ辞書を使えなくするという保護形態は，セキュリティ対策として受け入れるべきかよく分からないところがあります*
MEM_DECOMMIT, MADV_FREE, mono_mprotect - NyaRuRuが地球にいたころ
さて，だいぶ地ならしができたので，いよいよ本題でも． アプリケーションサイドでヒープマネジメントを行う場合，回収された使用済み (アクセス済み) メモリ領域がページアウトされるのを防ぎたい，という話があります． たとえば、一時的に、300MBぐらいメモリを使って、そのあとGCが動いて、使ってるメモリが15MBぐらいになったとする。 このとき、使わない285MBは、必要の無い領域になる、が、しかし、この領域には一旦書き込んでしまってるので、ページが割り当てられているわけだ。そうなると、他のプロセスがメモリを必要としたときに、この領域がスワップアウトしてしまう。 つまり、無駄なスワップが発生してしまうわけだ。PC使ってる時のストレスの80%ぐらいはスワップが原因（多分）なので、無駄なスワップが発生するのは心苦しい。 これは CLR の GC ヒープに限らず，Visual C++ に付属する s
TSF を使う (1) - Windows Input Method の歴史 - NyaRuRuが地球にいたころ
前回もお伝えしたように，そもそも TSF の話を急いでする必要はなくなりました． Windows Vista で当初私が懸念していた Full IME-aware applications の UI ウィンドウ制御に関する互換性問題は，DirectX SDK のサンプルに存在していたバグが原因であり，Vista 開発陣は IMM32 の互換機能をきちんと実装していること 現在いくつかの MMORPG 等で発生している Windows Vista での日本語入力に関する問題は，もし上記 DirectX SDK のバグと同じコードが使用されているのであれば，非常に簡単に修正可能であること 今後 Legacy IM が TSF で置き換えていく流れが確実になっているとはいえ，これで当面急いで TSF に乗り換える必要は無いと思います． そういうわけでしばらく時間をおいてもいいのですが，いったんま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
