ICC について取り上げているサイトを探してみたら、9月の下旬頃にこれを取り上げている日記や blog がたくさん見つかった。アスキープラスに載ったのはこれの影響か。
http://www.odorikani.net/archives/2004_09.html#000116
http://www.hirax.net/diaryweb/2004/09/23.html#200409231
http://d.hatena.ne.jp/arajin/20040923#p9
http://gpm.jp/d/tito/20040924.html#p01
http://fwn.sub.jp/diary_log/diary0409.htm#0925
http://www2.big.or.jp/~iki-iki/?date=20040927#p07
Mozilla Firefox 1.0 RC1 を使ってみた。bsscroll と pageinfo は問題なく動いた。
アスキープラス 12月号で ICC が紹介されているのを確認。
プラッタを半分しか使用していない HDD を、全プラッタ使用できるようにって、それはちょっと違うと思うぞ。
Perl 5.8 での日本語の扱いに関してもう少し調査。「Perl 5.8.x Unicode関連」、「Perl 5.8 以降においての Unicode 文字列の扱い方」、「PerlのUnicode support」といったページも見つかった。ただ、use encoding をした場合に、パスに日本語を含むファイルを open できなくなってしまう問題について書かれているページは見あたらなかった。
22日の件は、Encode::_utf8_on() よりは、utf8::decode() を使う方が良さそうだ。ただし、utf8::decode() を使う場合は、use encoding で Filter => 1 を指定しないとうまくいかなかった。複雑怪奇だ。
use encoding "cp932", Filter => 1;
use Encode;
$filename = "C:/Documents and Settings/user/デスクトップ/hoge.txt";
$filename = encode("cp932", $filename);
utf8::decode($filename);
open IN, $filename;
ソース自体を UTF-8 で記述した場合は、
use utf8;
use Encode;
$filename = "C:/Documents and Settings/user/デスクトップ/hoge.txt";
$filename = encode("cp932", $filename);
utf8::decode($filename);
open IN, $filename;
といった感じになる。必要に応じて、use open ":encoding(cp932)"; や binmode STDOUT, ":encoding(cp932)"; などの指定も必要になるだろう。
Perl 5.8 での日本語の扱いに関して少し調べてみた。「Perl-5.8 MEMO」、「perl5.8のUnicodeサポート」などが詳しい。
Offline NT Password & Registry Editor というものを知った。WinNT 系でパスワードを忘れても、これを使えば再インストールの必要はないらしい。でも使い方はかなり面倒くさそうだ。
ActivePerl 5.8.4 で、use encoding "cp932"; としてしまうと、パスに日本語を含むファイルを open できなくなってしまうようだ。
use encoding "cp932"; open IN, "C:/Documents and Settings/user/デスクトップ/hoge.txt";
以下のように書き換えたところ、とりあえず開けるようになった。
use encoding "cp932";
use Encode;
$filename = "C:/Documents and Settings/user/デスクトップ/hoge.txt";
$filename = encode("cp932", $filename);
Encode::_utf8_on($filename);
open IN, $filename;
Encode::_utf8_on() という内部関数を使っているのがかなりいやらしい。もっと良い方法はないものだろうか。
ちなみに、この問題は、Perlモジュール/Tk を見て知った。
Cygwin JE の最新版をインストールしてみた。Cygwin の setup.exe で URL に http://cygwin-je.sourceforge.jp/cygwin_je/ を指定してインストールした。sourceforge.jp に移転する前の Cygwin JE では、bash-2.05a_ja-2 をインストールすると X が起動しなくなってしまっていたのだが、現在のものだとどうなるか試してみた。startx を実行したところ、xterm のウィンドウが一瞬だけ開いて、すぐに閉じてしまうのは以前と全く同じだった。以前は、startxwin.sh を試していなかったのだが、今回はそれも試してみた。startxwin.sh を実行してみたところ、xterm のウィンドウがすぐに閉じてしまうのは同じだったが、xterm が閉じても X は終了しないので、一応使うことはできた。
Cygwin JE の vim-6.3_ja-1 をインストールしたところ、cyggdk-x11-2.0-0.dll が見つからないというエラーが出て起動できなかった。gtk2-x11-runtime-2.4.11-1 をインストールしたところ、起動するようになった。もしかしてと思い、Cygwin/X を起動してから、gvim を実行してみたところ、GUI な vim が起動した。ただし、日本語は完全に文字化けしていた。gvim で日本語フォントを表示する方法はあるのだろうか。
bash-2.05a_ja-2 をインストールすると、startx で Cygwin/X が起動しなくなる原因が判明。/etc/X11/xinit/xinitrc に
exec xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash -l
と書かれた行があるのだが、最後の -l オプションが原因だった。-l は bash 2.06 で新設されたオプションのようで、--login と同じ意味である。そこで、これを
exec xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash --login
に書き換えたところ、無事に startx で Cygwin/X が起動するようになった。~/.xinitrc や、/usr/X11R6/bin/startxwin.sh などについても同様である。
ck の新バージョン (0.9.26) が出たので、Win9x 対応版を作ってみることにした。しかし、動かなかった。よく調べてみたところ、衝撃の事実が発覚。Win9x + Cygwin 1.5.11 では、Cygwin 用の GUI プログラムは起動すらしないのである。
Cygwin におけるプログラミング の 4.1.2. にあるサンプルプログラムをコンパイルしてみると、
warning: cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000
というメッセージが表示されるが、できあがったプログラム (hellogui.exe) は、WinXP + Cygwin 1.5.11 では、全く問題なく動作する。しかし、これを Win98SE + Cygwin 1.5.11 で実行してみたところ、うんともすんとも言わなかった。今度は Win98SE で、hellogui.exe と同じディレクトリに、Cygwin 1.3 の DLL (cygwin1.dll) を置いて実行してみたところ、全く問題なく動作してしまった。
cko 0.9.26 の動作をもう少し調べてみたところ、起動時に "failed to create mainthread handle" というエラーを出して終了していることが分かった。cygwin1.dll のソースをダウンロードして調べてみたところ、winsup/cygwin/thread.cc にそのエラーメッセージが含まれていた。pthread::init_mainthread() の DuplicateHandle() の部分でエラーが起きているようだが、対処法が分からない。お手上げだ。
結局、cko 0.9.26 Win9x 対応版は、コンソールプログラムとしてコンパイルしておくことにした。許可をもらったので、バイナリも公開することにした。
qkc という漢字コード変換ソフトがある。nkf とは異なり、指定したファイルを直接書き換えるので、余計な一時ファイルを作りたくない場合には便利である。MS-DOS 版 Ver.1.92 は、ファイルのタイムスタンプを書き換えないようになっているのだが、UNIX 版 Ver.1.00 は、ファイルのタイムスタンプを書き換えてしまう。UNIX 版でもタイムスタンプを書き換えないようにするパッチを作ってみた。(qkcc100-ftime.diff)
最新の nkf では、--overwrite オプションを付ければ、qkc と同じように、指定したファイルを直接書き換えるようになるようだ。試してみたところ、タイムスタンプも保存された。qkc とは違ってバイナリファイルもお構いなしに書き換えてしまうのはかなり問題だ。
ck 0.9.20 用 Win9x 対応パッチ。(ck-0.9.20-win9x.diff) kernel32.cpp の冗長な記述を修正。option.cpp のフォント名の指定部分を修正。
Perl でファイルコピーする方法を調べてみた。Perl5 では File::Copy を使えば、ファイルの属性も含めて正しくコピーできるようだ。ただし、Unix 系ではファイルをコピーした時に、タイムスタンプはコピーしないのが標準であるため、Unix 系では File::Copy も同様にタイムスタンプはコピーされないようである。Unix でも Windows と同じようにタイプスタンプを含めてコピーしたい時は、次のようにするのが良さそうである。
use File::Copy; ($atime, $mtime) = (stat($fromFile))[8, 9]; copy($fromFile, $toFile); utime($atime, $mtime, $toFile);
上記例で $fromFile にはコピー元のファイル名が、$toFile にはコピー先のファイル名が入っているものとする。
libunicows を gcc で使っていたが、Overriding an API in the Microsoft Layer for Unicode に書かれていることを試してみようとしたところ、リンク時にエラーが発生した。リンカに --allow-multiple-definition オプションを指定したところ、期待通りに動作した。
ck の Win9x 対応版で正しいフォントが読み込まれないことがある原因が判明した。gcc の wchar_t 文字列の扱いに問題があったのである。"ＭＳ ゴシック" の Unicode 文字列を表すつもりで L"ＭＳ ゴシック" と記述しても実際には Unicode 文字列にはならないのである。そのため、L"ＭＳ ゴシック" という文字列を CreateFontIndirectW に渡しても、正しくフォント名を認識できなかったようである。（WinXP では、問題なく動いているのが不可解だが。）
"ＭＳ ゴシック" という文字列をバイナリ表記すると、82 6C 82 72 20 83 53 83 56 83 62 83 4E 00 になる。(Shift_JIS)
L"ＭＳ ゴシック" という文字列は、gcc では、82 00 6C 00 82 00 72 00 20 00 83 00 53 00 83 00 56 00 83 00 62 00 83 00 4E 00 00 になってしまった。Shift_JIS 文字列を 1byte ごとに分解し、間に 00 を挿入しただけになっている。
結局 gcc で "ＭＳ ゴシック" という文字列を Unicode 文字列で記述するには、L"\xFF2D\xFF33\x0020\x30B4\x30B7\x30C3\x30AF" というように、16進形式で記述しないといけないようである。
どうやら CreateFontIndirectW という API は（Unicode 版であるにも関わらず）、フォント名を Shift_JIS で与えても問題なく扱えるようである。
Vim について調査中。
Vim 内で検索を実行すると、見つかった文字列がいつまでも、ハイライト表示されてしまうのが以前から気になっていた。:nohlsearch あるいは :noh と入力すれば、ハイライト表示が消えることが分かった。
Vim は、素の vi と異なり、入力モードでカーソルキーが使えるのが非常に便利である。そこで、ある Unix マシンに Vim をインストールしたのだが、どういう訳かカーソルキーが有効にならない。:help cursor-keys と入力したところ、説明が表示された。.vimrc に、
:set notimeout " don't timeout on mappings :set ttimeout " do timeout on terminal key codes :set timeoutlen=100 " timeout after 100 msec
と書けば良い。（" 以降はコメント） あるいは
:set ttyfast
でも良いようだ。なお、どちらも Vim 内で手入力した場合には有効にはならなかった。
WinXP で、OE を使っていないにもかかわらず、ログイン画面に「1 通の未読メール メッセージがあります。」という表示が出るようになってしまった。OE を起動してみると、初回起動時のようこそメールがあったが、それを削除しても未読メールの通知は表示されたままだった。Windows Messenger は使ってはいるが、自動でサインインするようにはしていない。Mozilla Mail でも未読はない。謎だ。
regedit で HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\UnreadMail を開き、右クリックでアクセス許可を選び、SYSTEM に対してアクセスを許可しないようにすればこの表示は出なくなるそうだ。
Cygwin + ck + ssh で、Unix マシンにログインした時に、BackSpace が正しく効かないアプリがあるのが以前から気になっていた。例えば、csh では、BackSpace を押しても ^H と表示されるだけで、カーソルの前の文字が消えなかったりした。いろいろ調べていてようやく原因が判明した。Cygwin 側の /etc/profile で stty erase '^?' と指定されているのが原因だった。コマンドラインから stty erase '^H' と入力したところ、意図した動作をしてくれるようになった。結局 /etc/profile の当該行をコメントアウトしておいた。
diff -u 形式で cko の Win9x 対応パッチを作ってみた。(ck-0.9.17-win9x.diff) 変更した点は以下の通り。
4. の変更は、ckstart が Win9x で使えないからである。cko の起動時に DOS 窓が表示されるのを消すために、run.exe を使うと、cko のメインウィンドウも表示されなくなってしまうという問題がある。SW_SHOW を指定しておけば、run.exe を使った時もメインウィンドウが表示されるようになる。SW_NORMAL や SW_SHOWDEFAULT を指定した場合は、それ以外の時のウィンドウの表示のされ方が変わる場合があるが、SW_SHOW ならば run.exe 以外での表示のされ方は変わらないようである。
MZLU は実装されている API が少なくて cko は動かなかった。実行する際には、unicows.dll が必要となる。
poEdit というソフトを見つけた。gettext メッセージカタログエディタだそうだ。gettext を使っているソフトをローカライズするのに便利だそうだ。ちなみに、同梱の unicows.dll は古いらしい。
ck の Win9x 対応版を作成。何とか Win98SE で cko（不透明ウィンドウ版）は起動するようになった。しかし、ボールドフォントが化ける。半透明ウィンドウ版の ck は、Win2k で新設された半透明処理用の API (UpdateLayeredWindow) を使っているため起動できない。
Ls312 で Win9x 対応パッチを作成していたのだが、最初はただの条件分岐の部分で cko が落ちていた。gcc -S でアセンブリソースをはき出してみると、cmov 命令が使われていた。MMX Pentium では使えない命令なので落ちて当然だった。コンパイルオプションで -mcpu=i686 -march=i686 が指定されていたので、 -mcpu=i586 -march=i586 に変更したところ、Ls312 でも無事 cko が動くようになった。
先月の spam メールの集計結果。着信拒否になった spam が少なくとも 4674通。着信拒否にならなかった spam が 440通。そのうち Spam Mail Killer で削除できた spam は 428通(97.3%)。中旬頃には、毎日 200通近くの spam が送られてきていた。
Command Line Process Viewer/Killer/Suspender for Windows NT/2000/XP というものを見つけた。コマンドラインからプロセスをいじれるのは、おもしろそうだ。
ck を Win9x に対応させることはできないか調査中。
The Microsoft Layer for Unicode on Windows 95/98/Me Systems (MSLU, unicows) というものがある。Win9x で Unicode 系（〜W 系）API を使えるようにするための、ライブラリ & DLL である。MSLU を使ったプログラムの作り方は、「プログラムの小ネタ(?)集」などに説明がある。
MSLU は、unicows.dll と unicows.lib から構成されている。unicows.dll は、単体でダウンロードできるが、unicows.lib は Platform SDK にしか含まれておらず、単体でダウンロードすることはできない。また、unicows.lib は、BCC や gcc など他社製のコンパイラでは使うことができない。unicows.lib 互換のフリーな実装が存在する。libunicows がそれである。
unicows.dll 互換のフリーな実装も存在する。Mozilla Layer for Unicode (MZLU) というものである。現バージョンでは、実装されている API の数は unicows.dll より少ないが、一部、unicows.dll に実装されていない API が実装されている。