Denial Ain't Just a River in Egypt

久々にDICEの新バージョンをリリースすることが出来た。今回は互換性を破る変更もあったので、インクリメンタルに新バージョンをリリースするという以前の目標はひとまず措いて、必要な部品が全て入るまで待たざるを得なかった。ついでというわけではないが、自分のハンドルもKLからRyuKに変更した。KLでは短すぎるというのが主な理由だが、元のサイト名(KLassphere)をとある理由で変更したかったという動機が先に存在したかもしれない。そちらはryukwareへ変わっている。サイトのデザインもDICEのWeb UIで採用しているテンプレートを再利用して改装した。Webサイト自体も去年秋から新アドレスへ移転している。

実はこのページもいよいよblogツールで生成するように変更しようかと思っていて、去年初めに各種ツールを検討してみた。が、一番最初に触ってみたMovable Typeがあまりにダメダメだったのでこの案はそこで一旦棚上げになってしまった。ファイルを置いているサーバはMySQLが使えるので環境は問題ない。ただ自分としてはデータのXCOPY deploymentができるSQLiteを使いたい。SSHも使えるのでSQLiteのビルドも出来、そこまでは問題なかった。問題だったのは、肝腎のMTの管理者ツールが非常に使いにくいということだ。カスタマイズの際の独自マークアップも汚く、そんな下らない物を学習する気など毛頭無い。使える既成 テーマもろくにない。何故MTが最初の候補に挙がったかというと、オリジナルサイトから古い記事をインポートしたときに、記事の日付をオリジナルの物に変更したいという事があり、さしあたりそれが可能なのがMTであったというわけだ。いつか機会が有れば今度はWordPressを試してみようと思ってはいるけれどSQLiteを用いるのにこちらはこちらで手間がかかるようで痛し痒しである。

他人の作ったツールを使う場合の居心地の悪さというものはソフトウェアを書く際に利用するミドルウェアについてもしばしば感じることになる。オープンソースでソースコードとシンボルが手に入るならともかくそうでない場合は、いや手に入る場合であったとしても、分厚いミドルウェアの利用者はハッカーたることを強制されてしまう。その意味ではWindowsというものも巨大なミドルウェアであって、最近はMSDNのMicrosoft社員blogで様々な情報公開が行われていて助かることしきりである。しかし実態として見れば、不十分なAPIドキュメントあるいはAPIそのものについての補遺を非公式の場で行うことは現状を追認するエクスキューズでしかない。ミドルウェアによってもたらされる利益がある一方で、ミドルウェアを原因とするフラストレーションは相手がはっきりしているだけに顕在化しやすい。Windowsのような、選択の余地がないケースでは尚更である。

DICEについて言うと、今回からSSPIを使うのをやめてOpenSSLに切り替えた。もう1つの変更は逆方向で、これまで8年間C++を用いる場合は常にSTLportを使い続けてきたのをやめて、今回からVC++のC++ライブラリを使うように変更した。VS2005からSxSになってインストールが面倒になったにも関わらず、である。C++標準ライブラリの変更自体は、これまでデバッグの関係で両対応にしていたので何ら問題はない。STLportの利点 は、かつてVC6時代にあったiostreamやロケールのバグが修正されていたり、SGI STL譲りのhash_map、ropeといったコンテナ、それからmalloc呼び出しを抑えるノードアロケータ、さらに名称の由来である移植性などで ある。加えて、後年メインテナーが変更になって以来、iostreamのさらなる修正やbig fileサポート、組み込みプラットフォームサポート、ユニットテスト追加、basic_stringのスタティックバッファ、+=ではなく+でbasic_stringを繋げる場合の最適化、ノードアロケータのロックフリー化、など様々な改良が施されてきた。VC++添付のライブラリはDinkumwareという会社のOEMで、そこのP.J. Plauger氏(以前Cマガジンで連載があった)が去年だったかニュースグループでSTLportの状況をかなり口汚く大人げないスタンスで論難し、反論に遭っていたのを見たことがある。

STLportを捨てることを決めたのは、VS2008の機能リスト中に、STLとマネージド型のマーシャリングが自動的になされるといった.NET絡みの親和性を見つけて、これはもう避けられないと感じた事による。STLportを使っていると、他のC++ライブラリと併せて使った場合に問題が起こることが多く、その度に苦しめられたという問題に関しては、長年使ってきたという既成事実のおかげでどうにか切り抜けられてきていた。それでも、マルチコア環境でSTLportノー ドアロケータが実際は標準mallocに劣るというテスト結果(OSのヒープアロケータの薄いラッパーであるmallocの方がスレッドやスレッドローカルデータについてよく知っているのだから当たり前だ)や、VC++がC++例外のソースコードを提供していないせいでSTLportを使う場合もVC++のdllが丸ごと必要になるという問題は以前から不愉快に思っていた。ノードアロケータはユーザランドでのメモリリークになるが、引き替えにパフォーマンスが得られるならと思い許容していたにもかかわらず、実は期待した効果を得られていないというのは特にショックだった。また、DICEではそもそもiostreamを使っていないのでその部分でのSTLportの恩恵は全くない。

STLportをやめてみてまず最初に判明したのは、これまでIntellisenseが正常に機能しなかった原因はSTLportにあったということだ。てっきりLokiが問題なのだと思い込んでいたが、そうではなかった。当然、MSVCのC++ライブラリだとSTLコンテナやbasic_stringの中身もデバッガで易々と見ることが出来る。唯一勿体ないと感じるのはbasic_stringの最適化くらいだけれども、どうしても無ければならないという類の物でもない。むしろ、デバッガでbasic_stringの中身を見るときに一々スタティックバッファとダイナミックバッファの両方を見たりせずに済むようになって、せいせいした。unordered associative container (hash_map)も今後TR1絡みで動いていくだろうから変更にはいい機会だったと思う。

他方、VS2008には困ったこともあった。ATL属性が廃止になっていて、実はDICEのサービスはこれを使っている。しかし、実際に汚い物なので、廃止されるのもむべなるかなといったところである。今回のDICEは、こういったWindows世界での波風からできるだけ逃れるというのも一つのテーマになっていて、上記のMSVCのC++ライブラリへの回帰は残念ながらそれに逆行するが、このページの2006年11月30日の項で述べたWeb UIへの移行はついに達成した。Web UIでカバーしきれない部分は、これもMicrosoftの束縛の象徴であるMFCを使っていたDICEAdminShellを廃止し、DICE Managerという、機能を最低限に絞ったヘルパーアプリケーションをC#/Windows Formsで作って新たに入れた。2006年11月30日の項でも書いたようにMFCは本当に無茶苦茶で、DICEAdminShell廃止も MFCに直接起因している。VS2003からVS2005に移行したときにビルドし直したところ、実行ファイルがXPでは動くのにWindows Server 2003では動かないようになってしまったのだ。VS2008では驚くべき事にMFCがまだ残っていて機能拡張までされているそうだが、この辺で引導を渡してやっていた方が結果的に各方面が幸せだったのではないか。DICEの.NET WebアプリケーションコンテナもVS2005移行に伴って.NET Framework 1.1から2.0に移行し、マネージドコード部分に多少書き換えを要した。.NET Framework 3.5が2.0ベースであるのは賢明な方針である。

Web UIは、それなりに道具が揃うとかなり楽に作れる。今回は勉強を兼ねて、prototype.jsに代表される外部のAJAXライブラリは一切使わず、自前でフレームワークを 作った。どのみちIDEが無いのだから大して手間は変わらない。無意味にファットなライブラリに興味はなく、また標準ライブラリを書き換えてあったり、一 旦導入すると以降はそのライブラリのスタイルを強要されたりするのも煩わしい。道具の一つとして、PHPのSmartyのようなテンプレートエンジンを JavaScriptでXHTMLのカスタムタグとDOMを利用して作ろうと思ったところ、XML名前空間やxhtmlについてIEはIE7でもサポートがろくになされていないのがわかり、またFirefoxにせよapplication/xml+xhtmlが必要になるため、仕方なくspanタグを使って作った。もう一つテンプレートエンジン絡みで参ったのは、<p>などのブロックタグが実行時にJavaScriptによって他のブロックタグの内側に挿入されると、IEが「未知の実行時エラー」を出すことだ。勿論規格的には正しい動作だが、普段はエラーに寛容なIEらしからぬ振る舞いで、VSのデバッガでもよくわからない部分へ行くので、原因を探すのに苦労した。

今のところWeb UIは通常のwebページの外見で、Web IRCクライアントで利用したときにせいぜいタブインターフェイスをサポートするくらいだが、将来的にはWebデスクトップに必要なMDIをサポートできるように、ウィジェットクラスの階層を定義できたらと思っている。今回は、デモとして、管理者用にリモートファイルダウンロードマネージャを入れた。 GetRightやIrvineのようなダウンロードマネージャアプリケーションに似た機能をWebから利用できる。サポート機能はまだプリミティブで、ベーシック認証やリザルトコード302などはサポー トしていないが、HTTP/1.1のchunked encodingは完全にサポートしているので、Perl/Rubyで以前書いたツールのスーパーセットになっている。

Web UIについて書いていて今気付いたが、DICEに新しいライブラリをもう一つ導入している。メンバー登録時に表示されるCAPTCHAを、GDI+を使って実装した。今回Vistaを正式サポートした際に、諸々の理由でWindows 2000を動作環境から外したので、これが可能になった。とはいえGDIを使えば済む話でパフォーマンスもそちらの方が有利ではあるものの、GDI+は何かと楽である。オープンソースの画像ライブラリだと、最近はFirefoxなどで使われている、ハードウェアアクセラレーションが入ったCairoが一番有名だろうか。ただ、これも他のオープンソースライブラリの例に漏れずlibpngなどに依存しているので、環境を作るのに労力が要る。昔FreeBSD のサーバで使うC++の掲示板用にCAPTCHAを入れた時にはpaintlibというクロスプラットフォームライブラリを使っていて、これは2年前に開発中止になってしまっている。

さて、今後は、DICEについてもう一段さらにジャンプを予定している。それが済んだらようやっと頻繁にリリースを出来る環境が出来るのではないかと思う。ゲームの方は、かなりの長期間離れていた後に、最近UT3が出たので下手ながらたまにオンライン対戦をやっている。UT2004は時間の無駄遣いが恐ろしくなりアンインストールするほどにプレイしたので今回も期待していたが、若干物足りない。売り上げは残念な結果に終わっているのでいよいよPCゲームも(MMOとSteamで買えるゲーム以外は)終焉に至ったかと感慨深い。