14年前に製造したAccess VBAを、64bit対応のため2年ぶりにメンテナンスすることになった。
WindowsとかLinux環境なんてものはとっくに64bit化しているけれど、アプリは32bitでも動くので、まだ32bitのアプリを結構使用している。当然のことながら、64bitのアプリがある場合は64bitのアプリを使用するのだが、大きな問題としてOfficeの64bit化が残っていた。
まあ、Officeは普通に使っていたら、64bitにしても何も問題ないはずだが、当社の環境では2つの問題が発生した。1つはAPIの問題、もう1つはVB6互換のコントロールの問題だ。
APIの問題とは何かといえば、32bitと64bitでAPIの呼び方が異なることだ。これはリンク先記載のptrsafeによって大体解決するが、winsockを用いたAPIがうまくできなかった。しかし。14年に作成したときにはwinsockを用いなければできなかった情報取得が今ならWMI使用でどうにでもなるので、WMIで実装することにして、無事完了。
ここから得られる情報は「昔APIで実装した機能が、今ならAPI使用しなくとも実装できる可能性が高い」ということ。
VB6互換コントロールの問題とは何かといえば、かつてVisualBasic6（VB6）という開発言語があって、この言語は「.netframework」を必要としないアプリケーションを作成できる最後のVisualBasicだ。このVB6用に使用できる開発用の部品（コントロール）が、多くの場合32bitのExcelやAccessのVBAから使用できた。しかし64bitのVBAからは32bitコントロールが使用できず、64bitのVB6はこの世に存在しないので、VBAからVB6用コントロールが使用できないという問題だ。
要はVBAではかなりVB6に近いことができたが、VB6自体がこの世からなくなりつつあるため、VB6の機能を使用したVBAも強制的にこの世からなくなっていくということだ。まあ、私の作ったVBAはそれほどVB6のコントロールを使用していなかったので、割り切ってしまえば改修は簡単であった。しかし、この世にはVBAでVB6コントロールを思いっきり使用してしまったアプリが結構転がっていることだろう。心当たりがあったら、ちゃんと対応しておいたほうがいいだろう。
