SpringM Ver.1.50k23 で、日本語ファイル名の補完がおかしくなったとの報告があったので、調べてみたところ、XP 以降のビジュアルスタイルが原因だった。全く予想外の原因だったため、解明に時間が掛かってしまった。
ビジュアルスタイルを使うと、エディットコントロールの挙動が変わり、ANSI 版 API を使っても、カーソル位置の設定・取得がバイト単位ではなく、文字単位になってしまうのである。調べてみると、次のような情報が見つかった。
SpringM では簡単に対応できそうにないので、ビジュアルスタイルの適用をやめることにした。
大量のファイルをマークしていると、再読込が妙に遅いのが気になった。C:\Windows\System32 のファイルをすべてマークしてあると、再読込に 1.5秒程度掛かる。時間を計測してみると、ファイルをマークしてマークファイルサイズを計算する関数の処理に時間が掛かっていた。しかし、SpringM で Home キーを押したときの処理はこれほど時間は掛からない。解析したところ、マーク処理をするたびに画面の更新を行うか、最後に一度だけ画面を更新するかの違いだった。マーク処理が終わってから画面を更新するように変更したところ、0.05秒程度で処理が終わるようになった。
1.50k21 からは、springm.dll から絶対アドレス指定で直接 EXE 内部の関数を呼び出すというかなり怪しいことをやっている。Delphi と VC++ では関数の呼び出し規約も異なるので、インラインアセンブラを使っている。
VC++ のインラインアセンブラでは、絶対アドレス指定でメモリの内容を読むことはできないのだろうか？
__asm {
mov eax, dword ptr [0x004aab38]
}
というコードを書いてみたのだが、
__asm {
mov eax, 0x004aab38
}
として解釈されてしまった。結局、次のようなマクロを定義して、_emit で命令コードを直接埋め込むようにしてみた。
#define mov_eax(moffs32) \
__asm _emit 0xa1 \
__asm _emit (moffs32) & 0xff \
__asm _emit (moffs32>> 8) & 0xff \
__asm _emit (moffs32>>16) & 0xff \
__asm _emit (moffs32>>24) & 0xff
__asm {
mov_eax(0x004aab38)
}
Vista を再起動したときなどに、ATOK パレットが画面の左上に勝手に移動してしまうことがある件だが、ATOK2007 の FAQ に載っている方法が ATOK2006 でも有効なのか確かめてみることにした。「パレット状態の自動保存=〜」という設定が ATOK2006 の設定ファイルには書かれていないようなので、これを書き加えてみた。3回ほど再起動してみたが、ATOK パレットは左上には移動しなかった。効いているのだろうか。
SpringM で長年の懸案事項だった、ファイルマークの挙動をついに解決することに成功。SpringM では、コマンドを実行したり、他のアプリからフォーカスが移ってくると、ファイルの一覧を取得し直すが、その際に、ファイルのマークが解除されてしまうという制限があった。今までは不満に思いながらも我慢して使ってきたが、SpringM の内蔵テキストビューワーも不満で、外部テキストビューワーの使用を検討し始めたところ、今度は、マークが解除される問題が気になってしまった。外部ビューワーを使うと、ファイルの中身を確認しながらマークするという使い方ができなくなってしまうためである。
再読込直前に、springm.dll 側でマークしたファイルの一覧を保存しておいて、再読込直後に、読み込んだファイル一覧とマークファイルの一覧を比較してマーク状態を復帰するようにした。
今までとは挙動が変更になるため、慣れるのに時間が掛かるかもしれない。
高速で使いやすいテキストビューワーが見つからないので、自分で作ろうかと思案中。他には、ヒストリの個数も 24個では少ないので 50〜100個ぐらいに増やしたいところ。Logdisk でディレクトリ名を入力すると、すべて大文字に変えられてからディレクトリの移動が行われるのも何とかしたい。
富士通から気になる UMPC (Ultra-Mobile PC) が発表された。小さい PC は大好きなのでこれはかなり気になる。
同種の小型 PC としては最近は、工人舎 SA1F があるが、画面が 800x480 と狭いのとキーボードがちゃちだったのが駄目。かつて FIVA 102 を使っていた者とすればやはり画面は 800x600 は欲しい。今回の LIFEBOOK U は 1024x600 ということでかなり魅力的である。キーボードも見た目はしっかりしていそうな雰囲気である。ただ、キーボードの配列がかなり特殊だ。カーソルキーが独立しておらず、PageUp, PageDown, Home, End が見当たらない。カーソルキーぐらいは独立していてほしいが。
個人向けは秋に発売だそうだ。XP モデルが残されるのかどうかが気になるところ。UMPC には Vista は重いと思うのだが。
同様の UMPC はもう１社開発中らしいので、そちらも注目したい。
SpringM で、もっと長いファイル名も表示できるようにしてほしいという要望があったが、ようやくその処理を行っている場所を発見。列数を計算するアルゴリズムも判明。どのように対処するかが悩みどころ。
SpringM のパッチ作成のために書いている、springm.2.asm を MASM 7.1 でアセンブルすると、MASM 6.1 に比べて、やたら時間が掛かって大きな .obj ファイルができるのが以前から気になっていた。調べてみると、MASM 7.1 では出力形式が OMF から COFF に変更されたのが原因だったようだ。/omf を指定すれば、MASM 7.1 でも MASM 6.1 と同じように短時間でアセンブルできた。
Vista では、タスクトレイの時計をクリックすると、時計とカレンダーが表示されるが、TClock Light でも表示できるようにしてみようと思った。Spy++ を使って、どういうようにしてこれが表示されるのかを調べてみた。WM_USER + 102, 103 というメッセージが使われているようだ。WM_USER + 102 を送出してみたところ、表示はできるようになったが、表示されるのが妙に遅い。Spy++ で監視してみたところ、これと関連があるのかどうかは不明だが、やたらに WM_NCHITTEST が発生している。XP では起きていない。もう少し調べてみる必要がありそうだ。
Vista 上で、TClock Light を VC6 を使ってコンパイルしてみたのだが、コンパイルがやたら遅い。CF-R6M でコンパイルすると CF-R2C の倍くらいの時間が掛かる。Windows Defender あたりが関係あるのではないかと思い、これを切ってみたが変化無し。何が原因なのだろうか。
やはり Vista などやめて、CF-R6M にも XP を入れるべきか？
ATOK2006 を Vista で使っていると、Vista を再起動したときなどに、ATOK パレットが画面の左上に勝手に移動してしまうことがある。移動してしまった場合は、表示されるボタンの数も３つになってしまう。2ch を見たところ、この問題は ATOK2007 でも発生しているらしい。
とりあえず、ATOK パレットの表示位置がどこに記録されているのか調べてみた。自分の環境では、以下の2つのファイルに保存されていた。
%USERPROFILE%\AppData\Local\Justsystem\Atok19\atok19wl.aen [ＡＴＯＫパレット２] パレット位置=0,0 パレット位置起点=右下 %USERPROFILE%\AppData\Roaming\Justsystem\Atok19\Atok19w.aen [ＡＴＯＫパレット２] 通常表示ボタン数=8
プログラムで表示位置・表示サイズを変更できないか試してみた。MoveWindow() や SetWindowPos() を使って強制的に表示位置を動かした場合は、すぐにもとの場所に戻ってしまう。
IME 制御用の API を試してみた。試してみたのは IMC_SETSTATUSWINDOWPOS, IMC_GETSTATUSWINDOWPOS の２つ。どうもここに書かれていることと、実際の挙動が違う。IMC_SETSTATUSWINDOWPOS は、lParam には POINTS へのポインタを指定するように書かれているが、実際には POINTS をそのまま指定するようだ。IMC_GETSTATUSWINDOWPOS は、戻り値として POINTS を返すと書かれているが、実際には、lParam で POINTS へのポインタを指定する必要があった。MSDN が間違っているのか、それとも ATOK の実装が間違っているのか、どちらだろう。
最終的には IMC_SETSTATUSWINDOWPOS を使うことで表示位置だけは変更できるようになったが、表示されるボタンの数までは変更できなかった。
いろいろ調べていたところ、ATOK12 は、制御用の API が公開されていることを知った。しかし、パレットの表示位置を変更する API は見当たらない。そもそも、これらの API は現在の ATOK でも使えるのだろうか？ 面倒なので確かめてはいないが。
この現象は ATOK2007 の FAQ には載っていることを後で知ったが、ATOK2006 には「パレット状態の自動保存=する」という設定が見当たらない。
ShellExView を使って GraphicsShellExt Class を無効にすると、タスクトレイにある、Intel Graphics Media Accelerator のアイコンを右クリックしてもメニューが出ないことに今更ながら気付いた。タスクトレイの方のメニューを無効にしないで、デスクトップを右クリックしたときのメニュー表示を高速化することはできないものだろうか。
ShellExView を Vista で使う際に、管理者権限で起動するのを忘れたために設定が変更できず、ちょっと悩んだ。
必ず管理者権限で起動するようにするため、ResourceHacker を使って manifest リソースを書き換えてみようとしたのだが、書き換えたらプログラムが起動しなくなってしまった。よく見ると UPX で圧縮されていた。UPX の圧縮を解除しようとしたところ、プロテクトが掛かっていると言われて、解除できなかった。結局、バイナリエディタで manifest リソースを直接書き換えることで、必ず管理者権限で起動するようにできた。元のサイズを超えないように書き換えるのはちょっと苦労したが、元々の manifest リソースには改行がたくさん含まれていたので、それらを削ったり、省略可能なものは省略することで何とかできた。
後になって気付いたが、こんな面倒なことをしなくとも、ファイルのプロパティ → 互換性タブ で管理者権限で実行するようにすれば良かっただけか。
UAC が有効かどうかをプログラムから知りたいと思い、調べてみた。レジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System の EnableLUA が 1 ならば有効とのこと。
UAC が有効なときに、SpringM を管理者権限で起動したら、タイトルにその旨表示するように改造しようかと考えている。ファイラーを Vista で使うなら、管理者権限で動いているかどうかが一目で分かるほうが都合が良いだろう。
関連付けされていないファイルを開こうとしたときの挙動が、ShellExecute() と ShellExecuteEx() とで違う場合があるようだ。
Vista では、ShellExecute() と ShellExecuteEx() のどちらを使っても、関連付けされていないファイルを開こうとしたときには、次のようなダイアログボックスが表示された。
しかし、WinXP SP2 で試したところ、ShellExecuteEx() を使った場合には、このダイアログボックスが表示されたのだが、ShellExecute() を使った場合には、関連付けがされていないとのエラー (SE_ERR_NOASSOC) を返すだけで、ダイアログボックスは表示されなかった。
さらに調べてみると、Vista でも拡張子によっては、ShellExecute() と ShellExecuteEx() で挙動が違うものがあった。
ShellExecuteEx() は、拡張された機能さえ使わなければ、ShellExecute() と全く同じように動くものだとばかり思っていたのだが、そうではないのだろうか。ShellExecuteEx() の方は fMask には、0 を指定しているのだが、何か追加のフラグを指定したら、ShellExecute() と同じ動作になるのだろうか。関係ありそうなものとして、SEE_MASK_FLAG_NO_UI を指定してみたが、同じ動作にはならなかった。
ShellExecuteEx() で lpVerb に "runas" を指定すると、Vista では権限昇格のダイアログが出るということを知った。早速、startw を改造。管理者権限で実行するための -admin オプションを付けた Ver.1.05 をリリースした。
Win2k/XP や UAC オフの Vista で "runas" を指定すると、既に管理者権限で動いている場合でも「別のユーザーとして実行」ダイアログが出てしまう。管理者権限で動いているかどうかを判別する必要があるがやり方が分からない。
とりあえずググって見ると、「Visual C++ 6.0 でのマニフェストもどきの実装」というものが見つかった。ただ、ちょっと面倒な感じである。もっと簡単な方法は無いものか？ （ちなみに、リンク先には VC++ 6.0 ではマニフェストが使えないとあるが、実際には以前書いたように可能であり、この方法は Vista 用のマニフェストファイルにも使える。）
さらにググって見ると、IsUserAnAdmin() というものを知った。この API は、かつては隠し API だったらしく、Win2k では、序数 680 (0x02a8) だけでエクスポートされており、名前では参照できない。WinXP からは名前でも参照できるようになっている。VC++ 7.1 付属の SDK は、この API に対応しており、序数でインポートするようになっていた。リンク先にもあるように、IsUserAnAdmin() 相当の機能は、CheckTokenMembership() で実装できるようだが、IsUserAnAdmin() に比べるとやはりちょっと面倒である。
IsUserAnAdmin() を使用するように startw を改造し、Ver.1.06 をリリースした。
Win2k/XP では "runas" を指定すると任意のユーザーでプログラムの起動できるが、Vista (UAC on) では権限の昇格しかできないというのは、ある意味機能ダウンの気がするが、こんなのでいいのだろうか？（一応、コマンドラインから runas コマンドを使えば任意のユーザーで起動はできるが・・・。）
ワイヤレスレーザーマウス V450 の電池がついに切れた。電池残量が少なくなったことを示す赤いランプが昨日の夜から点いていたが、それからは１日持たなかった。本来は単３電池を使うところを、単４の eneloop を使って３ヶ月弱持った。カタログスペックと比較するとちょっと短い気もするがそれでも実用上十分だ。
Vista で TaskArrange を使ってタスクバーのアプリの順番を入れ替えられるか試してみた。エクスプローラがクラッシュして使えなかった。残念。
SpringM の関連付け実行にまだ問題が残っていたことが発覚。OS で関連付けがなされているかどうかをチェックしている部分が正しく動かないことがあるようだ。正しく直すのも面倒なので、チェックを省いて直接 ShellExecute() を呼び出すことにしよう。
SpringM の内蔵テキストビューワーは、Unicode に対応していないので最近は何かと不便である。外部ビューワーとして ttPage-R でも使ってみようかと思ったのだが、CF-R6M で動かしてみると起動が遅いのがどうしても気になる。CF-R2C で試してみると起動は一瞬なのだが。遅いのはやはり OS のせいだと思われる。そういえば Vista には ReadyBoost などという機能があったのを思い出して試してみた。
ReadyBoost には向いていないと言われている SD カードで試してみた。KINGMAX の 2GB の SD カード（型番不明）を R6M の SD カードスロットに挿して使った。ReadyBoost の効果を発揮するにはメインメモリの 2倍の容量が必要と言われているが、空きが 1GB しかないのでその 1GB を ReadyBoost に割り当てた。
SD カードへのキャッシュの書き込みが終わってから、ttPage-R を起動させてみると、確かに早くなった。正確な時間は測定できていないが、元々 0.5秒程度だったものが 0.2秒ぐらいになったようである。とはいえ、やはりまだ R2C に比べると遅い。テキストビューワーは 0.1秒未満で起動してほしいところ。
Vista でも瞬時に起動する使いやすいテキストビューワーはないだろうか。
Sysinternals などで有名な、Mark Russinovich 氏による Vista カーネルの解説記事があることを知った。後でじっくり読もう。
SpringM のテキストビューワー機能を解析していて、タグジャンプ機能があることを再発見した。ヘルプにはしっかりと書かれているのだが、全く使っていなかったのですっかり忘れていた。ヘルプには、対応しているタグジャンプの書式については何も書かれていないので、どういう書式が使えるのか調べてみた。逆アセンブルリストと見比べながら実験してみたところ、SpringM が対応しているのは次の２つの書式だけのようだ。
ファイル名 行番号: コメント "ファイル名" 行番号: コメント
あまり使い道がなさそう・・・。どういうソフトで使われていた書式なのだろうか？
CF-R6M を使っていると、時々ホイールパッドユーティリティが効かなくなることがあるのだが、何なのだろう。（ホイールパッドユーティリティとは Let's note の円形のスライドパッドをぐるぐるなぞることでスクロールできるようにするためのソフト。） 特にスリープや、休止状態から復帰したときが怪しい気がする。しばらく待っていたら使えるようになった場合と、タスクマネージャで WheelPad.exe を殺してから、C:\Program Files\Panasonic\WheelPad.exe を立ち上げなおしたら使えるようになった場合と、再起動しなければ復活しなかった場合がある。
ホイールパッドユーティリティによるスクロールは（Vista だけでなく XP でも）、Wheel Redirector でリダイレクトできないのも以前から気になっている。Wheel Redirector はソースが公開されているので何とかしてみたいところである。
SpringM を Vista で使っていると、関連付け実行がうまく動かないことが多発してきた。.html や .pdf は時々開けないことがあり、さらに、先日 Orca をインストールしてからは、.msi を実行しようとすると、インストールされるのではなく Orca で開かれてしまうという状態になっていた。不便なので、詳しく調べてみることにした。
最初は、関連付けで実行する実行ファイル名を自力で取得しているのかと思い、関係ありそうな、FindExecutable(), AssocQueryString() といった API を調べてみたが、SpringM はこれらの API は使っていなかった。
次に、関連付けの実行で最もよく使われる ShellExecute() について調べてみた。デバッガ上で ShellExecute() の呼び出しを確認してみたところ、.html の実行時には、第２引数 (lpVerb) に "opennew" が指定されていた。通常、関連付け実行する際には、lpVerb には、"open" あるいは NULL を指定するはずなのだが・・・。調べてみると、SpringM では lpVerb で指定する“動詞”を動的に取得しているようである。取得方法に問題があるものと思われるが、どのように取得しているのかが分からない。しかし、そんな面倒なことをしなくても、lpVerb には NULL を指定しておけば規定の操作をしてくれることになっているので、そうする方が良いはず。
ということで、ShellExecute() の第２引数は NULL に固定して関連付け実行を行うように改変してみた。うまく動いているようだ。
Vista では、.hlp 形式のヘルプファイルが使えなくなってしまった。しかし、.hlp 形式を使っているソフトも結構あるので不便である。Vista 用の WinHlp32.exe をインストールすることにした。
Windows6.0-KB917607-x86.msu (64bit 版だと Windows6.0-KB917607-x64.msu) をダウンロードしてインストールすることで、無事 .hlp が読めるようになった。ただし、上記ページにもあるように、ネットワークの先のヘルプファイルはそのままでは読めないので注意が必要である。
せっかく買った CF-R6M だが、今のところ、室内モバイルマシンとしてしか使っていない。今後のためにバッテリーの持ちを調べてみることにした。比較のために、CF-R2C も同時に測ってみることにした。
まずは、付属の「PC情報ビューアー」で満充電容量を調査。CF-R6M は 41760mWh。しかし、エコノミーモード ON にしているため、残容量は 33410mWh。一方、CF-R2C は、26050mWh。公称容量は 4.4Ah、電圧は 7.4V なので、元々の容量は 32560mWh 程度のはず。どちらも本来の能力のちょうど 8割での比較となる。
それ以外のスペックは、以下の通り。
CF-R6M: Mem: 1.0GB + 512MB、HDD: 120GB、Aero ON、無線 LAN ON CF-R2C: Mem: 256MB + 256MB、HDD: 40GB、無線 LAN ON
ディスプレイの明るさは、どちらも 20段階のうち、暗い方から 4番目に設定。R2C のバックライトはかなりへたっているので、同じ設定でも R2C の方が暗いが。
この状態で使ったところ、R6M は開始時の残容量 80% から 2時間で 45% まで減少、3時間で 27% になり、3時間 40分 で息絶えた。
一方の R2C は、開始時 100% から 2時間で 48%、3時間で 22% となり、こちらもほぼ同じ 3時間 45分 で息絶えた。
実際の作業内容は、R6M の方は、Web ページを見ながら文章を書いたりしていたが、R2C は、スクリーンセーバーが動かない程度に Web ページを見ていた程度なので、R6M の方が負担は大きかったわけだが、どちらもほとんど同じ時間だったというのはちょっと複雑な気分。
R6M は、満充電で使ったとして、4時間 35分になる計算。カタログスペックの約６割といったところか。
先月の spam メールの集計結果。着信拒否にならなかった spam が少なくとも 1850通。そのうち、@nifty の迷惑メールフォルダーでも Spam Mail Killer でも spam として認識できなかったものは 2通(0.1%)。やはり先月も、@nifty の迷惑メールフォルダーの判別精度は非常に良かった。今度は SMK の判定精度を上げることを考えた方が良いかもしれない。
