[かみやんのたわごとへ戻る]


counter

CEDEC

 来週の9/16にCESA DEVELOPERS CONFERENCE(通称CEDEC)が、開催される。詳しくは、ここ。年に一度の楽しみの3D野郎カンファレンスの実質的な3回目だ。当然俺は行く(公聴者としてだが)。第一回目は、俺はProjectDPを発表した。規模は30人ぐらいか。第二回目は、宮野くんと行ったきた。規模は80人ぐらいか。CEDECでも、常連のshi3zさん、早瀬さん、永谷さんなどが発表してくれる。他にもきっと、いつもの常連と会うことができるだろう。今から楽しみだ。

UR-HardKeyのその後

 UR-HardKeyだが、リリース後、少しばかりの反響があった。特に、Pal Macさんのページでは、長いレビューが載った。ついでに、PalmVやWordPad c3で、ウインドウ位置が保存されないというバグも見つかり、バージョンアップした。要望もいくつか来ていて、

といったところだ、どちらもできそうなので実装したいと思う。

FEPの状態変数解析

 前回のたわごとで、グローバル変数を参照してFEPの状態を見ていると書いたが、実は、状態変数(PolotGlobalsP->inlineStatus)の構造をメモリダンプをとって解析したのだ。状態変数へのポインタは得られるのだが、そのポインタがvoid*になっているため、自分で解析する羽目になったのだ。メモリダンプを追ってハックするなんて久しぶりにした。以下が、その解析した構造体だ。

struct FepStatusType {
      Word n1 ;//不明、常に1
      Word n2 ;//不明、通常0xCAB2、太い下線がある状態で0xCB15
      Word n3 ;//太い下線の長さ
      Word n4 ;//細い下線の長さ
      Word n5 ;//選択文字列の開始位置(細い下線の最初が基準)
      Word n6 ;//選択文字列の終了位置(細い下線の最初が基準)
               //選択文字列がないときはカーソル位置
               //この選択文字列とは、文節区切り間違えのときにユーザが文節を
               //指定するために選択した文字列
      Word n7 ;//不明、常に0
      Word n8 ;//不明、常にn3(太い下線の長さ)と同じ
      Word n9 ;//確定した文字列の長さ
      Word n10 ;//不明、常に0
      Word n11 ;//不明、フラグか?
      Word n12 ;//不明、フラグか?
      Word n13 ;//不明、常に0
      Char n14 ;//FEPの状態
                //0...FEP OFF
                //1...FEP ON 通常
                //2...FEP ON 「あ<->ア」ボタンでひらがなに変換した後
                //3...FEP ON 「あ<->ア」ボタンでカタカナに変換した後
                //4...FEP ON 変換中(太い下線がある状態)
      Char n15 ;//入力モード 0...「あ」、1...「ア」
      Char yomiText[100] ;//読みが入る(NULL終端文字列)
} ;

かなりの部分が解析できた。これを使ったHACKソフトとかを作れば色々と面白いことができそうだ。

C++化難航中...

 先日、UR-HardKeyをCからC++へ移植すると言っていたが、非常に難航している。デザインパターンを使って設計すると言っていたが、もうやめた。いつも通りの俺のスタイルにしてしまった。そんなことは問題ではない。

 まず、DAはグローバル変数を使ってはならないという大前提がある。アプリケーション場合は、グローバル変数の先頭アドレスをa4レジスタにセットし、グローバル変数を参照するときはa4レジスタからの相対アドレスで参照する。グローバル変数領域はアプリケーション起動時にOSが確保し、そのアドレスをa4レジスタにセットするわけだ(たぶん)。ところが、DAの場合は、既にアプリケーションが動作している上に起動される。だからa4レジスタはアプリケーションのグローバル変数領域の先頭アドレスをさいているため、DAがグローバル変数にアクセスしようとするとアプリケーションのグローバル変数領域をアクセスすることになる。つまり、DAでグローバル変数を使うと起動元のアプリケーションのグローバル変数領域を破壊してしまう可能性がある。そのため、DAの開発では、スタック領域とヒープ領域だけで開発しなければならない。

 さらに悪いことに、gccでは仮想関数テーブルはグローバル変数領域に置かれる。これは、恐らくPalmデバイスのメモリの少なさを考慮した設計なのだろう。このことに気づいたのがコードをすべてC++に変えた後だったので、致命的だ。ちなみに、VisualC++では仮想関数テーブルはインスタンス毎に持っている。まだ、この問題に付いては解決していない。解決法は、以下の3つだろう。

 3番目の方法が最もスマートなので、その方法をしたいと思っている。が、68kのアセンブリを知らない俺にどこまでできるかが問題だ。ちなみに、これをやり遂げるのにデバッガは使えない。前にも書いたがDAやHACKの開発ではgdbは使えないのだ。先は遠い。

 もう一つ、相対ジャンプは32Kまでという制限がある。これも辛い。8086の時代を思い出す(さらには、z80のころは、相対ジャンプは128byteまでというのもあった)。ある関数を呼ぼうとすると「届かないよ」とリンカエラーを出す。

DWord PilotMain() {
    int* p = new int[100] ;
}

 こんな、短いプログラムをコンパイルしても、「_default_new_handlerからコールしている_exit()が届かないよ」とリンカエラーを出す。これは、もはやC++を使うなということか。とあきらめず、とりあえず自分で_exit()関数を書いてOK。

結論:C++でDAの開発はかなり厳しい


[かみやんのたわごとへ戻る]