今度は ResourceHacker を使って、SpringM のダイアログボックスを修正。アクセスキーを追加するだけで、ずいぶん操作性が向上した。コピー・移動時に同名ファイルが存在したときに表示されるダイアログボックスは、プログラムで文字列を変更しているために、ResourceHacker で表示を変更することはできなかった。仕方なくバイナリエディタを使って手動でパッチ当て。
何とか SpringM の修正を完了。パッチの総容量は、570bytes にもなってしまった。数バイトや数十バイト程度のパッチ当ては今までいろいろとやってきたが、これほどのものは初めてである。
キャプチャボードを導入してから大容量ファイル・ディスクを扱う機会が多くなり、負のサイズをたびたび目にすることがあって、何とかしたいと思っていたのだが、これで気分よく使える。後は 4GiB 以上のファイルサイズの表示を何とかしたいところだ。本当は自分で１からファイラーを作りたいところだが、JF はずいぶん前から開発停止状態だ。
SpringM をまた改造。Win2k/XP で正しいディスクサイズが表示できるようになったのは、思っていた以上に便利だったので、今度は Win9x でも正しいディスクサイズを表示ができるようにしてみた。GetModuleHandleA() と GetProcAddress() を使って、動的（明示的）に GetDiskFreeSpaceExA() のアドレスを取得しているので、素の Win95 でもそのまま動くはずである。ちなみに、明示的リンクよりも暗黙的リンクにしてしまった方が、コードは簡単に記述できるのだが、あえて明示的リンクにしたのは、バイナリをいじって GetDiskFreeSpaceExA() への暗黙的リンクを追加する方法が分からなかったからである。
Win32API の呼び出しでは ecx, edx は破壊されないという前提でコードを記述していたためにはまってしまった。WinXP で実行したら、スタックオーバーフローというエラーが表示されたり、Win98 で実行したら、ウィンドウを閉じてもプログラムが残っていて、プログラムを複数立ち上げるとどんどんシステムリソースを消費していくといった現象が発生した。なかなか原因が分からず、VC++ のデバッガでステップ実行してようやく原因が分かった。edx はともかく、ecx も破壊されるというのは意外だった。
Win9x で、ピリオドを２つ以上含むディレクトリに移動できなくなってしまった。よく調べてみると、Win9x の GetDiskFreeSpaceExA() がバグっていることが判明。ピリオドを２つ以上含むディレクトリをカレントディレクトリにした状態で、第１引数を NULL にして GetDiskFreeSpaceExA() を呼び出すとプログラムが落ちてしまう。なんてこった。回避方法としては、GetCurrentDirectoryA() でカレントディレクトリを取得し、UNC パスでなければ、そのディレクトリをルートディレクトリに変換して、GetDiskFreeSpaceExA() に渡せばよいようだ。問題はそれだけのパッチを当てるスペースが残っていないことである。
LaTeX で pdf 画像を取り込むには、mediabb.sty を使うと .bb ファイルを生成する必要がなくなって楽らしい。
「ProcessorPack 5.0をVisual C++ 6.0 (Service Pack 6)にインストールする」というページを見つけた。おもしろい情報だが、今のところ VCPP はインストールはせずに MASM 6.15 を取り出して使っているだけだし、今後もインストールすることはなさそうだ。それに最近は、MASM は VS.NET 2003 に付属の Ver.7.10.3077 を使っている。ただ、VCPP5 に同梱されている MasmRef.doc だけはちょっと役に立つ。Word ファイルは嫌いなので、PDF に変換してから読んでいる。
引き続き SpringM の解析を行う。
"%9d" という文字列が見つかったので、それを "%9u" に書き換えてみたところ、2GiB 以上のファイルサイズでも表示が負にならなくなった。これで 4GiB までのファイルならばファイルサイズが正しく表示できる。しかし、それ以上になると、実際にファイルサイズを 4GiB で割った時の余りが表示されるはずである。4GiB 以上のファイルサイズでも正しく表示できるようにするのはかなり大変そうなので、そこまではやらないつもりである。
ディスクサイズおよび、マークファイルの合計サイズの表示部分は、一文字書き換えるだけというわけにはいかないような感じである。これらは、コンマでの 3桁区切りで表示を行うためか、32bit 整数を fild 命令で浮動小数点数に変換してから、表示を行っている。32bit 符号無し整数を直接浮動小数点数に変換するような命令は無いようなので、結局、32bit 符号無し整数を一度 64bit 符号付き整数に変換してから、fild 命令を使って浮動小数点数に変換しないと 2GiB 以上のサイズは正しく表示できないということになる。しかし、マークファイルの合計サイズに関しては、
fild dword ptr [eax+4]
という命令を、
fild qword ptr [eax+4]
に変更 (dword -> qword) したところ、4GiB までならば正しく表示されるようになった。どうやら、上位 32bit がうまい具合に 0 になっているために、たまたまこれだけの変更で表示できるようになったようだ。一方、ディスクサイズに関しては、こううまくはいかないような感じである。それに、ファイルサイズならまだしもディスクサイズが 4GiB までしか正しく表示できないというのはかなり問題である。
SpringM では、ディスクの総容量と空き容量を求めるのに、GetDiskFreeSpace() という API を使っている。この API では、セクタサイズ、１クラスタ当たりのセクタ数、クラスタ数が取得できる。ディスクの容量を得るにはこれら３つの数値を掛け合わせなければならない。SpringM では、困ったことに、この数値の掛け算には、imul という命令が使われていた。imul では、符号付き整数の掛け算が行われるのである。そこで、これを mul 命令を使って、符号無し整数として扱うように変更した。なお、GetDiskFreeSpace() は、Win9x だと最大 2GiB までの値しか返さないという問題があるが、これを GetDiskFreeSpaceEx() を使うように変更するのは、やはりかなり大変なので、そこまではやらないことにする。
結局、ディスクサイズは 64bit 符号付き整数で扱うように大幅に書き換えた。ステップ数はおよそ 100。さすがにこれだけの分量をハンドアセンブルでやるのは無謀なので、アセンブラを使った。ただし、アセンブル結果を実行ファイルに埋め込むのは、アセンブルリストを見ながら、バイナリエディタで手入力だった。打ち込みに２か所ほど間違いがあったが、直したところ無事にディスクサイズが正しく表示できるようになった。160GB の HDD でも表示を確認してみたが、総容量、空き容量ともに正しく表示された。（前述のように、Win9x では、ディスク容量が 2GiB 以上あっても、2GiB として表示されるが、これは仕方あるまい。）
SpringM には、WinNT 系 OS で空ディレクトリが削除できないという問題があるのだが、どういう訳か、その問題が発生しないマシンもある。調べてみたところ、設定の問題だった。メニュー → 「設定」 → 「動作設定」 → 「動作設定」タブ → 「ディレクトリ削除時の読み込み違反対策をする」のチェックを外したところ、WinXP でも空ディレクトリを削除できるようになった。
あとは、2GiB 以上のファイル・ディスクサイズの表示がおかしくなる（負の値になったりする）のが何とかできればいいのだが・・・。ということで、SpringM を少し解析してみることにした。
解析してみたが、原因となっている場所がなかなか特定できない。SpringM は Delphi (or BCB) で書かれているようだが、Delphi だとコードとデータが同一のセクション内に混在しているので、怪しい文字列を探すのにも一苦労である。
ファイル・ディスクサイズの表示とは別の部分で少し気になっているところもいくつかあるのだが、１か所簡単に直せそうな部分が見つかったので、直してみることにした。SpringM には、アーカイブファイルの中を直接見ることができる lview という機能がある。lview は、SpringM のファイラーとは UI が異なっているのだが、表示に少々問題がある。具体的には、ファイル名が長いとファイルサイズやタイムスタンプの表示が後ろにずれてしまうという問題と、タイムスタンプの min. の値が 9 以下の時に 10の位の 0 が表示されないという問題がある。ついでに圧縮率の表示で % が全角になっているのもちょっと気に入らない。"%-13s%10d%10d %3d.%1d％ %4d/%2d/%2d %2d:%2d" という文字列が見つかったので、それを "%-30s%11u%11u %3d.%1d%% %5d/%2d/%2d %2d:%.2d" に書き換えた。これで、ファイル名の部分は 30文字以内ならば、ずれなくなる。文字が１文字増えてしまったので、つじつま合わせもしないといけない。C の文字列は '\0' で終端となるのだが、Delphi では C とは異なって、文字列の長さが一緒に格納されているのでそれを変更する必要があるのである。
SpringM の解析中に fild という命令を見つけたのだが、どういう命令なのかが分からなかった。インテルのサイトから「IA-32 インテル アーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル」を DL してきた。以前とは異なって、中巻が A, B の２つに分かれている。（下巻へのリンクがないのも少し気になるが今回は必要ない。）
fild を調べると、16bit, 32bit, 64bit の符号付き整数を浮動小数点数に変換し、変換結果の値をFPUレジスタスタックにプッシュする命令と判明。2GiB 以上のディスクサイズが負として表示されるのはここで 32bit 符号付き整数として扱っているのが原因のようだ。
SpringM の解析中に diswin, dispe にバグを発見した。DB 3C 24 というバイト列を逆アセンブルすると、
fstp tbyte ptr [esp]
になるべきなのに、どちらも
fstp dword ptr [esp]
になっていた。
ずいぶん前に、Susie plug-in のバージョンを上げたら (0.06)、SpringM で zip ファイルが扱えなくなってしまうということがあった。そのときは、axzip.spi のバージョンを下げことで対応していたのだが、久しぶりに Susie のサイトをチェックしてみたら、axzip.spi の新バージョン (0.08) が出ていた。SpringM で問題なく動いた。他のプラグインのバージョンもいくつかチェックしてみたところ、ifjpegx.spi（MMX, SSE2 対応の JPEG Plug-in）が更新されていた。ちなみに、Susie Plug-in を探すには、Susie Plug-in/etc Link Page が便利だ。（長いこと更新されていないのが残念だが。）
Windows で扱えるディスクには、ブートセクタの先頭付近 (03h-0Ah) に、フォーマットした OS 名等 (OEMVersion) が書き込まれる部分がある。例えば Win98 でフォーマットすると MSWIN4.1 となる。実は以前から、この部分が勝手に書き換わることがあるのに気付いて、気になっていた。少し調べてみることにした。
まず、WinXP で ipl98 を使って FD に IPL を書き込んでみる。この時点で OEMVersion は "MSWIN4.1" となっているはず。rwfd を使ってデータを吸い出して確認してみると確かに "MSWIN4.1" となっていた。次にこの FD を Win98 マシンへ持って行って、dir で中身を表示してみる。再びこの FD を WinXP マシンに持ってきて rwfd でデータを吸い出して確認してみたところ、OEMVersion が "-.E(6IHC" という奇妙な文字列に変わっていた。もう一度 Win98 へ持って行って、FD にアクセスしてみたが、今度は OEMVersion は、"-.E(6IHC" のままだった。
もう一度 ipl98 を使って FD に IPL を書き込んで、OEMVersion を "MSWIN4.1" に戻してから、再び FD に Win98 でアクセスしてみたところ、今度は、OEMVersion が "-i{h2IHC" になっていた。先ほどとは少し違っている。
さらにもう一度同じことをしてみると、今度は "-hF`-IHC" になった。同じような問題は、「簡易OSを作ろう編−２」でも発生しているようだ。
どうやら Win9x でリムーバブルメディア (or FAT12/16 media ?) にアクセスすると、OEMVersion が "?????IHC" の形式に勝手に書き換わるらしい。"?????" の部分はランダムのようだ。一度 "?????IHC" の形式になるとそれ以降は書き換わらないらしい。HDD (FAT32) の場合は OEMVersion は、"MSWIN4.1" のまま書き換わらないようだ。
ちなみに Win9x では X68000 フォーマットの FD の IPL が改竄されるという問題もあるようだが、これとは微妙に違うようだ。こちらは、BPB の部分が勝手に上書きされているようである。
Perl 5.8.4 での use encoding の動作が少々怪しい。s/@/@/g; という処理で "ァ" を含む文字列の一部が文字化けを起こしてしまった。（Shift_JIS だと "ァ" の 2byte 目は、"@" と等しい。） open で明示的に encoding を指定したところ、文字化けは発生しなかった。
Java で zip ファイルを扱う場合、普通は java.util.zip.ZipFile を使うことになるのだが、これには、ファイル名が UTF-8 以外のものが扱えないという欠点がある。org.apache.tools.zip.ZipFile を使えば、Shift_JIS などでも扱えるようになるという話を聞いて調べてみた。これは、Ant に含まれているらしい。確認してみたところ、Ant の lib\ant.jar の中に確かに、org.apache.tools.zip.ZipFile が含まれていた。これの使い方は、docs\manual\api\apache\tools\zip\package-summary.html などに書かれていた。Encoding が指定できる以外は、java.util.zip.ZipFile とほとんど同じように使えるようである。JF に組み込みたいところだが・・・。
TV キャプチャ用マシン ST6E が不調だ。昨日、パワーマネージメント関連の設定をいじって以来おかしくなってしまったようだ。サスペンドしてしまうと、録画予約時間になってもサスペンド状態から復帰しない。つまり録画がされない。これは大問題である。よく調べてみると、サスペンド状態の時に、時計が進んでいないようなのである。手動でサスペンド状態から復帰させると、時計がサスペンドに入った時刻のままになっているのである。さて、どうしたものか。
ヤンマーニ ヤンマーニ ヤンマーニ ヤーイヤ♪
今更ながら買ってみた。EXDAP512 でループ再生。
AT 互換機 ST6E でサスペンドの状態を変更できることを知った。現在は S1 になっていた。サスペンド時の消費電力がより少ない S3 に変更してみた。なんだかサスペンドからの復帰が不安定な気がしたので、結局元の S1 に戻しておいた。
設定変更のせいか、以前からの問題かよく分からないが、ST6E の電源が落ちなくなっている。Win2k でシャットダウンや再起動を選択すると、設定保存中のメッセージが消えたあとでハングアップしてしまう。困ったことに、電源ボタンを長押ししても電源が落ちない。また、リセットボタンを押してもハングアップしたままである。復帰させるには電源ケーブルを１回引っこ抜かなければならないという非常に困った状態になってしまっている。
EXDAP512 の電池の持ち時間をもう一度調べてみた。900mAh で 7時間持った。まあ、こんなものか。
久しぶりに http://www.t13.org/ を見てみたら、ATA/ATAPI-8 のドラフトが公開されていた。IDENTIFY DEVICE コマンドに関しては、ATA/ATAPI-7 とはまだほとんど変わっていなかった。
PC-98 用の sys.com, format.com の中にある IPL について調べてみた。Win95 の syscom, format.com には 3個の IPL が、Win95 OSR2, Win98SE の sys.com, format.com には 4個の IPL が入っていた。IPL コードのサイズは、1024bytes, 2048bytes, 512bytes, 1536bytes の順になっていた。IPL コードを調べてみたところ、順に、FD 用 (FAT12)、IDE HDD 用 (FAT16)、SCSI HDD 用 (FAT16)、FAT32 用になっているように思われる。
この前買った、USB・シリアル変換ケーブルを CF-R2C で使ってみた。CF-R2C と La13 をクロスケーブルでつないで、ハイパーターミナルを使ってみたところ、115.2kbps でも問題なく通信できることが確認できた。
次に、USB・シリアル変換ケーブルを使ってカーネルデバッガが動くかどうか試してみることにした。La13 で以前と同じように、wdeb98.exe を動かして、CF-R2C で rterm98.exe を動かしてみた。しかし、どういう訳か、Rterm98 が見つからないとのエラーが出てしまった。速度を、9.6kbps, 19.2kbps, 115.2kbps の３通りで試してみたが、いずれもダメだった。もしかして、rterm98.exe が NT 系では動かないのかと思い、Ls312@Win2k で rterm98 を動かしてみたところ、一応動いた。（設定によっては rterm98.exe が落ちてしまうこともあったが・・・。） USB・シリアル変換ケーブルの問題なのか、それとも、rterm98 は WinXP では動かないのか・・・。いずれにしても、USB・シリアル変換ケーブルを買った最大の目的は、カーネルデバッガを使うことだったのに、それが使えなかったのは非常に残念である。
TeX から PDF を作成する方法に関して少し調査。
まずは、以前調べた用紙サイズの設定等に関して再調査。dvipsk + Distiller で PDF を作る際には、まず、「PDFの作り方」にしたがって、Distiller の設定を変更しておくのが良い。とりあえず、用紙サイズを 21.0cm x 29.7cm (A4 size) に変更したジョブオプションを作っておくと良い。ジョブオプションを変更しない場合には、「dvips の用紙サイズ指定」にある方法で用紙サイズの指定ができるが、ちょっとややこしい。現在のバージョンの \usr\local\share\texmf\dvips\config\config.ps には、
@ a4size 210mm 297mm @+ %%PaperSize: a4 @ a4 210mm 297mm @+ ! %%DocumentPaperSizes: a4 @+ %%BeginPaperSize: a4 @+ a4 @+ %%EndPaperSize
といった記述がある。以前のバージョンでは、a4 コマンドがコメントアウトされていたが、現在のものではコメントが外され、有効になっている。したがって、現在のバージョンであれば、dvipsk に -t a4 オプションを付けて実行するだけで、Distiller で生成する PDF は A4 サイズになってくれる。一方、
\documentclass[papersize,a4paper]{jsarticle}
というように、TeX のソースファイルで用紙サイズを指定した際には、"@ a4 210mm 297mm" ではなく、"@ a4size 210mm 297mm" の方が有効になってしまうため、PS ファイルには a4 コマンドは書き込まれず、"%%PaperSize: a4" というコメントが出力されるだけになってしまう。そこで、
*@ a4size 210mm 297mm *@+ %%PaperSize: a4
というように行頭に * を付けてこの２行をコメントアウトしてしまえば、papersize,a4paper オプションで用紙サイズを指定するだけで、Distiller は A4 サイズの PDF を出力してくれるはず。・・・といろいろ書いてみたが、やはり、Distiller のジョブオプションで用紙サイズを変更してしまうのが一番簡単そうな気がする。一方、dvipsk + Distiller の代わりに、dvipdfmx を使う場合には、papersize,a4paper オプションを指定するだけで、A4 サイズの PDF を出力してくれるようだ。
hyperref パッケージを使ったときに、dvipsk でハイパーリンクが使える PS ファイルを出力するには、-z オプションを指定すればよい。一方、dvipdfmx では特にオプションを指定しなくてもハイパーリンクは有効になる。
> dvipsk -P pdf -z foo.dvi
次は、画像を含む TeX ファイルを PDF にする方法についてまとめてみた。
ベクトル画像に関しては、EPS 形式にしてしまうが最も良いだろう。dvipsk, dvipdfmx のいずれでも扱えるし、dviout でも表示可能である。
ラスタ画像（ビットマップ画像）に関しては、dvipsk の場合は、EPS 形式に変換しないと使えない。一方、dvipdfmx では、PNG, JPEG なども使える。（PNG, JPEG は、dviout + Susie Plug-in でも表示可能である。） ただし、PNG, JPEG などを使う場合には、ebb コマンドなどを使って *.bb ファイルを出力しておく必要がある。dvipsk, dvipdfmx, dviout のいずれの場合でも、\includegraphics{} で画像ファイルの拡張子を省略した時には、適切な拡張子を勝手に補ってくれるので、拡張子は省略しておいた方が互換性が高くなる。ちなみに、
\usepackage[dvipdfm]{graphicx,color}
というように、dvipdfm オプションを指定したとき、同じ名前の EPS ファイルと PNG ファイルがある時は、PNG ファイルの方が優先され、
\usepackage[dviout]{graphicx,color}
というように、dviout オプションを指定したときは、EPS の方が優先されるようである。dvips オプションを指定したときは、PNG はそもそも使えないので、EPS の方が使われる。
PNG 画像と、PNG を EPS に変換した画像では、EPS に変換した方がサイズが大きくなる。そのため、dvipdfmx で PDF に変換する際には、EPS よりも PNG を読み込むようにした方が、サイズ的に有利になるようである。
dvipsk + Distiller でラスタ画像入りの TeX を PDF に変換すると、ラスタ画像の解像度が Distiller のジョブオプションで指定された解像度に落とされてしまう。CJKScreen (Distiller 5.0), Smallest File Size (Distiller 6.0) などのジョブオプションで出力してしまうと、画像によってはかなり見た目が悪くなってしまうので注意が必要である。
EXDAP512 の FM ラジオの周波数帯の設定が・・・。選べるのは、
の３通りなのだが、日本の FM ラジオだと、大抵は 76〜108MHz が聞けるようになっているはず。しかも、3. を選択したはずなのに、オートパワーオフで電源が落ちてから再度電源を入れてみると、1. の設定に戻っていた。さすが韓国製。
ツクモに行ってみると、EXDAP の予備の USB ケーブルと、イヤホンが売られていた。ケーブル \200、イヤホンは \380 だった。とりあえず予備の USB ケーブルを１本買っておいた。
EXDAP512 の体積は Hyper-Hyde より小さいことが判明した。Hyper-Hyde は 54 x 45 x 16[mm] で 38.88 cm^3、EXDAP512 は 65 x 38 x 13[mm] で 32.11 cm^3 である。
とりあえず、少し使ってみたところ、いくつか気になる点が見つかった。まず、付属のイヤホンだと音が少しこもっているような感じがした。ディレクトリをまたいだ連続再生ができないというのも問題だ。連続再生ではカレントディレクトリにあるファイルしか再生してくれない。別ディレクトリのファイルを再生したい場合は、一度停止してからそのディレクトリに移動しなければならない。せめて下層のディレクトリも連続再生してくれると良いのだが。ちなみに、曲の再生順はディレクトリエントリの順のようだ。好きな再生順にしたい時は、その順にファイルをコピーしていけば良さそうである。内蔵メモリのフォーマットは、FAT なのだろうか。WinNT 系に対応したディレクトリエントリ並べ替えソフトがあれば、簡単に曲順が変更できるのかもしれない。M3U リストに対応していれば、曲順の変更はもっと簡単なのだが、M3U リストには対応していなかった。また、オートパワーオフで電源が切れた時は、再生していたディレクトリが保存されず、次に電源を入れた時は、１つ前のディレクトリに戻ってしまうようだ。
J2SE 1.4 では、インストールすると Java Web Start というアイコンがデスクトップとスタートメニューに登録されるのだが、J2SE 5.0 ではそれが登録されないことに気付いた。一応、C:\Program Files\Java\jre1.5.0\bin\javaws.exe を実行すれば、Java Web Start は立ち上がるが・・・。
現在使っている MP3 プレイヤーは、Hyper-Hyde なのだが、32MB の MMC を 2枚、合わせて 64MB までしか使えない。しかも困ったことに、I-O DATA 製の MMC しかまともに使えない。そろそろ新しい MP3 プレイヤーが欲しいと思っているのだが、なかなか良いものが見つからない。とりあえず、条件としては、
といったところである。まず、今使っているものより大きくなるのは許せない。しかし、Hyper-Hyde 並の小ささの製品は意外と少ない。2. に関して、128MB では明らかに少なすぎる。また、最近はメモリ内蔵型がほとんどだというのが非常に残念なところである。3. は、単４ならば電池が切れても交換するだけでよいが、内蔵型だとそうはいかないからである。また、単４ならば Hyper-Hyde と同じなので今まで使っていた NiMH 電池がそのまま使えて都合がよい。
ツクモでツクモオリジナルの MP3 プレイヤーが売られていた。サイズは Hyper-Hyde とほぼ同じ。電源は単４。メモリ 512MB 内蔵のもの (EXDAP512) で、\15,980 である。しかも、タイムセールで 5% 引き。Junk 氏にも背中を押されて、買ってしまった。
帰ってから、EXDAP512 をチェック。USB 接続コネクタがミニ B コネクタではなく、独自のものだった。接続ケーブルをなくしてしまったら終わりである。ちゃんと規格で定められたものがあるというのに、なぜそれを利用しないのか、大いに疑問である。付属のソフトは、カードサイズの CD-ROM に入っていた。マニュアルも CD-ROM の中に PDF 形式で納められていた。一応、マニュアルは日本語だったが、不思議な表現が多数あった。さすが韓国製。
NT4 をインストールしたマシンを引っぱり出してきて、Win9x 対応版 cko が動作するかを確認する。無事動作した。これなら、Win95 でも動くのかもしれない。しかし現在手元に Win95 がインストールされたマシンはないので、動作確認ができない。
Firefox 1.0 をインストールした。bsscroll と pageinfo は問題なく動作した。
公開から既に１ヶ月以上経っているが、ようやく J2SE 5.0 をインストールした。とりあえず JF を動かしてみたが、問題なく動いている模様。Swing コンポーネントの外観が変更されていた。
1.4.2_03 の時と同じように、ファイルのタイムスタンプがインストールした日時になってしまった。
Win9x 対応版 cko が NT4 では動作しないコードになっているのに気付いたので、少々修正。ただ、それ以外の部分が NT4 でも問題なく動くのかがちょっと分からない。
ck の作者のお言葉。背景と同じ色で書かれていて、そのままでは見えないようになっている。まあ、言いたいことはいろいろあるが・・・。とりあえず、Win2k/XP が Win98 並の軽さなら、あるいはせめて NT4 並の軽さなら、Win9x を捨てるという選択肢は十分にあり得るが、そうではない以上そのような選択肢はあり得ない。もちろん、Win2k/XP がまともに動かないような古いマシンは捨てるべきという意見は聞く価値すらない。
CF-R2C で Mozilla などを使っているとかなりスワップが発生するので、少し前からメモリを探していたのだがなかなか安いものが見つからない。PC2100 だと新品で 2万近く、中古でも 1.5万ほどしている。ふと気が付いて神和電機に行ってみると、神和オリジナルの PC2700 Micro-DIMM 256MB (MDD333-256M) が \7,350 だった。512MB は \13,965 となっていたが品切れだった。R2C は 512MB には正式対応していないし、それほどいらないだろうと思い、256MB を購入。
少し使ってみたが、スワップが減ってかなり快適になった。しかし、これだけメモリを積まないと快適に使えないとは・・・、世の中間違ってる。
久しぶりに秋月電子へ行ったら、\1,400 の USB→シリアル変換器があった。ずいぶん安い。CF-R2C には RS-232C インターフェイスがないのが不便だと思うこともあったので、買っておいた。
千石の 2号店がオープンしていた。1.0m の D 端子ケーブルが \790 で売られていた。かなり前に秋月で買った時ほどではないが結構安い。98note 用の RS-232C 変換ケーブル用に良さそうだ。（参考：2004/01/23）
以前の内容を再検証してみた。OS は、Win2k SP4。
まず、標準の状態では、MO への遅延書き込みは有効になっている。この状態では、キャッシュの内容が書き込まれるまでは、イジェクトボタンを押してもディスクは排出されない。しかし、標準でリムーバブルメディアへの遅延書き込みが有効になっているのはどうかと思う。
次に、遅延書き込みを無効にしてみる。やり方は、「デバイスマネージャ」→ 「ディスクドライブ」→（MO ドライブを選択）→「ディスクのプロパティ」タブ →「書き込みキャッシュを有効にする」のチェックを外せばよい。この状態で、MO への書き込みを行ってみたところ、やはり以前と同じように遅延書き込みは無効にはなっていなかった。しかも始末の悪いことに、書き込みが終了する前でも、イジェクトボタンでのディスクの排出ができてしまった。最終的に書き込みが行われるまでの間に、イジェクトボタンを使ってディスクを取り出し、別のディスクに入れ替えてしまったら、ディスクの内容が破壊されてしまうのは明らかである。エクスプローラで MO ドライブを右クリックし、イジェクトを選択すれば安全に取り出すことはできるが、はっきり言って面倒である。何とかならないものだろうか。
WinXP の初期版でも同様の問題があったようだが、SP1 で修正されたらしい。ちなみに、WinXP での遅延書き込みの on/off のやり方は、Win2k とはちょっと違っていて、「デバイスマネージャ」→ 「ディスクドライブ」→（MO ドライブを選択）→「ポリシー」タブ で、「クイック削除のため最適化する」を選べば off、「パフォーマンスのために最適化する」を選べば on になる。
先月の spam メールの集計結果。着信拒否になった spam が少なくとも 5117通。着信拒否にならなかった spam が 409通。そのうち Spam Mail Killer で削除できた spam は 394通(96.3%)。誤削除が 2通ほど。先月はしつこい日本語の spam があった。(200410.txt) 最初は Spam Mail Killer も、Mozilla Mailer の Junk Mail Filter もすり抜けてしまっていた。文字コードが "SHIFT_JIS" と指定されているのが特徴的だったので、"SHIFT_JIS" なメールはばっさり削除することにしてしまった。
このところ CF-R2C のバッテリーの持ちがずいぶん短くなっていたように思っていたのだが、１つ思い当たることがあった。バッテリー使用時のバックライトの輝度を最高値に設定していたのである。ちなみに R3 は、半分の輝度で 9時間、最高輝度で 6時間程度持つらしい。そういえば、いつの間にか Let's note の冬モデルが出ていた。最近チェックしていなかったので気付かなかった。