Windows 上の 64 ビット Visual Basic for Applications (VBA) のコンパイラ バグが何年も修正されずに存在しており、64 ビット Office への移行を妨げていると、ユーザーから苦情が寄せられています。
StackOverflow ユーザーによって報告された問題は、32 ビット VBA では正しく実行されるが、64 ビット バージョンでは実行されないコードにあります。
Windows API を呼び出す Declare ステートメントなど、VBA コードを 64 ビット モードで実行するために変更する必要がある理由は文書化されていますが、これはそのうちの 1 つではありません。
むしろ、クラスが Class_Terminate() メソッド (クラスが破棄されるときに呼び出されるデストラクタの VBA 用語) を含めて宣言されている場合、場合によっては false を返すべき関数が true を返すことがあるようです。
試してみたところ、コードは 32 ビット VBA では期待どおりに動作しますが、64 ビットでは動作しないことが確認できました。
このバグは64ビットExcelで簡単に実証できる
これはバグを説明するために簡略化した例ですが、32ビット版VBAでは動作していたものの64ビット版では動作しなくなったアプリケーションから抽出されたものです。「コードが外部に公開できないため、Office 64への移行が妨げられています」とユーザーは述べています。
バグはソフトウェアではつきものですが、今回のバグの何が特別なのでしょうか?
いくつかあります。一つは、falseを返すべき関数がtrueを返すと、悲惨な結果を招く可能性があるということです。運が良ければアプリケーションがクラッシュしますが、運が悪ければ、すぐには気づかれない誤った結果を返します。
第二に、このバグはマイクロソフトに報告されていました…何年も前のことです。このユーザーは2018年に報告しました。
このバグはおそらく Office 2010 で 64 ビット VBA が導入されて以来、何年も存在していたものと思われます。
StackOverflow ユーザーは、「このバグは、2013 以降のすべてのバージョンの Office で見つかりました。おそらく少なくとも 8 年前のものです」と述べています。
このバグは Mac 上の VBA では発生しません (また、Mac ではコンパイラ定数 Win64 が true と評価されることもわかっています。実際のオペレーティング システムを明らかにする別のコンパイラ定数 Mac があります)。
- マイクロソフトは、Visual Studio Tools for Office を .NET Core に移植する要求を「もちろん検討します」から「いいえ」に転換しました。
- Stack Overflow調査：Microsoft IDEが優勢、AWSの後ろでGCPとAzureが激戦
- 不合格となった就職活動の共通点：履歴書
- ブレイキング・バッド？それとも単にブレークポイントが悪かっただけ？前任者がBASICだった時のあの感覚
- 32,000人の開発者を対象とした大規模調査で、JavaScript、GitHub、AWSがトップに
64ビット版Officeは長年存在していますが、多くのユーザーは64ビット版Windowsを使用しているにもかかわらず、依然として32ビット版を使用しています。これは、Microsoftがデフォルト設定を変更したのは2019年3月になってからだからです。それ以前は、互換性の問題から、ほとんどのユーザーにとって32ビット版の方が安全な選択肢であると考えていました。
Office のインストールは、あるアーキテクチャから別のアーキテクチャに自動的に変更されないため、デフォルトを上書きしない限り、それ以降に Office の新しいバージョンをインストールしたユーザーのみが 64 ビットになります。
根本的な問題は、Microsoft が戦略的であると考えるコードに精力的に取り組んでいる一方で、その逆もまた真実であるという点です。
Office 自体は同社にとって引き続き重要ですが、VBA はそうではありません。これは、開発者がデスクトップ、モバイル、ブラウザーのクロスプラットフォームで動作する Web ベースのアドオンに移行するという考えがあるためです。
これが、同社が Visual Studio Tools for Office を .NET Core に移行しようとしない理由であり、VBA が 10 年以上もバージョン 7.x のままになっている理由です。
ただし、ユーザーの観点から見ると、VBA は軽量かつ高機能であり、公開されている COM (コンポーネント オブジェクト モデル) API により、Office アプリケーション内のほぼすべての機能にアクセスできます。そして、これはセキュリティ上の問題にもなり得ます。そのため、マクロを含むドキュメントには異なる拡張子が付けられています。
「正直に言うと、Officeプログラムにはバグがたくさんあり、それを確実に修正する方法はありません。私も何度か遭遇しました」と、別のユーザーは悲観的に語った。
StackOverflowコミュニティが回避策を見つけたのは、部分的に良いニュースです。別のユーザーは、「If True = ReturnFalse(New SomeClass) Then」で修正できると指摘しました。それに対する答えは？「問題は、ユーザーがバグを報告したり、バグを修正してもらったり、さらには未解決のバグのリストを入手して回避したりするための明確なプロセスがない開発プラットフォームに投資すべきかどうかだ」と元のユーザーは言いました。おそらく、この質問への答えは簡単でしょう。®
