日記みたいな何か

Anthyの中の人が優勝したCellのアレのソースが公開されてました．うちのはまあ適当に探してください．パターン作って一部でハイスコア叩き出したけど最後で予定外の発狂に対応しきれず1周できなかったみたいな感じな名前と結果ですｗ

yazさんから新しいパッチを頂きました．何か色々マージして頂けました．どうもです．

メモリも増えたことですし，久々に起動してみることにしました．カーネルモジュールを作り直していざ起動してみると，バージョンが上がっているとのメッセージが．早速新しい方(5.5.4-44386)を落として入れてみようとしたわけですが，例によってカーネルモジュールのビルドで失敗するんでany-any-updateの力を借りることに．

ftp://ftp.cvut.cz/vmware/から最新と思しきvmware-any-any-update109を落としてビルド．・・・が，VMwareを上げると，バージョンが合わないと言って動いてくれません(´・ω・｀)．何か109で入るバージョンは古い模様ですなぁ．確かにファイルの日付見るとちょっと古そう．あれー．

みんなはどうしているんだろうとググってみたら憩いの場にて情報発見．ぬ，5.5.4-44386でもany-anyで普通にできるのか・・・．ってことはany-any自体が古い？ vmware-any-any-update でググってみたら，さっき見たのとは別のhttp://platan.vc.cvut.cz/ftp/pub/vmware/なんてサーバが出てきて，こっちには vmware-any-any-update110 という新しめのが・・・．なんて罠だ．こっちでバッチリでした．

そういえば最近のLinux版のVMwareではExperimentalながらDirect3Dが使えたりするらしいですが，前試したときはビデオチップがMobility Radeon 7500でATIのドライバが使えずちゃんと動かなかった・・・ような気がします．が，今のT60はX1300を積んでいて，ATIのドライバも入っているわけで，実はDirect3Dいけちゃうんじゃないの？

というわけで，再び挑戦してみました．vmxファイルに以下の3行を追加して，いざVMware起動．

mks.enable3d = "TRUE"
svga.vramSize = "67108864"
vmmouse.present = "FALSE"

dxdiagを実行してみたところ，立方体がグルグル回転しました．この環境でもDirect3Dはいけるみたいですな．

で，試しに何かゲームも動かしてみようと思い，東方風神録を起動してみました．結果は・・・読み込み画面からタイトル画面までは正常です．が，ゲームが始まると大変なことに(;´д`)．ちなみに，何度か試しましたが，何度もOSごと固まってくれたりしてかなり危険ということがわかりました(笑)

結局のところ，Windows側のlibiconvがISO-2022-JP-MSに対応してないのが悪いわけで，パッチを当てて対応させたiconv.dllをPidginと一緒に配布すればいいだけの話なんではないかということに気づきました．

というわけで，libiconv-1.9.1にパッチを適用してMinGWで普通にconfigureしてmake・・・が，makeでこけます．ググったら1.9.2だとうまくいくという情報が出てきたので，1.9.2と何が違うのかと思って見てみたら，1.9.1の方には↓が無かったり．この辺足したら通りました．

#if defined _WIN32 || defined __WIN32__
# define WIN32_LEAN_AND_MEAN
# include <windows.h>
#endif

が，make installしてもiconv.dllはできず．これってもしかして手で作らねばならんのか？ 調べてみたら，ここに説明がありました．MinGWのツールで普通に手で作れるのか．で，これをやるためにはdefファイルというのが要るみたいなんですが，これをどうやって作ればよいのだろうか・・・と彷徨ってたらこちらでナイスなツールが紹介されていました．

./tiny_impdef.exe 'c:\cygwin\home\nosuke\compile\pidgin\gtk_installer\gtk_install_files\bin\iconv.dll'

のように既存のiconv.dllを食わせてやったら iconv.def とか適当なファイル名でdefファイルを書き出してくれました．素晴らしい．これを使って↓のような感じで手リンク．

dllwrap -k -def iconv.def --driver-name gcc -o iconv.dll \
 ./lib/.libs/iconv.o ./lib/.libs/localcharset.o \
 ./lib/.libs/relocatable.o

iconv.dll ができました．よし早速置き換え．・・・あれ，ISO-2022-JP-MSが出てこねーぞ？EUC-JP-MSはあるみたいだけど・・・．ぐはっ，ISO-2022-JP-MSが出てきたのは1.10からか・・・．

そんなわけで，今度はlibiconv-1.10にパッチを当てて作り直し．手順はまったく同じで，普通にiconv.dllができました．Pidginと一緒に入るGTKのを置き換えてやったら，ばっちりISO-2022-JP-MSが指定できるようになり，IRCで半角カタカナとか「〜」とかが化けなくなりました．次からはこれをWindows版のPidginに同梱するのが良さそうですね・・・．

チャットルームの一覧も文字化けするんだそうで．なるほど，確かに文字化けしている・・・．パケットキャプチャして確認してみたところ，「0x1B 0x28 0x42」の後に，0xCFとか0xBBとか，ASCIIじゃないコードが混じってるところが化けてますな．ひでえなこのESC(B．

とりあえず，ASCIIであると主張しているところを次のエスケープ文字までを抜き出して，そこをSJISとしてISO-2022-JP-2に変換してつないでいく手抜き対処をしてみたところ，一応この部分の文字化けは解消しました．が，結局ISO-2022-JP-2じゃ対応できない部分が他にもあったりして，やっぱ他の手を考えた方が良さそうな感じ．どうしたもんか．

おぼの君他いつものメンバー(±1)で集まってうちで焼肉しました．微妙に風邪気味でピンチ．なぜかおぼの君がグラVとかドラブレとかやってました．ほんと弾避けの能力がすごい．

時間ができたので久々に秋葉原へ行ってきましたよ．行く途中，朝ご飯がよくなかったのか山手線で超気持ち悪くなって危機的状況に(;´д`)

T60用のメモリ，RAP2の交換用レバー，工具，部材などを購入．うろうろしてるうちにだいぶ体調も回復してきたので，いつものように中古ゲームもチェック．トレーダー覗いたら何かサターン用のジョイスティックのジャンクが300円で売られてたので，部品取りにでも使えればと購入してしまいました(笑)

で，最後にHeyに立ち寄ってむちむちポークやって帰ってきました．むちポって，難易度超低めなんですかね，初見で4面まで行けてしまうなんてとても珍しい・・・．雷電IVは超難しそうだったのでパス・・・．

早速買ってきたメモリに換装してみました．2Gになって(゜Д゜)ウマー．特にディスクキャッシュがかなり効いてくれるのがありがたい．あとこれでVMwareを割と気兼ねなく上げられます．

元々ついてたサンワのJLF-TP-8Yを外して，代わりにセイミツのLS-32-01をつけてみました．余ったサンワのレバーもどっかで使えればと，秋葉原でサンワ用の8角ガイドとハーネスを買ってみたんですが，ハーネスはまったく同じ物がLS-32-01にも付属していてややショック．

で，交換してみた感じですが，何か気持ちレバーが短くなったような気が．いや，気のせいか？ドラブレやってみたらまた6面まで行けました．ここ数日で一体何が・・・．

何かWikiの方にIRCで半角カタカナが文字化けするという情報が・・・．うーん，IRCねぇ・・・．普段使ってないだけに，モチベーションが全然上がらないわけですが．自分がPidginの中の人だったら放ってはおけないけど，超外の人だしなぁ・・・といつもなら「そのうち」とかいって放置するところなんですが，うっかり戯れに追ってしまいました．

以前テストでIRCサーバをインストールしていたことを思い出し，ポートを開けて起動．で，早速LinuxとWindowsでPidgin上げて，Pidgin間で通信してみたんですが，全然化ける気配なし．あー，デフォルトだとエンコードがUTF-8なんだっけ．というわけで，ISO-2022-JPにしてみましたが，やっぱり化けないぞ．何だこれは？

再現条件が全然書かれて無かったんですが，まあきっとISO-2022-JPで発言したときに，Winodwsの他のクライアントだと文字化けしてしまうんだろうとにらんで，一番使われてそうなLimeを入れて実験．・・・おお，化けた．半角カタカナがことごとく化けますな・・・．

wiresharkでパケットをキャプチャしてみたら，半角カタカナが混じるとISO-2022-JPっぽくないバイト列が送られている模様．デバッグウィンドウを開いたら，「文字コードの変換に失敗した」みたいなメッセージが出ますわ(;´д`)．で，ソースを見てみると，g_convertでUTF-8から指定したコード(この場合ISO-2022-JP)への変換に失敗したら，そのままUTF-8で送るみたいな感じになってました．スゴス．だからPidgin同士だと化けなかったのかぁ．

では何でg_converが半角カタカナを処理してくれないのかという話ですが，Wikipediaに色々書いてありますな．なるほど，そもそも ISO-2022-JPについて書いてあるRFC 1468に，JIS X 0201のカナを含まないぜと記されてるのね．その辺をlibiconvとかglibcがきちんと守っているからダメなわけか・・・．というわけで，結論としては「ISO-2022-JPを指定した以上，半角カタカナを使うんじゃない」となるわけですが，そんなコチコチ頭的考えは嫌なのでもうちっと追ってみました．

とりあえず手元のLinuxではglibはlibiconvを見ていて，libiconvにはCP932絡みのパッチが当ててあります．「iconv -l」とやったら「ISO-2022-JP-MS」なんてのがありました．これをPidginで指定してみたところ，変換失敗のデバッグメッセージが出なくなり，何とLimeでも化けずに表示されるようになりました．ということは，LimeはISO-2022-JPと見せかけて「ESC ( I」に対応しているのか？ まあいいや，これにて一件落着・・・．

というわけにはいかなくて，肝心のWindows版の方では，libiconvにパッチ何か当たってないので「ISO-2022-JP-MS」を指定しても変換できんわけです (´・ω・｀)．じゃあ，何を指定すれば・・・？ 試しにISO-2022-JP-2を設定してみたらいきなり成功．Windows版Pidgin → Lime で半角カタカナが通りました．でも，これをやると，今度は「〜」が化けます．もしかしてと「¬」を試してみたら，こっちも化けました．さらに外から「〜」を打った場合，WindowsのPidginだけフォントが汚くなります．あれか，WindowsのUnicodeのアレ．

というわけで，Pidginのlibpurpleのircのところにでyazさんの関数呼ぶようにして，送信時と受信時にUTF-8をいじるようにして解決させてみました．多分こんな感じ．ちなみに，現在のyazさんパッチでは，ircのソースに関して一切変更を加えてないようです．

しかし，ISO-2022-JP-2で半角カタカナがエンコードできるようになるのがよくわからんなぁ．ISO-2022-JP-2にはJIS X 0201のカナの方は含まれてないように見えるが・・・．そもそも無理やり変換することを考えるより，Limeと同じように，ISO-2022-JPのときはPidgin内部で半角カナ→全角カナの変換をやっちゃった方がいいのかも？