日記みたいな何か

入れてみました．とりあえずuim.elは普通に動いてくれる模様．

いまさらですが，32bit版XP大復活 (手元にあったことを再発見しただけですが) ってことで，XRGB-3のファームウェアを2007年9月25日版に上げてみました．超半年遅れ．

このバージョン，FPGAのコンフィギュレーションを切り換えると デジタル・トランスコーダー & ラインダブラー・モード が使えるんだそうで．「液晶ディスプレイの多くの機種では表示できません」とマニュアルに書いてあったんですが，ダメ元でサターンをつないでみたら (というか元々つなぎっぱなしだったので電源入れただけですが)，いつものシャープの液晶(LL-T19D1-B)にあっさり映ってくれました．

せっかくなので，(ジャンクで買って開封もせずに棚に突っ込んだままだったものとかの動作テストも兼ねて) 手元にあった15kHz RGBが出せるものを一通り試してみました ．さすがに全勝とはいかなかったものの，なかなか．すごいじゃん，LL-T19D1-B．あ，でもこれ，モニタ側で拡大切れないのか．だめじゃん．あと基板がダメだったのがかなり残念．

マニュアルにも書いてありましたが，メガドライブのみ制御信号とやらが画面下に出てますね．ソフトによるのかもしれませんが・・・．にしても，×なのは，何が原因で×なのか気になりますね．やっぱ同期信号まわりなんですかねー．何か挟んで直せるもんなら直したいところですが・・・．ローパスフィルタかましてXMD-2通すようにしたりしたらうまくいったり・・・しないかなぁ・・・．

※ 映像が出たのはSG専用ソフトのバトルエースのみ．ただし，画面がぶるぶる震えているような状態．普通のHuカードは一切映像出ず (´・ω・｀)

で，サターンで起動したついでに今日もグラIIで遊んでみました．クリスタルコアにガチで挑んで勝てたのはいいんですが (モタモタしてたらオプションハンターに3個も持っていかれたけどorz)，デスMk-IIでオプションめり込ませてみようとしたら撃沈．普通に挑むんだった・・・．

心なしか反応がよく，遊びやすかったような気もしますが，まあ多分気のせいでしょうｗ

上ですごいじゃんとか言ってますが，最近突然つかなくなったり，ついてるのに映像が出なくなったりすることが何度かあって，微妙に不調です．昨日は裏の主電源電源何度も入れ直したら復活したけど・・・．

MDT242WGかなーと思ってたんですが，やっぱあの枠がなぁ(笑)．となるとHD2441Wか・・・？

Fedora7 上でビルドした w3m だと Twitter が表示できるのはなぜか・・・．手元のユーザ環境だとだめぽ．まあ現状特に困ることとかないんでいいんですが・・・．

2時間かけて行って3時間くらい飲んで2時間かけて帰ってきました．遠いよー．キング先生が既に軽く出来上がっていて，何でか知らんけど色々苛められたような気がします (;´Д`)

今日もグラIIやってます．1面でコースを決められなくてうろうろしているうちによく死にますｗ．2面はとても安定しているのに・・・．で，3面もだいぶ慣れてきたんですが，やっぱ破壊できないクリスタルがふよふよしてるところ辺りから終盤まで超緊張．そしてクリスタルコアが全然ダメっす・・・．

2回ほど勝てたんですが，どっちも1回ミスして，その後ほぼ何も装備していない状態で目の前の安置に潜り込んで撃破というパターン(笑)．フル装備だと安置にうまく入れないのは3速だから？

4面は初回は瞬殺だったんですが，2回目はほぼすっぴんからそこそこ復活し，そのまま後半突破→デスMk-II撃破という奇跡のビギナーズラックで突破．ほとんど全部初見だったんですが，よく抜けられたなーと・・・．もう当分抜けられんだろうなぁ・・・．そしてそのまま5面でモアイが赤くなるあたりまで頑張ったんですが，ハッチから出てきた雑魚の弾に当たってしまい，復活もできずに終了となりました・・・orz

bugzillaキター．今後の展開に注目．

T42にMTVX2006USBをつないでみたんですが，音は出るものの画面がまったく出ず．あれこれ試してみたところ，2005モードにすると出ることが判明．FAQから察するに，どうやら2005モードだとDirectDrawのオーバーレイで表示するようになるらしく，2006モードのDirect3Dでの表示だとT42のビデオチップ (確かRadeon Mobility 7500) ではうまくいかないということか？・・・ってこれじゃあVHScrCapで拾えんぞ (;´Д`)

どうにかならんかとあれこれググってみたら，Omega Driversなんていうドライバを発見．とりあえず Mobility Radeonにも対応していそうだったので，ダウンロードして入れてみたところ・・・2006モードだとウィンドウすら出なくなってしまいましたorz．そしてディスプレイまわりの各種設定を弄っている内に，気づけば2005モードでも何も出ない状態に．dxdiag で確認してみたら，DirectDrawもDirect3Dも無効になっとるし (;´Д`)

どうにもわからん状態になってしまったので，仕切り直しということで，一旦ディスプレイアダプタのドライバをロールバックしてみることに．今まで一回も使ったことなかったんですが，普通に前のドライバに戻ってくれたみたいです．へー．そして，再起動したら2005モードで画面が出るようになりました．ふぅ．

で，この状態で2006モードにするとなんにも出ないわけで・・・って2006モードでも映っているぅ！ い，一体どういうことだ・・・．そのまま VHScrCap で普通に取り込めてUstreamに流し込めました．というわけで，結論としては，なんだかよくわからないけどやぱり T42 で MTVX2006USB は使えるらしい．いやー，何がどう直ったのかさっぱりですが，まああっさり諦めなくて良かったってことで．

昨日ぐらにどっとこむさんの動画を見てたらやりたくなって，サターンをつけてやってみました．・・・クリスタルコアで終了 orz．もうどうしようもなく下手だ ＿|‾|○

いやしかし3ボスで終わってる人が何を言ってやがるって感じですが，今やっても普通に面白いというか，古さをさほど感じないのがすごい．20年前からこの水準のゲームが存在していたんだなぁ．とりあえず1周ぐらいはしたいものです．頑張ろう・・・．

歯医者行って，前に削ったりしてもらったところの型とったりしたんですが，最後に「何か」を対象の歯とその周辺にぎゅうぎゅう練り込まれました．何かキャラメルがひっついてるみたいで超非常に気になる・・・というか，来週半ばまで耐えられるのかこいつは・・・．

Windows版のPidginの oscar (AIMとかICQのプロトコル) では，ユーザの入力したUTF-8な文字列を UTF-16BEに変換する前に，まず ISO-8859-1 に変換できるか試します．これで変換できたら1byte文字で送ったりするわけで，多分常にUTF-8で送るよりは多少は効率的とか，そんな感じなんでしょう (oscarでは非Latin1な文字はUTF-16BEで送るらしいので)．

で，Windowsだと，上記の箇所で，全角記号や全角英数字までもが UTF-8 から ISO-8859-1 へ変換できてしまい，しかもその際勝手に半角に置き換えられてしまう・・・というのが今回の問題．上の方でworkaroundを仕込むのもいいんですが，気持ちが悪いのでどうにかできんかと，yazさんを無理矢理巻き込みつつ原因を追ってみました．以下，わかったことと推測されることの要点．

• g_convertを呼んで UTF-8 の全角アルファベットをISO-8859-1に変換するだけのコードを書いてテストしたところ，Linuxでは g_convert に失敗するが，Windows上でPidginについてきた Glib とリンクさせると成功して半角アルファベットになった．Pidginが変なことをしているわけではない模様．
• GNU libiconvには，変換先の文字コードに「ISO-8859-1//TRANSLIT」のように「//TRANSLIT」をつけると，前述のような挙動になる機能があった (libiconvのソースのlib/translit.defを見てみよう)．
• Windows版のPidginと一緒に入るGTKのGlibは，なんと GNU libiconvを使っておらず，代わりに win_iconvというのを利用している模様 (libglib-2.0-0.dll を objdump -d して確認)．glib-2.16.1 のソースを落として中を見てみたら，普通に win_iconv 入ってるのね．
• win_iconv は，Windows のAPIを呼び出してlibiconv互換のAPIを実現しているっぽい．多分 UTF-8 から ISO-8859-1 に変換する際には，WideCharToMultiByte が呼ばれることになる．
• WideCharToMultiByte は，デフォルトで「TRANSLIT」的な動作をするようで，2個目の引数に「WC_NO_BEST_FIT_CHARS」というフラグをつけるとこれを防げるらしい (ここに書いてある「WC_NO_BEST_FIT_CHARS」の説明だと逆なように見えるのでいまいち確証が持てませんが)．
• Glib内蔵の win_iconv のソースを見ると，2個目の引数に0が突っ込まれていた．外からいじれないっぽい (´・ω・｀)

というわけで，アプリの側からどうこうできるような問題じゃないっぽいというのが結論でございます．これだけ書くとすごくあっさりここにたどり着いたように見えますが，どこで問題が起きているのかなかなか見抜けず，半日ずっとこればっかやってました ＿|‾|○

で，既存のコードを尊重するなら，以下のようなパッチが良さそうです．ISO-8859-1に変換できたとしてもすぐに結果を信じずに，再変換してサイズが同じだったら初めて信じる，みたいな．

--- /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c.old
+++ /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c
@@ -551,7 +551,19 @@
 	 * XXX - We need a way to only attempt to convert if we KNOW "from"
 	 * can be converted to "charsetstr"
 	 */
-	*msg = g_convert(from, -1, charsetstr, "UTF-8", NULL, &msglen, NULL);
+	*msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);
+#ifdef _WIN32
+	if (*msg != NULL) {
+		gchar *msgr;
+		msgr = g_convert(*msg, strlen(*msg), "UTF-8", charsetstr, NULL, NULL, NULL);
+		if (msgr == NULL || strcmp(msgr, from) != 0) {
+			g_free(*msg);
+			*msg = NULL;
+		}
+		if (msgr != NULL)
+			g_free(msgr);
+	}
+#endif
 	if (*msg != NULL) {
 		*charset = AIM_CHARSET_CUSTOM;
 		*charsubset = 0x0000;

古いクライアントなんてクソ喰らえなら，こんな数byteをケチるためのコードとはとっととお別れしてUTF-16BEで統一すべきですね(笑)．って，ICQはそれで平気なんだっけ？