ビルドマシンと Windows 7，そしてクラシックな ADO

作者 Jonathan Allen , 翻訳者 吉田 英人 投稿日 2011年10月24日

セクション

デベロップメント

トピック

Japanese Build systems ,

プログラミング ,

Legacy Code ,

COM

共有 |

原文(投稿日：2011/10/19)へのリンク

90年代後半から運用されている，旧式の ADO ライブラリを使用したアプリケーションのメンテナンス作業を行うと考えてみよう。再コンパイルされたコードは，Windows 7 SP1 マシン上では問題なく動作する。ところが不思議なことに，そのプログラムを10年近く使用している Windows XP マシンではクラッシュしてしまうのだ。 これが現在，多数のメンテナンス開発者が直面している問題である。

最初にこの問題が発生したとき，Microsoft はそれが限られた開発者にのみ影響を与えるものだと考えていた。確かに 15 年前のデータアクセス技術を使ったアプリケーションをコンパイルするのに，最新バージョンの Windows を使用する人が多数いるとは考えられない。Evan Basalik 氏は続けて，次のように説明する。

要するに ADO API のいくつかで，プラットフォーム依存のデータ型を使用していたことが明らかになった，ということなのです。具体的には，32 ビット版で LONG を使っていた API に対して，64 ビット版では同じ API に LONGLONG を使用していました。これによって，64 ビットアプリケーションがこれらプラットフォーム依存のデータ型を使用しようとして，呼び出し側と呼び出し先のデータ型が一致しない場合に問題が発生したのです。http://support.microsoft.com/kb/983246 には，VBA マクロがこれとまったく同じ問題に遭遇した時のシナリオが説明されています。残念ながら私たちは，Windows 7 SP1 上で ADO アプリケーションの再コンパイルを実行するユーザ数を，大幅に過小評価していたようです。さらに悪いのは，上で述べた "大幅に"というのが，本当の意味で大幅であったことです。

問題の大きさを認識した私たちは，即座によりよい解決策を探すための行動を開始しました。しかしこの時点では，最初に実施された理想とはほど遠い対策によって，問題がさらに悪化していました。この対策によって変更された GUID が，古いバージョンの OS にまで拡大される可能性があったためです。ここで私たちは，http://support.microsoft.com/kb/983246 を引用するという，苦渋の決断をしました。そう – VBA の時と同じように，実行可能な解決策のないシナリオがいくつか残っていることは分かっていました。それでも私たちは，変更した GUID を広め続けるよりも，この方がよい選択であると考えたのです。理想的ではないにせよ，私たちの選択した推奨方法は http://support.microsoft.com/kb/2517589 から後方互換ライブラリを取得して使用するか，あるいはWindows 7 RTM 上でコンパイルする，というものでした。すべてではないにせよ大部分のシナリオはカバーできていましたし，大規模なアーキテクチャ変更なしで適用できる方法の中ではこれが最高の選択だったのです。

私は今，私たちがよりよい解決策を提示できることをうれしく思っています。次のような措置の実施が予定されています。

1. 新しいタイプライブラリファイル msado60.tlb を通じて，Windows 7 RTM から 6.0 タイプライブラリを公開します。複数のプラットフォームを対象とする予定です。
2. 新しい 6.1 タイプライブラリ (新規および非推奨のインターフェース両方を含む) を公開して，msado15.dll 内に組み込みます。
3. すべての 2.x タイプライブラリを Windows 7 RTM のもののように戻します。

新たな長期的解決策も基本的には用意できているが，広範なテストの実施される来年まではリリースされない予定だ。これができれば，6.1 タイプライブラリを 64ビット VBA アプリケーションや，旧オペレーティングシステムで動作する必要のないプログラムで使用することも可能になる。それ以外の方々は，2.x と 6.0 タイプライブラリを引き続き使用することができる。