やれやれやっとDICE 0.8の配布にこぎ着けることが出来て感慨深い。というくらいリリースが難航して結果約2か月も予定より遅れることになってしまった。その代わりと言っては何だが新しくWebサーバ機能も入り、かつ安定性も大幅に向上している(特にWindows XP/Windows Server 2003上)。「IRC/HTTP/opennapハイブリッドサーバ for MS Windows 2000/XP/2003」なんていかにも危なっかしい形容なのでIISのように簡潔な名称にしたいところではある。そこで私自身忘れていたのは、実はDICEという名前がその役目を果たすべきものであるにもかかわらず、未だに何故DICEという名前なのかどこにも由来を書いていないということである。今回も書かないのだけれども代わりにDICEに関する今後の方向性を示唆する物としてIFIRCでのインタビューを参照されたい(これも微妙に古くなってしまったが)。
»Read More
Devastationやってみた。一応最後まで行ったけれどもとんでもない駄作だった。Unreal Tournamentのエンジンを使ってるのはいいとして、画面の雰囲気が何となくHalf Lifeを思わせる荒さで汚く、ボットの動作もぎこちない。シナリオは無理矢理UTのTeam Matchをやらせるためにでっちあげた(特にReGen、これこそご都合主義の権化である)と言っても過言ではない代物だ。「HOTEL れしゃお貴族」のような壊れた日本語ネタには尽きないゲームではあるが本当にそれだけだった。おまけに久しくFPSで酔ったことはなかったのに(移動しな がらcrosshairsを標的あるいは消失点に固定し続けることが出来るようになればFPSでは酔わない)、何故かこのゲームに限って酔ったので最悪で ある。文字通り「むかつく」ゲーム体験となってしまった。今年はもうしばらくゲームをやらないと思う。
ところで、DICEバージョン0.22 – 0.5にはアセンブリによる中途半端な最適化によりPentium3で動作がおかしくなるバグがあったので、そのバージョンで正常に動作しなかった場合は今回の0.6を試して頂きたい。
DICEバージョン0.22配布開始。メンテナンスリリースで特筆すべきことは何もない。尚、DICE上での利用に問題があるIRCクライアント用スクリプトがある場合、ここにDICEから削除されているIRCコマンドのリストがあるので自力でスクリプトの方を修正して頂きたい。それらのコマンドは、主にセキュリティ上の理由からDICEでは意図的に省かれているものである。
さてUnreal IIである。3日かかってクリアできた。解像度は1280 * 1024 * 32bitを使用した。最初は1024 * 768に設定したが明らかに汚かったので既にこの解像度はゲーム向きではないらしい。GF4Ti以上のVGA + 2Ghz以上のCPUで満足にプレイできると思われる。(Doom IIIだとこれでは足らないらしいが)
»Read More
あけましておめでとうございます。
去年末からC#で.NETフレームワーク用のプログラムを書いている。開発環境のサポートが充実している点を割り引いても、まるでかつてPerlでスクリプトを書いたときに味わったような爽快感を再び味わうことができた。
年末の総括を忘れていたので今数えてみたところ2002年は8回このページを更新できたのでなかなか悪くない結果である。今年は6回と予想しておく。
一昨日DICE v. 0.21を公開したが問題が発覚したので0.211に差し替え。
さらに昨日公開したDICE v. 0.211にも微妙な問題が発覚したので0.212に差し替え。
DICE version 0.2 に凡ミスが見つかったので急いで修正&差し替え。結果的に別の部分まで手を入れることになったので慌ただしくリビジョンを上げた。あまり何回も見得を切るのは格好悪いので願わくばこれ以上問題が起こりませんように。
DICE version 0.2の配布を開始した。SQL Server/MSDEが要らなくなり、より一般的なユーザに身近になったと思われる。SQL ServerのデータベースからDICE ver 0.2用のデータファイルを抽出するツールも置いたので移行も簡単である。来年はDICEに手を入れる機会はほとんどないのでこれを完成版と呼んでも差し支えない。ナンバリングこそ0.2ではあるがユーザインターフェイスの不親切ささえ脇に置けばサーバアプリケーションとしての内容は1.0と呼んでも良いものに仕上がったと自負している。SQL Serverのおかげでインストールに二の足を踏んでいた方は0.2の完成度を是非動かして試して頂きたい。ついでにISAPIの掲示板ももう手を入れる余裕がないので、なし崩し的に配布することにした。
»Read More
1. はじめに
2. Windowsのマルチスレッド設備
3. 同期オブジェクトの保護対象
4. マルチスレッドの病理
5. マルチスレッドデバッギング – 実行時テストによる
6. マルチスレッドデバッギング – クラッシュダンプの分析
7. 広義のカーネルオブジェクトとしてのCRITICAL_SECTION
8 . おわりに
はじめに
Intel Corp.によるHyper-Threading Technology導入により、マルチスレッドアプリケーションがMicrosoft Windows®上で効力を発揮する機会がさらに増えることが予想される。Windowsにおける従来のメインストリームとしての、デスクトップでの個人利用を前提としたGUIアプリケーションでは、マルチスレッドといってもせいぜいワーカスレッドを作業の度に生成してシングルユーザに対するユーザイン ターフェイスの応答性を担保するといったきわめて局所的な利用に留まる場合が多かった。こうした、共有メモリの中での割り込みを主目的とするような限定的で単純な利用では、マルチスレッド固有の問題が生起する確率は当然低い。
»Read More
DICEについて、前回言及した更新版とは別にいくつかの機能を付け加えるとともに、既存部分の振る舞いを変更したくなったのでサービスリリースとして更新が必要なファイルのみアップロードした。先に0.1をインストールして、そこへ上書きということになる。修正は含んでいないので既に稼働中のサーバがある場合はどうしてもSR1の機能を使用したいということでなければ入れ替えの必要性はない。
標題の通り、ようやくDICEのバージョン番号付き正式リリースを迎えることができた。サーバアプリケーションに要求される一定水準のavailabilityを達成したことにより正式という冠とバージョン番号を付けた。そもそもバイナリは2週間以上前に出来上がっていたにもかかわらず他の作業に充てる時間の都合が付かず配布にこぎ着けるのが遅れてしまった。これからも評価版としての配布が続行される。運が良ければ年内にもう一度だけ バージョンアップできるかもしれない。現在DICEは少なくとも2つの点でMicrosoftが提供するあるコンポーネントに依存しているのでどちらか、もしくは双方を取り除き代替物を組み込む予定である。DICEのコアを利用した別のアプリケーションも作りたいけれど時間がない。とにかく生産性を上げる手段を見つけるしかない。この無力感をどう償えばよいだろうか。少なくともこの鬱陶しいサイトの更新で焦燥が紛れないのは確かだ。
»Read More
前回は、 DICEの初めての配布に際して、近年のIRC周辺の状況と、DICEに実装するIRC機能セットの選択基準について述べた。ただし観念的なバックグラウンドから具体性のあるデザインを抽出し計画を整形する過程の最中で書き留めたものであり、曖昧な部分が数多く存在した。当時の実装は、着手してから半年経過し最初のベータテストに臨んだばかりの段階で、一応のIRC/opennapサーバ機能は備えたとはいえ不安定で、明らかに改善の余地を残していた。現在では、さらに半年の検証と調整を経て、長期運用と数千の同時接続に実際に耐えることができる初めての正式バージョンのリリース(DICE v. 0.1)に至っている。そこで今回は、DICEの汎用ネットワークサーバとしての側面、バージョン0.1リリースに至るDICEの方向性の変更、また opennap準拠サービス(VirtualDirectory)の実装の詳細など、経験に基づいた視点をより多く加えつつ、現時点でのDICEの特性とその背後の意図を解説してここまでの記録としたい。
About 2 years ago, I opened an IRC channel on a small IRC network. I’d been hanging out in EFnet, Undernet, or DALnet, but the accessibility to those large networks from Japan was not decent and not much improvement is seen even today. In some networks you are just kicked because you are from the .jp domain. As a consequence, I chose a small but reliable place for the new channel among many networks. It had nickserv and chanserv. One of the largest networks known in Japan, IRCnet, lacked those services.
»Read More
Win32のUUID(GUID)構造体のラッパークラス。VS.NET2003付属STLのhashコンテナ(hash_map/hash_set /hash_multimap/hash_multiset)用比較関数、SGI系STLのhashコンテナ用ハッシュ関数オブジェクト付き。システムの用意した構造体を継承してクラスを作るというのは割とよくやる方法で、継承した場合vtableが無ければメモリレイアウトの先頭に継承元が入るので、後ろに追加のデータをペイロードとして付けた上で、親の構造体を引数とするAPIの引数に使えるという利点がある。換言すれば、templateと、template policyを利用したmix-inによって、C++における継承は、Java等のクラスライブラリに顕著な、現実世界やデザインパターンとして観念されるモデルのマッピングに近いカテゴリ概念の素朴な具体化のための道具というよりは、本来の意味でのデータ抽象/アルゴリズム抽象に向けての手段として、あるいはCOMのバイナリ仕様の表現として活用(exploit)される箇所しか出る幕が無くなってしまった。
