Microsoft to Disable VBScript in IE 11 in Windows 7 and 8.x

Posted on August 3, 2019 by Paul Thurrott in Cloud, Dev, Windows with 15 Comments

Continuing a years-long push to phase out its insecure legacy technologies, Microsoft has announced a new milestone for VBScript. This month, it will disable VBScript by default in Internet Explorer 11 running under Windows 7, 8, and 8.1.

“The change to disable VBScript will take effect in the upcoming cumulative updates for Windows 7, 8, and 8.1 on August 13, 2019,” the Microsoft Edge team revealed. “VBScript will be disabled by default for Internet Explorer 11 and [web browser controls] for Internet and Untrusted zones on all platforms running Internet Explorer 11. This change is effective for Internet Explorer 11 on Windows 10 as of the July 9th, 2019 cumulative updates.”

For those unfamiliar with VBScript, it’s a scripting language based on classic Visual Basic that first launched in 1996 alongside JScript, Microsoft’s 90s take on JavaScript. VBScript could be used on both the client- and server-sides on the web, but because the client version was only supported in Internet Explorer, it didn’t gain much traction against JavaScript, which was universally supported. VBScript did see some success on the server, however, as it could be used to power database-backed websites running on Microsoft’s Internet Information Server (IIS) using Active Server Pages (ASP).

VBScript was also used for writing scripts—basically more modern versions of MS-DOS batch files—that ran under the Windows Scripting Host (WSH) starting in Windows 95 (later renamed Windows Script Host). And it was briefly used as a scripting language in just one Microsoft Office application, Outlook 97. It was even used in Windows CE.

But by the turn of the century, Microsoft was transitioning to .NET and VBScript was left behind. Microsoft transitioned Office to Visual Basic for Applications (VBA), it utilized Visual Basic .NET for both client- and server-side development, and it eventually replaced WSH with PowerShell. By the 2010s, Microsoft explained that VBScript was deprecated and “should no longer be used as a scripting language.” It was only permitted for websites rendered in legacy document modes, and then only in IE 11.

In 2017, Microsoft released a cumulative update for Windows 10 that included an option for blocking VBScript execution in IE 11 for all document modes. And it noted that it would disable VBScript entirely in some future update. That day has arrived: Microsoft disabled VBScript by default in IE 11 on Windows 10 in July, and it is doing so today on all remaining supported Windows versions.

“Should you still need to utilize this legacy scripting language, the settings to enable or disable for VBScript execution in Internet Explorer 11 will remain configurable per site security zone, via Registry, or via Group Policy,” Microsoft notes.

Normally, I would assume that once IE 11 is no longer supported, Microsoft would officially kill VBScript for good. But IE 11 will be supported for the supported life of Windows 10, which is currently indefinite. I assume that will have to change at some point. But for now, VBScript continues forward, albeit in dramatically diminished form.

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (15)

15 responses to “Microsoft to Disable VBScript in IE 11 in Windows 7 and 8.x”

  1. MikeGalos

    Actually, JScript became the standard (ECMA 262) for the proprietary Javascript because, among other things, it was Y2K compliant. Javascript, despite being designed in the mid-1990s, treated all years as "19" + the 2-digit year.

    What you use today as Javascript really is the Microsoft version.

  2. webdev511

    I had that book and used it too. Got me started with ASP 1.0 page development which I rode all the way to ASP 3.0.

  3. skane2600

    Hopefully outside of IE, it is still supported on Windows (although what is inside and outside IE is ill-defined). VBScript has automation capabilities that VBA doesn't have, namely the ability to automate Office programs (and others) from the outside. Also it was a option that avoided all the version issues that plagued .NET.

    It obviously wasn't something you'd use to create a stand-alone application of any significance but as a scripting language it was quite useful.

    • hrlngrv

      In reply to skane2600:

      Fairly common in advanced Excel and Access VBA to include references for regular expressions and scripting DLLs to gain access to those capabilities in VBA. It'd be a major step backwards to remove those DLLs from Windows. Unless MSFT intended to make Office for Windows as underpowered as Office for Macs.

  4. hrlngrv

    Meta: I got an error trying to post the comment below when I had included dot and EXE following CMD. When I deleted the extension, posting worked. That's some awfully fussy text filtering.

    • hrlngrv

      VBScript was MSFT's response to Unix-originated scripting languages. Python won that particular war.

      FWIW, I was tasked with converting some front-ends from batch files to VBScript. VBScript was more of a PITA for several things, especially for what CMD batch files could handle.

      This had better not mean removing the Windows Script Host (actual name, not Scripting) DLLs. Excel may be getting regular expression functions, but the Dictionary object is very useful in VBA.

      • skane2600

        In reply to hrlngrv:

        VBScript support being included as part of Windows' standard install made the existence of other scripting languages somewhat moot on Windows. Not a matter of quality or power, but of practicality.

        Yes, the potential removal of wscript.exe was what I was concerned with along with mshta.exe.

        • hrlngrv

          In reply to skane2600:

          Unless cscript.exe is just a hardlink for wscript.exe, I'd want it retained as well. With the sole exception of an input box calculator, I've never written or used a WSH script with any interactivity.

          My main concern is vbscript.dll and scrrun.dll, both of which are frequently used to add functionality to Excel and Access.

      • wright_is

        In reply to hrlngrv:

        The article only says it is being removed from IE.

        • skane2600

          In reply to wright_is:

          The concern stems from the fact that a number of these technologies were bundled as part of IE (recall MS's legal argument was that removing IE would break Windows) and thus could be in jeopardy depending on how Microsoft plays it.

        • hrlngrv

          In reply to wright_is:

          Perspective is important. From the perspective of someone who used Excel on a daily basis and maintains a lot of VBA code, the form of deprecation of the SQLREQUEST add-in makes it prudent to be concerned for the worst.

  5. sharpsone

    RIP vbscript you saved my ass many times.

  6. harris0n

    Paul, VBScript is alive and well on the server side (as you know?). My company's site source code contains thousands of lines of it, among newer code. And my company is not alone. The prospect of 'officially killing VBScript for good'? - nowhere near reality. The story is spooking executives, for no reason other than an unfamiliarity with client-side / server-side concepts.

  7. gelfer

    Hey Paul, a new experience: dutch book title written by you! Did not know it existed. Maybe your Amsterdam house-swap friend helped with the translation?

    BTW: keep up the good work on this site & the programming windows series, I'm really enjoying them and learning a lot!