Deployment

Feature Gates: How Microsoft Switched to a Single Code Base for Multiple Versions of Office

Did you ever wonder why SysCmd(acSysCmdAccessVer) returns 16.0 for every version of Access starting with Office 2016? I have a theory...

Mike Wolfe

Apr 3, 2023 • 5 min read

(DISCLAIMER: I do not have any official documentation or insider knowledge about how this works. Think of this more as a series of educated guesses rather than a piece of pure non-fiction.)

Here is a recap of the list of Microsoft Office versions going back to Office 95 when Microsoft first introduced a unified suite-wide version number. The leading number is the code version, which appears in the registry (as seen here, for example) and is the value returned when you run SysCmd(acSysCmdAccessVer) in Microsoft Access.

7.0: Office 95
8.0: Office 97
9.0: Office 2000
10.0: Office XP
11.0: Office 2003
12.0: Office 2007
14.0: Office 2010
15.0: Office 2013
16.0: Office 2016
16.0: Office 2019
16.0: Office 2021
16.0: Microsoft 365

Notice anything suspicious? The code version for Microsoft Office has been stuck at 16.0 since the introduction of Office 2016.

What's Going On Here?

In a highly ranked Q&A on StackOverflow, Dirk Vollmar addresses the change in version numbering (emphasis and strikethrough in original):

Update: Office 2019 and Office 365

As of Office 2019, MSI-based setup are no longer available, Click-To-Run is the only way to deploy Office now. Together with this change towards the regularly updated Office 365, also the major/minor version numbers of Office are no longer updated (at least for the time being). That means that – even for Office 2019 – the value used in Registry keys and the value returned by Application.Version (e.g. in Word) still is 16.0.

For the time being, there is no documented way to distinguish the Office 2016 from Office 2019. A clue might be the file version of the winword.exe; however, this version is also incremented for patched Office 2016 versions (see the comment by @antonio below).

If you need to distinguish somehow between Office versions, e.g. to make sure that a certain feature is present or that a minimum version of Office is installed, probably the best way it to look at the file version of one of the main Office applications

Dirk–like so many of the rest of us–tried and failed to find a reliable way to distinguish between Office versions 2016 and later.

It's not that we haven't found a solution to the problem: it's that the problem simply CANNOT be solved.

One Code Base - Many Versions

The problem is that we are all operating on a faulty assumption.

We are assuming that Office 2016, Office 2019, Office 2021, and Office/Microsoft 365 are all different code bases. THEY ARE NOT.*

^{* I don't think. Please refer to my original disclaimer above.}

Microsoft realized that maintaining multiple code bases–especially ones that are substantially similar to each other–is pure madness.

Think about it. Every vulnerability that requires a security fix would require updating every code base that suffers from the vulnerability. That would also mean running a test suite against multiple code bases. And deploying updates to multiple code bases.

But wait! you protest. How can Office 2016 and Office 2021 be using the same code? Wouldn't that mean that every new feature introduced in Office 2021 would be available to Office 2016 users? Why would anyone ever upgrade if that were the case?

Feature Gates: An Application Paywall

We're all familiar with the "paywall" concept in modern online journalism.

Many publications post two different types of content:

Public content, which is free to everyone
Premium content, which sits behind a "paywall" and is only available to paying subscribers

Microsoft Office uses this same concept to keep certain features behind a paywall based on the nature of the purchased license. In software development, this concept is known as a feature gate (or feature toggle, as Wikipedia prefers):

A feature toggle in software development provides an alternative to maintaining multiple feature branches in source code. A condition within the code enables or disables a feature during runtime. In agile settings the toggle is used in production, to switch on the feature on demand, for some or all the users. Thus, feature toggles do make it easier to release often.

...

Feature toggles are essentially variables that are used inside conditional statements. Therefore, the blocks inside these conditional statements can be toggled 'on or off' depending on the value of the feature toggle. This allows developers to control the flow of their software and bypass features that are not ready for deployment.

Reading the Tea Leaves

So where exactly does Microsoft document this behavior?

Good question! I'm not sure they do, at least not directly. However, once you start looking for them, the signs are everywhere:

Office stopped getting new code versions at 16.0
Bug fixes can be rolled out in under 24 hours and users don't even need to update their software--just close and reopen it!
Security fixes are often simultaneously released on multiple Office versions
The official way to know if a feature is available at runtime in recent versions of Office is to just try it and handle the error if it fails
Features are unlocked by updating the Office license, usually with no additional software download required

Reader Feedback

As I said at the beginning, this article was a series of educated guesses. Please let me know in the comments below how my theory lines up with your experience. I'm especially interested in any official Microsoft sources that confirm or refute my theory.