Microsoft Announces End of RegEx Support for VBA
We finally have an official timeline for when Microsoft will be dropping support for VBScript--and what impact that will have on VBA developers.
About six months ago, I took a bit of heat on LinkedIn for what some people considered clickbait when I wrote the following article:
Mike Wolfe
Fast forward six months and we finally got some additional information from Microsoft on the topic. And it's not good (emphasis mine):
Phase 3
VBScript will be retired and eliminated from future versions of Windows. This means all the dynamic link libraries (.dll files) of VBScript will be removed. As a result, projects that rely on VBScript will stop functioning. By then, we expect that you’ll have switched to suggested alternatives.
Naveen Shankar Chilla
Wait a minute, what do you mean by "all the dynamic linked libraries of VBScript"? How many are there? I was only worried about two: vbscript.dll (which includes RegEx support) and scrrun.dll (which includes Dictionary and FileSystemObject support). Now I'm concerned that maybe I wasn't worried enough.
UPDATE: I asked for clarification in the comments of the aforelinked article and received this official response from Naveen Shankar, the Microsoft employee who authored the article:
The scope of VBScript deprecation includes only vbscript.dll and no other libraries. This shall not impact any projects that are not dependent on vbscript.dll.
The VBA team is committed to provide more updates around the alternatives/new developments soon. Stay tuned for further information
While that is obviously terrific news, why did the article go out with the original wording? Was Microsoft just looking to keep their options open? Going back to November, this whole announcement has been a bit of a PR disaster.
Countering Fear, Uncertainty, and Doubt (FUD)
When I wrote my first article covering the VBScript deprecation announcement, I was accused by many of fomenting FUD.
To be fair, the accusation was not entirely unfounded. My concern then (and it remains now) is that the people at Microsoft making this decision have no idea just how impactful this change will be. Nothing that I wrote was untrue in any way, but I certainly framed it to elicit an outcry from the VBA development environment.
Unfortunately, that "outcry" (such as it was), mostly fell on deaf ears at Microsoft.
In fact, the only person there who seemed to care at all was Courtney Owen, a member of the Microsoft Access engineering team. When I attended the MVP Summit in March, he told me that he had reached out personally to the team responsible for the original VBScript deprecation announcement to pass along my concerns. If not for him, I don't think the concerns of VBA developers would have been addressed at all.
That said, Microsoft really did the bare minimum in addressing those concerns in their follow-up article.
Microsoft Throws VBA Developers a Bone Some Crumbs
Beyond the quote about .dll's that I included above, the following section is all the information regarding VBA that appeared in this latest announcement:
VBA projects that use VBScript
Visual Basic for Applications (VBA) allows users to automate repetitive tasks and customize functionalities within Microsoft Office suite. This includes Excel, Word, PowerPoint, Access, and some other applications. With VBA, you’ve been able to write scripts (macros) to manipulate data, create custom forms, automate reports, interact with other applications, and perform various other tasks to streamline workflows and enhance productivity.
Currently, VBScript can be used in VBA for two scenarios:
• Scenario 1: Call a .vbs script directly from VBA.
• Scenario 2: Use VBScript as typelib reference (such as VBScript regular expression) in VBA.
You can keep using the existing solutions if your VBA solutions have the scenarios above, as Phase 1 won't affect you. But future phases will affect you, so watch out for new developments.
If you see a runtime error or compile error while executing the VBA projects, check that the VBScript FODs [(features on demand)] aren’t disabled by admin setting.
I don't even know where to begin.
First of all, Microsoft's language unnecessarily creates more FUD rather than less. Perhaps I'm being pedantic–and maybe it's my background in Latin–but the use of the present perfect tense in the sentence, "With VBA, you've been able to write scripts..." conjures an ominous implication that maybe those days are numbered.
What I find most infuriating about that implication is it simply is not true.
VBA is not going anywhere.
The Access team knows this. The Excel team knows this. Everyone on the Office team (except those rogue scoundrels trying to foist New Outlook upon us) knows this. But there is a whole new generation of developers at Microsoft who do not seem to know this. And that includes whatever team is responsible for showing VBScript the door.
It's Not VBA; It's the Desktop
For a long time, I thought the problem was that "real" developers looked down on VBA as a development language.
And for a long time that was true.
But over the last decade or so there has been a subtle but important shift. These days, "real" developers look down on the desktop as a development platform.
What used to be, "no one writes VBA applications" has morphed into "no one writes desktop applications."
After all, why would you want to pay one price for a perpetual license to use desktop software when you could instead pay a recurring subscription fee with the reassuring feeling that someday your web-based SaaS provider could close up shop and you could be left with nothing?
To be sure, there are important benefits to web-based software, but the dirty little secret in the development world is that the move to web-based subscription software disproportionately benefited developers and software companies rather than end users.
Anyway, this underlying assumption that "desktop software development is dead" can be seen in the Microsoft article's clear emphasis on the impact that VBScript deprecation would have on web development rather than desktop development.
As evidence, consider the following quotes lifted from the Microsoft article (emphases mine):
Scripting options for web development and task automation are modernizing.
[VBScript] is often embedded within HTML pages to add dynamic interactivity and functionality to web pages and is commonly used in conjunction with Microsoft technologies like Active Server Pages (ASP) and Windows Script Host (WSH). However, with the advancement of technology, more modern and efficient options are now available.
Why is VBScript deprecated?
Technology has advanced over the years, giving rise to more powerful and versatile scripting languages such as JavaScript and PowerShell. These languages offer broader capabilities and are better suited for modern web development and automation tasks.
Considering the decline in VBScript usage in favor of more modern web technologies, we have developed a phased deprecation plan for VBScript.
Consider two modern solutions to replace VBscript: PowerShell and JavaScript.
Given this context, the article's short digression into the deprecation's impact on VBA feels like even more of an afterthought.
Final Thoughts
At the end of the day, things could have been a lot worse.
The "Microsoft Scripting Runtime" reference (scrrun.dll) is not going anywhere. That means the FileSystemObject and Dictionary object are both safe for now. The coming loss of vbscript.dll does mean the loss of the Regular Expressions library, but:
- Relatively few VBA developers use the RegEx library
- There's still plenty of time for Microsoft (or some enterprising community member) to come up with a solution/workaround for the lost functionality
The deeper concern is the utter disregard for the VBA community within Microsoft.
It took more than six months to get an official followup to the initial announcement. And even then, the team doing the deprecating couldn't be bothered to figure out which .dll's were affected. They went with the cop-out language of "all the dynamic link libraries (.dll files) of VBScript will be removed."
Annoyingly, it didn't seem to take long to find the actual answer. I and another commenter asked about it, and the author came back with a response in less than two hours. In other words, the data was always there–it just took a bit of digging to find it.
