Delphiの汎用数値型は符号つきがInteger、符号なしがCardinalだから、何も考えないで数を扱うときはIntegerばっかり使ってきた。たとえば1から10までしか変化しない数字を扱うのであれば、32bitのIntegerを使わないで16bitや8bitの型を使えば、たぶんメモリやレジスタを節約できるんだろう。また、マイナスにならないと分かってる数を使うなら、Cardinalにした方が倍も大きい数字を扱える。だからそうする必要があると持ってる人はこだわって型を使い分けてるはずだが、あたしは不都合がない限りとりあえずIntegerだ。不都合ってのはたとえばAPIの呼び出しで型が決まってるような時ぐらいなんだけど。その、汎用で使っていいIntegerを、きっと64bitコンパイラは自動的に64bitの型として扱ってくれる物だと期待したが、Delphiではそうならず、新しくNativeIntという型を使わなければいけなくなった。おそらくちゃんと型を使い分けてる人だと、ソースコードに一括置換を行えば早く終わるんだろうが、あたしのやり方じゃそうもいかないので、チマチマと手作業で直してる所。

　やってて気がついたのは、特にGDI関連のAPIなんかが32bitの数値型を要求していると言う事だ。これに対してはDWORDとかLongIntとかを使って対処すべき所を、あたしはIntegerとCardinalでやっちゃってるので、一括置換でNativeIntにするとダメで、APIが求める正しい型に手作業で修正。まぁGDIであれば、画面を描画するだけなので64bitの数値型を要求する必要はない。でもスクロールバーを描画するのには多少不都合があって、今までは全部で何行のテキストファイルを開いてその中の何行目を表示してるかってのを、内部で扱ってる32bitの数値でそのままAPIに送る事が出来たが、真魚が64bitのデータを扱うなら内部の64bitデータをそのままGDIに送る事は出来なくなるわけで、スクロールバーの機能そのものから自作しないといけなくなる。あと、日本語入力関連も32bitのデータを送ってて、そっちもひょっとしたら一切の作り直しが必要になるかも知れない。APIだけじゃなくVCLも64bit化して欲しいクラスが32bitだったりして、これも64bitデータに触れる部分は自作していかないといけない。

　WSHはアクセス違反がでるからわかりやすいけれども、実はそこだけが障壁ではなく、Delphiがまだ64bitアプリを作るのに適してない印象を持った。というよりWindowsがまだ64bitアプリを作るのに適してないのかも。いや作る事は出来るだろうよ。あたしには無理だけど。とりあえず今回のDelphiは将来の64bit対応に向けて準備できるようにはなったってぐらいで、本気で64bitアプリを作るのは難しすぎるって内容だと思う。あたしの使い方のせいかもしれないが、デバッガやリファクタリングもほぼ動作してないので、ずいぶん使いにくくなったと感じているが、それもひょっとしたら64bitでやってるからなのかも知れない。もしかしたら32bitに切り替えればちゃんと動くのかも。

　つーわけで、真魚の64bit化は断念。少々出来ないことがあるぐらいなら制限付き64bit版として公開したかったが、このままでは64bitのデータを扱う事すら出来ないので、出来る事が何か増えるわけでもなく一切意味がない64bitバイナリだ。Delphiは買っちゃったけど、64bit化をあきらめるんなら今回も買わなきゃ良かった。