This article is more than 1 year old
Eight-year-old bug in Microsoft's 64-bit VBA prompts complaints of neglect
'It blocks a migration to Office 64 here, because we cannot get our code out'
A compiler bug in 64-bit Visual Basic for Applications (VBA) on Windows has existed unfixed for years, a user complained, and is blocking migration to 64-bit Office.
The problem – reported by a StackOverflow user – is in code that runs correctly in 32-bit VBA but not in the 64-bit version.
There are documented reasons why VBA code may need modifying to run in 64-bit mode, such as Declare statements that call the Windows API, but this is not one of those.
Rather, it appears that if a class is declared including a Class_Terminate() method (VBA lingo for a destructor, called when the class is destroyed), then in some circumstances a function that should return false will instead return true.
We tried it and can confirm that while the code works as expected in 32-bit VBA, in 64-bit it does not.
Note that while this is a simplified example to demonstrate the bug, it is distilled from an application that worked in 32-bit VBA but broke in 64-bit. "It blocks a migration to Office 64 here, because we can not get our code out," the user said.
Bugs are a fact of life in software, so what is special about this one?
A few things. One is that a function that returns true when it should return false could have potentially calamitous consequences. If lucky, the application crashes; if unlucky, it delivers wrong results that are not immediately noticed.
Second, the bug was reported to Microsoft... years ago. This user reported it in 2018.
The bug has likely existed for years, possibly since the introduction of 64-bit VBA in Office 2010.
The StackOverflow user said: "I could find this bug in all versions of Office I have, starting from 2013 and it is probably at least 8 years old."
The bug does not appear in VBA on the Mac (and we also learn that on a Mac, the compiler constant Win64 evaluates to true; there is a separate compiler constant Mac which reveals the actual operating system).
- Microsoft flips request to port Visual Studio Tools for Office to .NET Core from 'Sure, we'll take a look' to 'No'
- Stack Overflow survey: Microsoft IDEs dominate, GCP and Azure battle behind AWS
- The common factor in all your failed job applications: Your CV
- Breaking Bad or just a bad breakpoint? That feeling when your predecessor is BASIC
- JavaScript, GitHub, AWS crowned winners in massive survey of 32,000 developers
Although 64-bit Office has existed for a long time, many users still run 32-bit versions, despite using 64-bit Windows. The reason is that it was only in March 2019 that Microsoft changed the default. Prior to that, the company felt that compatibility issues made the 32-bit version a safer choice for most users.
Office installations do not change from one architecture to the other automatically, so it is only users who have installed a fresh version of Office since then who will have 64-bit, unless they overrode the default.
The core problem is that while Microsoft works energetically on code that it considers strategic, the opposite is also true.
Although Office itself remains important to the company, VBA is not, since the idea is that developers migrate to web-based add-ons that work cross-platform on desktop, mobile and in the browser.
This is why the company is not attempting to migrate Visual Studio Tools for Office to .NET Core, and why VBA has stuck at version 7.x for over a decade.
From a user perspective, though, VBA is both lightweight and capable, with access to almost anything in the Office applications thanks to the COM (Component Object Model) API that they expose – and yes, this can be a security problem too, which is why documents which include macros have a different extension.
"Honestly, there are plenty of bugs in Office programs and there's no reliable way to get them fixed. I've run into several," said another user, pessimistically.
The partial good news is that the StackOverflow community found a workaround. "If True = ReturnFalse(New SomeClass) Then" fixes it, another user noted. The response? "Problem is, should I invest in a development platform that has no defined process for users to report bugs, get bugs fixed or even get a list of open bugs to work around?" said the original user. A question, perhaps, that is easily answered. ®