AB開発日記

ネタ的にかなり遅めですが、IE7のBeta3、入れてみました。なんでこんなに試すのが遅くなったかというと、、、

x64だからですorz

まぁまぁ、x64を悪くいっちゃぁいかんです。これまで、試行錯誤を繰り返しながらムリヤリ色々なソフトを対応させてきたのですから。それでもx64未対応と言われればそれまで（Beta2までは未対応だったんです）。だったら、WOW64上で動く32ビット版を入れれば・・・←OSに溶け込んでくるIEはそのようなフットワークは無いようです。ということでBeta2までは全くインストールできなかったんです。

そんなわけで、x64対応のBeta3からやっとIE7を試せたワケなのですが、

グラフィカルな感じになったのは良いのですが、使い物になってません（Betaだからしょうがないといえばそれまでですけどね…人のこと言えないかも）。

_blankで別ウィンドウが立ち上がった瞬間にほぼ100%の確立で強制終了。Googleで検索するたびに、IMEがおかしなことになります。

このブログをアップするのがIE7 Beta3の最後の仕事。今からアンインストールしてきます(~~

C/C++で書かれたAPIをABに移植する際、エディタについている置換機能の中で、正規表現による置換を使うと非常に効率よく作業が進みます。

例えば、下記のような置換を行うと、大文字の型名の変数宣言文がAB向けに書き直されます。

検索する文字列: ([A-Z]+) (\**)([a-zA-Z0-9_]+)

置換後の文字列: $3 As $2$1

しかし、複数の変数を一つの型で定義するときなどには対応しきれないので、「次を置換」ボタンを押しながら、慎重に置換していきましょう（と、自分に言い聞かせる…）。

間違っても、「すべて置換」でスル〜してはいけません（焦

オブジェクト指向対応型のプログラミング言語を実装する上で、クラスの管理は欠かせないものになります。というか、それが全てだといっても過言はありません。少なからず、コンパイラの内部でクラスに関するすべてのデータを持ち合わせ、照合を行いながらコード生成に挑んでいく必要があるのです。

では、データとして持たなければならない「クラスに関する情報」というのは、具体的にはどのようなものがあるのでしょう？これは一般論ではなく、ABを実装する上での事象ですので、その点をご了承の上・・・

• クラス名（これが無いとお話になりませんf(^^;;;）
• スーパークラスへの指標
• メンバに関する情報（複数）
  • メンバ名
  • 型
  • （必要であれば）配列要素
  • アクセシビリティ
• メソッドに関する情報（複数）
  • メソッド名
  • 仮想関数かどうか
  • パラメータに関する情報（複数）
    • パラメータ名
    • 参照型かどうか（ByRef/ByVal）
    • 型
    • （必要であれば）配列要素
  • 戻り値の型
  • アクセシビリティ
• アライメント値

このような情報を一つのクラスとしてまとめ、更にプロジェクト内に存在するすべてのクラスを統括して管理するためのクラスデータベースクラスを用意してしまえば、クラスの管理を効率的に行えるようになります。

このように、オブジェクト指向をクラスという側面から見た場合、そのクラス構造そのものも、クラスとして捉えるという、またワケのわからないことを書いてしまいました。

JavaやC++、C#などでは当たり前のように使ってしまう仮想関数。同じ名前のメソッドでも、そのクラスの階層、はたまた時系列によってその内容は変わっていくという不思議な存在であります。また、モジュール設計を重視する上では非常に便利で有効な手段です。

しかし、これらを言語レベルで提供していくには、結構面倒な壁にぶち当たるときがあります。仮想関数ポインタを配列で提供するvtblなど、普段は意識することがありませんが、実は裏方で地味な作業をしているのです。

コンストラクタを順次に呼び出していく仮定で、vtblの内容の決定タイミングは非常に重要になってきます。例えば、クラスA、クラスBがあったとします（クラスAはクラスBのスーパークラス、因みに仮想関数を持ちます）。

1. クラスBがNewされる
2. vtblをcallocし、クラスAで実装可能な関数ポインタをセット
3. クラスAのコンストラクタを実行
4. vtblをreallocし、クラスBで実装可能な関数ポインタをセット
5. クラスBのコンストラクタを実行

これでやっとクラスBの機能を使えるようになります。まぁ、これらの処理はプログラマは概念的に知っておくだけで全く問題ありません。言語処理系が面倒を見る部分ですから・・・

しかし、その言語処理系を抱える私は、これらの手順が少しでも違っただけで、アクセス違反の大きなタネを作っていることになります。複雑で長いコードではありますが、慎重に扱っていきたいものです。

ここ数日、最適な室温のおかげなのか要因は不明なのですが、開発作業時の集中力がいつもよりも高いような気がします。

そこで、なかなか手を出せなかった機能の一つ。デバッガのアタッチ機能に取り組んでみます。

デバッグを行う上で、プロシージャ階層やスレッド情報を実行側が管理しておく必要があるのですが（だからデバッグコンパイルとリリースコンパイルがあるのです）、アタッチ前の状態ではデバッガとの意思疎通が取れない状態になっています。

そんなこともあって、VC++などはどうやってアタッチ前の情報を仕入れているのかなと。。。不思議に思ってはいたのですが…。

どうやらアタッチを行った瞬間に、それまでのデバッガに流れるべき実行状態が垂れ流しで送られてくるようです。タネも仕掛けもありませんでした（ある意味ホッ

通常、デバッガは下記の2つのいずれかの方法でターゲットアプリのデバッグを開始します。

• CreateProcessで起動（DEBUG_PROCESS または DEBUG_ONLY_THIS_PROCESS を使用）
• DebugActiveProcess

後者の方法をとればアタッチを行えるので、そのようなコードを書いていきます。何気に、DebugActiveProcessでアタッチを行った直後に流れてくるDLLのロードイベントでは、通常の方法ではDLL名を取得できないようなので、モジュールアドレスからGetModuleFileNameExで取得することにします。

こんな感じで、実験段階ではアタッチが成功しているので、実用段階までインターフェイスを煮詰めていきたいと思います。

これで、ABでのデバッギングも少しはラクになるかな〜なるといいな〜

ヒマな時間を活用して、がっつり作りこみました。

Win32/Win64アプリ共にアタッチを行えます。デバッガの32/64切り替えはIDEが自動的にやってくれるので、ユーザーは意識しなくてよい仕様に仕上がりそうです。

今のところ、問題はなくテスト稼動が遂行しております。このまま、何も無ければ今夜はゆっくりとテレビでも見てくつろげます。

普段使い慣れているものに限って、メンテナンスを忘れてしまうということ、ありますよね。

特にマウスなんかは良い例です。今や光学式がほとんどでコロコロマウスがほとんどなくなってきたので、ボールをはずして掃除するということは無くなりつつあります。

しかし、日常的に使うものであれば、”汚れ” は必ず付きます。通常はホコリが圧縮されたものが裏側に着く程度だと思うのですが、私のようなハードユース者は表面のゴム素材が剥れ、元のデザインが分からなくなってしまうくらいに変わり果ててしまうこともあります。

他人であればすぐ気づくのも、いつも使っているもの、ちょっとずつ汚れていくものは自分では気づきにくいです。

今朝、なんとなくなのですが、マウスの細かいところまでじっくり観察して、相当汚れていることが判明しました。

潜在を含ませたタオルで磨きまくったのですが、もはや手遅れ。その劣化を隠すことはできません。ただ単にカッコ悪くなるだけなら良いのですが、磨けば磨くほど、ゴム素材がヘタッてベトベトしてくるんです。

長年使っているものだけに（かれこれ5年…）、反応速度、ボタン配置、フィット感、クリックの感触など、体が覚えている状態なんです。ノーパソのマウスに切り替えてみたものの、なんかしっくりきません。

ということで、本日は私の商売道具でもある大事な大事なマウスを買いに、久々にPCショップに行ってきます！おっと、その帰りに本屋でも寄ってネタでも探してくるか…

ODBCのデータソースドライバをインストールする関係で、コンパネからODBCアドミニストレータを開いているところなのですが、私の持っている64ビットWindowsではドライバが揃っていないみたいなのです。

コンパネから起動するODBCアドミニストレータは純粋な64ビットアプリなわけで、当然ながら64ビットドライバを探しにかかることになります。

ODBCドライバが揃っていないんだから、親切に32ビット版のODBCアドミニストレータをコンパネに置いておいてくれれば問題ないのですが…。そういうところの配慮のなさが64ビットWindowsを買ったのに、32ビット版に再インストールしてしまうユーザーを増やしていることと思います。

そこで32ビット版のODBCアドミニストレータはどこにあるのかということになりますが、下記のフォルダにodbcad32.exeというファイル名で格納されています。

• C:\Windows\SysWOW64\

これはWOW64として実行可能な32ビットアプリ（またはDLL）が格納されているフォルダなのですが、なぜかフォルダ名の末端には “64” という表記があります。まぁ、WOW64というのが正式な略語だということはわかるのですが、純粋な64ビットアプリがそのフォルダのちょい上にあるSystem32にあることを考えると、いかがなものかと。

ようは、

• 64ビット … C:\Windows\System32
• 32ビット … C:\Windows\SysWOW64

ということなのですが、、、逆じゃないかと。。。大体この点から紛らわしいんですよ。”Program File” フォルダだって “Program File(x86)” という表記になっているんですから、”system32″ と “system64” に分けるだけでいいんじゃ…。

まぁ、何かしら理由はあると思うのですがね。こういうところで時間を食ってしまうことがたたあるので、Windows Vistaではスムーズにことが運ぶことを祈ります。

ABユーザーのToshiさんが開発されるタブ型ブラウザToss、各種コントロールがどのような構成で実現されているのかに興味を抱きつつ、ダウンロードしてみました。

まずはIEコントロールの埋め込みに関して。ウィンドウにIEコントロールを埋め込むだけであれば私もやったことがあるのですが、細かい部分でのイベントのやり取りがABのみではあまりうまくいかなかったのを覚えています。結局、COMとATLをAB上でどのようにカバーするのかがポイントになります。

何気に気に入ったのは、レバーコントロール、ツールバーコントロール、タブコントロールがスッキリとキレイにまとまっていたこと。アルファ版ということで機能こそ多くはないものの、好感が持てるインターフェイスは今後とも継続してもらえるとうれしいかも。。。デザインセンスで突き進むのであれば、メニューをオーナー描画してLunascpaeみたいにするのもアリかもしれません。

実用に耐えうるバージョンまでもっていくにはいくつかの壁を乗り越える必要がありますが、そのような方向に少しでも近づいていくことを祈っております。

Toss開発元ページ:

http://toshi.my.land.to/

ちょっと探しているのですが、なかなか見当たりません（ないのかな…）。

日本語、英語の双方向の翻訳ができれば良いのですが、、ちなみに、WebサイトからのAPI呼び出しではなく、アプリケーションが要求を出して、結果をテキストベースで受け取るという用途を考えているのです。

Google Translate（米）であればスクレイピングすることができそうなのですが、「アプリケーションからの用途でも使って良いよ」という記載（っつか、サイトからも）が見当たらなかったので現状だとダメっぽいです。。。

うーん、さすがにCPUを食い尽くす処理をしていそうな翻訳サービス、WebAPIにできるほど余裕が無いのか・・・いや、今どきそんなはずは、、、うーん、わからん