卒業研究で私が開発を担当した、重度視覚障害者用 Java プログラム開発環境の構築を主眼としたシステムを昨日公開しました。 システムは AiB Tools という名前で、 端末エミュレータとテキストエディタが中心になるツール群です。
MS-DOS から続くバッチファイルについて、記事を書いてみました。 興味のある方は次のリンクからどうぞ。
（2006-11-19追記。記事中に間違いがありましたので、修正しました。 間違っていたのは「パスの通ったディレクトリからファイルを検索」の項です。）
とある Java のライブラリを作っている時に JNI (Java Native Interface) で Win32API を叩いてウィンドウを生成したところ、 ウィンドウがフリーズ状態になりました（応答も返らないしメッセージも受け付けない）。 メッセージループが回っていないのかなと予想して、JNI のネイティブコード中で「メッセージループを実行する」スレッドを作ってやったところ、 これではうまくいきませんでした。
何が悪いのか、与えている引数が悪いのか、などと悩んでいたところ、 MSDN をよく読むと GetMessage の説明は次のようになっていました。
The GetMessage function retrieves a message from the calling thread's message queue.
今更ながら、Windows のメッセージキューがスレッドごとに存在する事を初めて知りました（苦笑）。 となると先ほどの話は、ウィンドウの生成からメッセージループの実行まで、 生成したスレッド中で行えば良いのでしょう。 試してみたところ、うまくいきました。 以上、本日の備忘録。
「コールバック関数を使うC/C++のAPIをC#から呼ぶ」の記事を更新しました。記述を少し詳しくし、さらにマルチスレッド問題を取り上げてみました。
プログラミング関連の記事を更新しました。日本語文字エンコーディング推定クラスに機能追加、C#（というより .NET Framework）のメモ書きをC# Notesという新しいページに追加しました。 2006年9月29日 [Acc, PG]
昨日、倉敷で行われたヒューマンインターフェイス学会で研究発表をしてきました。 「重度視覚障害者のJava プログラミングを支援するシステムの開発」という題で、 研究開発したテキストエディタ、代替コマンドプロンプト (X Window的に言えば terminal emulator)、 最後にコンパイルエラー解析プログラム（解析してエラー箇所をテキストエディタで開くだけ） を紹介してきました。
発表した後に改めて感じたのは、 「プログラム開発環境」と「重度視覚障害者用ソフトウェア」の交差点には人が少ないという事です。 発表がダメダメだったにもかかわらず質問をしてくださったのは、 視覚障害者にプログラミングを授業で教える教員でもある先生だけでした。 とはいえ、その先生から発表後に色々と有用な話を教えて頂けたので、 私としては、ほぼ成功といえる発表だったと思います。 言いたい事は五分の一も言えませんでしたが。
発表がダメダメだったのには自分なりに言える理由があります。 まず、「開発環境を作った」という研究発表には、 その環境の有用性を科学的に示す「数字」（とは限らないが）が必要です。 しかし、私自身で納得できるような、 開発環境に対する数値的評価を行う方法を見つけられなかったのです。 結局、数字として確実に効果が現れるような機能を取り出して、 それを使うと有利な作業を被験者に課し、 作業所要時間が短くなるのを示すという流れで発表をしたのですが、 正直に言うと極めて不完全燃焼です。
とりあえず間違いなく言える事は、
インデントを把握できない、 英語的でないスペリングのシンボルを判別しにくい、など
音声出力と同じ内容を表示されるぐらいなら無い方が良い、 自然言語文は全角半角の区別しない方が良いがプログラム文は区別できないと困る、 など
このあたりについては発表用論旨で簡単に書けたので、その点は良かったです。 まあ何にせよこれで一段落付きました。 あとは、３日間だけ残っている夏休みをゆっくり過ごすとします（笑）。
おっと、書き忘れていました。 IronPython がリリースされています。 倉敷帰りの新幹線で C# のオブジェクトを python スクリプトに渡して操作し、 C# 側で受け取る(Hosting)するプログラムを書いてみたところ、 あっという間に作れました。これは、楽しいです（笑）。
日本語文字エンコーディング推定クラス EncodingAnalyzer を更新しました。 なんと JIS かどうかを判定している最中に無限ループに陥る可能性があるというトンデモナイ問題をはじめ、 速度向上、精度向上、さらに UTF-8 の判定を「まじめに」（苦笑）行うようにしました。
推定精度はもう十分に高いと思います。 が、どうにも C# で作っている宿命なのか、遅い気がします。 次の暇には unsafe 化して高速にできる部分を高速にしてみますか・・・。 もっとも、普通はエンコーディングの推定など頻繁に行いませんから、 多少遅いままでも良いかもしれませんね。
詳細は、日本語文字エンコーディング推定クラス のページにて。
（2006年9月8日追記）ファイルパスを指定する方法でエンコーディングを解析するとファイルを開いたまま閉じない、 という問題があったので修正しました。
Win32API 覚え書き。 RegisterWindow で登録済みクラスと同名のウィンドウクラスを新しく登録すると、 クラス名が「上書き」される。 "BUTTON" や "EDIT" などのシステムで共有しているウィンドウクラス名でも、 少なくともそのアプリケーション内では上書きできます （外部のアプリからそのウィンドウの情報を取得してもウィンドウクラス名は上書き後の名前になっています）。 すると、たとえば新しく "BUTTON" という名前で自作ウィンドウを登録したら、 GUI のボタンというボタンがすべて自前ウィンドウになってしまうのでしょうか・・・未検証ですが、 面白い話ではあります。
システム共有コントロールのウィンドウクラス名が上書きできるとなると、 スクリーンリーダーなどの支援技術がウィンドウクラスを元に UI の情報を取得するのは 100% 安全な方法とは言い切れないようです。 やはり MSAA や Java Accessibility API などのアクセシビリティ API の範囲内で動作するのが一番安全ではありますが、 実際問題それらの API に対応しているアプリケーションの少なさを考えると、 そうも言ってはいられないのが現実なのでしょうけれども。 ・・・まあ、もっとも、 システム共有のウィンドウクラス名を上書きするようなプログラマが使うに値する代物を作るとは思えませんから、 考えなくて良い問題だと思いますが（苦笑）。
Win32API の AllocConsole / FreeConsole を使って遊んでみました。 何をしたかというと、 コンソールから実行された時はコンソールアプリケーションとして動作するが単体起動された場合は Windows アプリケーションとして動作するようなプログラムを作ってみました。
まずプログラムそのものはコンソールアプリケーションとしてリンクします。 そしてプログラムの冒頭で GetConsoleWindow を呼び、 失敗したら FreeConsole するようにします。それだけです。
何かメリットがあるのかというと、現在まったく思いつきません（苦笑）。
Athlon 64 X2 の新システムを再構築していると、問題が出てきました。 問題とは、特定のゲームで遊んでいる最中に次のような症状が現れるというものです。
このような動作が起きたゲームは次のものです。
現象は起きたり起こらなかったりしたため、原因の目星を付けられずにいました。 オーディオカードのドライバがおかしいのか、 あるいはゲームや Direct X のインストールに失敗したのか、 などと検証をしていたところ、同じ現象について書いているブログを見つけました （該当記事へ）。 そのブログによると、AMD の Dual-Core Optimizer というユーティリティをインストールしたら解決したそうです。 そこで私も同ユーティリティをインストールしたところ、症状が直りました。 ただし、Serious Sam 2 だけは直りませんでしたので、 Seriously! のフォーラムの情報を元に、 ゲーム起動後にタスクマネージャのプロセスタブで Sam2.exe を右クリック、 「関係の設定」で CPU 1 のチェックを外してやる事で一応の対処ができました。
同ユーティリティは、CPU 内にある二つのコアの間で TSC (Time Stamp Counter) の同期を取る・・・というものだそうです。 最近の（？）ゲームでは、タイマーを高速に取得するために Windows の API を介さず直接 CPU からタイマーを取得する RDTSC (ReaD TSC) 命令というものを使うそうです。 Windows の API ではコア間の同期が取れていなくても正常にタイマー取得できるのに対し、 RDTSC を使うと正常に取得できなくなるのだそうです。 それが原因で様々な問題が起こるらしく、 修正用ドライバがリリースされた、という事です。
私はゲームを作った事がありませんが、憶測してみます。 一般的なアプリケーションの動作速度は、 コンピュータの速度に左右されます。 一方、ゲームは正しい速度以外ではゲームになりませんので、 左右されるわけにはいきません。 つまり動作速度を管理する必要がありそうです。 たとえば時速 6 km で走るキャラクターがいるとしたら、 どんなコンピュータでもゲームの世界の縮尺に合わせて 1 秒間に 1.67 m、 そのキャラクターの座標を動かさなければなりません。 このような処理を行いたければ、正確なタイマーを使って、 そのタイマーの進行に応じてゲームのキャラクターを動かせば良いでしょう。 キャラクター以外についても同様で、結局のところ、リアルタイム性のあるゲームは、 タイマーを使う事でゲーム中の「時間」という概念を管理するものなのでしょう。
さて、この憶測が正しいとすると、 タイマーが正常に取得できなければゲーム内の時間が狂います。 ゲーム内の時間とは、冒頭で「ゲーム全体の速度」と表現した概念そのものです。 であるならば、ゲームの速度が異常に速くなったりする現象にも合点がいきます。 また、このタイマーの取得はゲーム中で常に行われる非常にローレベルな処理です。 これを高速・低負荷に行えればゲーム全体のパフォーマンス向上に繋がりそうな気が確かにします。 RDTSC 命令を使いたくなるのも憶測レベルですが納得できます。
最後に残った疑問は、 複数のシングルコア CPU で構成したシステムでは同じ現象が起きるのか、です。 単一のデュアルコア CPU で構成した今のシステムでも、 Win32API で CPU の数を取得すると 2 つになります。 つまり条件が過去の複数 CPU 構成のシステムと同じと思えるんですよね。 複数 CPU 構成のシステムなんてたくさんあったはずですから、 こういう問題は過去に起こっていたのでしょうか・・・少し気になります。
Athlon 64 X2 その他を購入しました。 やっと PCI-Express のシステムに移行です。 届き次第、システムの再構築ですね。
本日、次の二枚の CD を購入しました。
当然ですが、まだ両方とも聴き込んでいません。 とはいえ、ぱっと聴いた感じでは両方とも良作のような気がします。 まだ気がするだけですが。
先日サイレントヒルの映画を見てきました。 「初めてゲームの映画化が成功した例」との評判通り、良かったと思います。 個人的にはサイレントヒルの異世界が持っている・・・絶望感とでもいうか、 独特の感覚が再現されていたのが特に気に入りました。
映画の後で友人のとこさんと話したのですが、 ゲーム F.E.A.R. の影響を受けたのかな？と思われる部分が何カ所かありました。 そう思って F.E.A.R. をやり直したくなったりするのですが、 マシン性能が足りないので画質を落とさざるをえず、不完全燃焼状態にあります。
マシン性能が足りないのは DOOM 3 の頃から感じ続けていましたので、 そろそろ買い換えたいなと思う今日この頃です。 Prey という面白いゲームも見つけてしまいましたし（苦笑）。
なお、話のネタとしてはつながっていますが、 内容的には無関係な DOOM 劇場版は 8 月 11 日発売。買う気、満々です（笑）。
現在、学会用に論文を執筆中です。 卒業論文は HTML で書くという暴挙に出たところ HTML ではページ番号を振れないという致命的欠陥に提出の直前で気づき、 結局 Word にコピー＆ペーストして整形する、という悔しい思いをしました。 というわけで、今度は一太郎 2004 で論文を書く事にしました。 ・・・いや、どうにも Word の操作感が好きじゃないので（苦笑）。
さて、論文は一般的に左右二段組みになっています。 ですから当然、一太郎でもページを二段組みに設定して書いているのですが、 引用部などについて脚注を入れたところ、 ページ下部にページ幅の脚注エリアができてしまいました。 しかし書いているのは二段組の文書ですから、脚注エリアも左の段なら左の段の下部に、 その段の幅で作られて欲しいわけです。 が、どうにもそれができません。 文書末尾に脚注エリアを入れる設定にしても、結局は同じでした。
そこで現在のところ見つけた対策案の備忘録 for 自分。
ただし一太郎 2004 では本文とレイアウト枠内は別の文書と扱われるらしく、 本文からレイアウト枠中の連番を参照できません。 おそらく本文中からは脚注番号を手打ちするしかないように思えます。 とはいえ、各ページのレイアウト枠をリンクしてやれば連番を続けてくれるので便利です。 また体裁は良いですし本文を変更してもレイアウトは崩れません。
あと、参考文献については単純に連番機能を使えば十分ですね。 文書末尾で連番を使って文献を列挙、本文からはその連番を参照、です。
気まぐれに、日本語の文字エンコーディングを自動判別するクラスを C# で実装してみました。 簡単にウェブ検索をして、 エンコーディングの変換ルーチンは見つかったのですが判別ルーチンは見つかりませんでした。 というわけで作ってみた次第です。
実際のところ、 曽田さんの ttPage で実装されているアルゴリズムをそのまま C# へ移植しただけのクラスです。 やはり他人のソースを時々読むのは重要ですね。 自作のコードにしか触れない日々を送っていると、 どうにもコードの質が落ちてくるような気がしてなりません。 完璧なソースを書く人など存在しないわけですから、 他人のソースを解析すれば、まずそのコードに客観的に「イマイチな」点が見つかります。 その点を見て、つまり他人の振り見て我が振り直せるようならば、 また一つ勉強できたと言えるでしょう。
もし欲しい、あるいは参考にしたいという方はどうぞお持ち帰りください。 非常にフリーなライセンスで公開します。
Visual Studio .NET 2003 において、リソースファイル（.resources 形式）をプロジェクトの項目として追加する場合について覚え書き。
まず、次のような簡単な例を考えましょう。このソリューションには MySource.cs というソースファイルと、MyResources.txt という文字列リソースファイルがあるとします。これを Visual Studio .NET 2003 でもコマンドラインツールでも同じようにビルドする方法を考えます。なお、MyResources.txtの内容は次のようになっているとします。
コマンドラインツールを使う場合を考えます。 まずリソースファイルを ResGen コマンドで MyResources.txt をバイナリ形式(.resources)に変換します。その後 csc コマンドで MySource.cs を、バイナリ形式に変換したリソースをを埋め込んでコンパイルします。コマンドは次のようになります。
このようにビルドすると、リソースはファイル名と同じ名前でアセンブリに埋め込まれます。すなわち、次の名前です。
そのため、たとえば次のようなコードでリソースのデータを取得できます。
実行すると、次のように文字列が表示されます。
続いてVisual Studio .NET 2003でプロジェクトの項目としてリソースを追加する場合について考えます。今回は、あらかじめリソースをバイナリ形式に変換しておき、それをVisual Studio .NET 2003のプロジェクト項目として追加、アセンブリに埋め込む事にします。
この場合、ファイル名と同じ名前では埋め込まれません。埋め込まれる名前は、ファイル名の頭にプロジェクトの「既定の名前空間」とソリューションエクスプローラ上でのフォルダ名が付いた名前となります。「既定の名前空間」は、普通にVisual Studioでプロジェクトを作成した場合ではプロジェクト名と同じ名前になっています。
プロジェクト名がHelloCSharp、リソースファイルがFolder1という名前のフォルダに追加されていた場合、埋め込まれるリソースは次のような名前になります。
このリソースは、コマンドラインツールの例と同様に次のようなコードで取得できます。
実行すると、次のように文字列が表示されます。
もし、「既定の名前空間」を空欄にした場合、埋め込まれるリソース名はソリューションエクスプローラ上のフォルダ名＋リソースファイル名になります。すなわち、次のようになります。
リソースがどのような名前で埋め込まれるかは、以上のように決まります。 もしコマンドラインツールでもVisual Studioでもビルドできるソースを書きたいと考えた場合、当然ですが埋め込むリソース名はどちらのツールを使っても同じにする必要があります。したがってリソース名がどのように決定されるかを把握しておかないと、このような場合に面倒な事になります。
私の場合、コマンドラインツールでもVisual Studioでもリソースが同じ名前で埋め込まれるように、次のようにプロジェクトを作りました。ご参考までにどうぞ。
こうすると、どちらでビルドしてもリソース名は Folder1.MyResource.resources となり、ベースネームをFolder1.MyResourceとすればResourceManagerクラスからアクセスできるようになります。
先日書いたとおり、コールバック関数を使うネイティブコードの関数を P/Invoke する方法を調べました。また、調べたままでおくのはもったいないと思い、一つの記事にしてみました。興味のある方は次のリンクからどうぞ。
一昨日、C#.NET から関数ポインタを引数にとるネイティブコードの関数を P/Invoke して遊んでいたところ、 呼び出す関数によっては不可解なエラーで異常終了する問題が起きました。 たとえば msvcrt.dll から qsort を呼び出して「C#の配列をソート」した時などに NullPointerException が飛んできました。 うーん、我ながら実にくだらない遊びです（苦笑）。
さて、そこで C++ で関数ポインタを引数にとる関数を作って試行錯誤したところ、 エラーの直接的な原因がわかりました。 どうやらネイティブコード側のメモリ空間（スタック領域）が壊れてしまうようでした。 おおかた P/Invoke する時に calling convention の指定を間違えたためにスタックの積み方がおかしくなっているのだろうと思ったのですが、 calling convention の指定とは関係なくこの現象が起きていました。
どうにも原因を追い切れず、 お手上げになってしまったのでインターネット上で検索してみたところ、 答えを見つけました。 calling convention が問題だろうという予想は正しかったのですが・・・ calling convention の指定が間違っていたのは、 P/Invokeした「関数ポインタを引数にとる関数」ではなく、 「引数に与えた関数ポインタが指す関数」の方でした。
発生したエラーの予想は当たっていましたし、 それを解決するために採るべき方法も正しかった。 何て事はありません。ただ、注目するべき場所を間違えていただけです。 発生していた問題のレベルを見誤っていただけです。 つまり本当の問題はcalling conventionの指定ではなく、 calling conventionを考えなければならない関数が二つある事に気づけない私にあったのですね。
最後に、インターネットを検索して見つけた「答え」へリンクを張っておきます。
the scripts.comのフォーラムでの一質問です。
__cdecl callback function with P/Invoke
ThinkPad を初期化して以来、 XML エディタの <oxygen/> の動作が異様に遅くて困っていました。 いろいろと試行錯誤したところ、 ビデオチップの省電力モードをオフにするとサクサク軽快に動作するようになりました。 本日の備忘録 for me。
VisualStudio 2005 で .NET Framework 2.0 に触れてみました。 .NET Framework 2.0 へのアップデート内容のうち、 個人的に非常にうれしいのが ListView クラスの改善です。 新しく追加された VirtualMode プロパティを true にすると、 リストビューが項目ベースでなくモデルベースになります。 項目の描画についてはデリゲートで処理します。
趣味で作った画像管理プログラムを使っている友人の環境では、 普通に動作させると六千を超える項目がリストに追加されてしまい、 重たくて使えないという話になっていました。 調べたところ、 時間がかかっているのは六千の項目オブジェクトの生成でも六千の項目用文字列のコピーでもなく、 リストの表示でした。 そこで速度向上対策として自前のモデル型リストを作って表示にかかる負荷を極小化する事を考えたのですが・・・ すばらしい事に標準ライブラリでモデルベースのリストが使えるようになりました。 ちょっとだけ自前のリストを作ってあったので微妙な気分ではありますが（苦笑）。
それで、試しに VirtualMode の時とそうでない時で 100 万個の項目を追加して表示にどれくらいの違いが出るのか試してみました。 結論から言うと、比較にならないくらい VirtualMode の方が速かったです。 Virtual Mode では一瞬で表示されるのに対して 20 秒ほどかかりました （試した PC の CPU のクロックは 3GHz です）。 もっとも、Virtual Mode と言っても表示処理 （デリゲートで表示処理を実装） をどうするかで表示速度も変わりますのでこれは極端な例です。 とはいえ、多くの場合は Virtual Mode の方が高速なのではないでしょうか。
私が愛用している ThinkPad T42 ですが、 Apache を起動して Internet Explorer で localhost にアクセスすると応答が帰ってこない状態になりました（苦笑）。 この他にも動作が怪しい点が増えてきたので、 思い切って工場出荷状態にリカバリーしました。
一点、環境を再構築していくにあたって悩んだ事がありました。 コマンドラインインターフェイス環境をどのように構築するか、という点です。 選択肢として msys や cygwin を中核に据えてしまうことも視野に入れたのですが、 やはり無理でした。 たとえば拡張子 .py のファイルに Python インタープリタを関連付ける事を考えましょう。 関連付けを普通に行ってから .py ファイルをダブルクリックすると、 ファイルが見つからないと表示されて実行に失敗します。 おそらく cygwin では Windows 形式ではなく UNIX 形式のパスを使っている事が原因でしょう。 対策しようと思えば簡単に対策できますが、面倒くさいのでネイティブ版を使おうと（苦笑）。
なお、私は Python スクリプトをダブルクリックで実行したいわけではありません。 UNIX 系システムでよく行われるように、 コマンドラインからスクリプトファイルを実行ファイルのように起動したいのです。 つまり HelloPython.py という Python スクリプトがあるならば、それを
python HelloPython.py
ではなく
HelloPython
と入力して実行できるようにしたいのです。 正しく関連付けができていれば、 この夢（？）は PATHEXT という環境変数に対象の拡張子を追加すると実現します。
さて、話を本題に戻します。 結局のところ、お世話になる事となったのは cygwin でも msys でもなく、 Windows ネイティブ移植版 GNU コマンド群と各種スクリプト言語の Windows 版インタープリタでした。 Windows に UNIX 的 CUI 環境を構築する場合、 やはり文化が違うので完全に UNIX 化できるはずはありません。 そこそこに使いやすくして、そこそこ不自由なままで我慢するのが労力的にもベストかなと。
参照 : Native Win32 ports of some GNU utilities
先日、総務省主催のウェブアクセシビリティセミナーに参加してきました。 誰に言われたわけでもなく、あくまで個人的に勉強目的で、です。
JIS 規格の JIS X 8341-3 はウェブのアクセシビリティについて標準化しています。 しかし、その内容が技術的すぎる点、 アクセシビリティを確保するための具体的な方法などが示されていない点が課題とされてきました。 そこで、具体的に地方公共団体でウェブサイトを運用するモデルを研究し、 その成果から「みんなの公共サイト運用モデル」が作成されました。
「みんなの公共サイト運用モデル」は PDCA サイクルや QC７つ道具といったキーワードで知られる品質管理の方法論を取り入れた、 文字通りウェブサイトのアクセシビリティを維持・向上しながら長期にわたって運用していくためのプロセスをモデル化したものです。
ウェブサイトの運用にあたり、更新作業は必ず発生します。 しかし現実には、更新を行うの人間がアクセシビリティの「アの字」も知らない場合がほとんどです。 そのため、セミナーでは人間の教育や意識改革といった課題が大きく取り扱われた事が（ごく個人的に）印象的でした。
総務省の「みんなの公共サイト運用モデル」のページでは、研究の成果である同運用モデルを記した文書を無料で手に入れる事ができます。また、本セミナーで配付された資料や、発表に使われた各種障害を持つ人々のインターネット利用の様子を写した貴重な動画を見る事ができます。興味を持っているかどうかに関わらず、多くの人々にとって公開されている動画は見る価値があると思います。実際に動画にあるような現場を見た経験が無い方であれば、何らかの衝撃を受けるはずです。