VBScript

VBScript is the most widely deployed programming language that almost nobody chose. It arrived in 1996 as a browser feature, was installed by default on every desktop Windows machine from Windows 98 onward, became the automation language of an entire industry by being the thing that was already there, and has been slowly dismantled ever since. Microsoft stopped developing the engine in 2000, shipped its last version in 2009, switched it off in the browser in 2017, formally deprecated it in 2023, and published a three-phase plan in 2024 that ends with the DLLs being deleted from Windows.

It is a subset of Visual Basic with the compiler, the forms designer, the type system and the standard library taken out. What is left is a small procedural language with exactly one data type, and a function called CreateObject that hands you the entire Component Object Model. Almost everything VBScript is famous for - good and bad - follows from that second thing.

Option Explicit

Dim fso, folder, file
Set fso = CreateObject("Scripting.FileSystemObject")
Set folder = fso.GetFolder("C:\Logs")

For Each file In folder.Files
    If LCase(fso.GetExtensionName(file.Name)) = "log" Then
        If DateDiff("d", file.DateLastModified, Now) > 30 Then
            WScript.Echo "Deleting " & file.Path
            file.Delete
        End If
    End If
Next

A dozen-odd lines, no imports, no build step, no dependencies, and it runs by double-clicking. That is the whole argument for VBScript, and for twenty-five years it was a good one.

Where the language came from

VBScript is the third member of a family. Visual Basic, shipped in 1991, was the product; Visual Basic for Applications, from 1993, was the same language embedded in Office; VBScript, from 1996, was the same language again, cut down far enough to be safe to run inside a web browser and small enough to download. Microsoft’s own Windows CE documentation describes it plainly as “a subset of the Visual Basic programming language… a fast, portable, lightweight interpreter”, and the MSDN introduction is franker still: “If you already know Visual Basic or Visual Basic for Applications (VBA), VBScript will be very familiar.”

The cutting was aggressive. There is no Type statement, no user-defined enumerations, no fixed-length strings, no Variant-free declarations - in fact no type declarations at all, since Dim x As Long is a syntax error. File I/O, which in Visual Basic was in the language, is gone; you get it from a COM object instead. Early binding is gone. The GoSub/Return and Line Input verbs of the old dialects are gone. What remains is small enough to learn in an afternoon if you have ever written any BASIC at all.

The context for the release was the browser war. Microsoft shipped VBScript and JScript together as the two halves of what it called Windows Script Technologies, and its documentation of the period reads like an attempt to make VBScript a standard by giving it away:

As a developer, you can license VBScript source implementation at no charge for use in your products. Microsoft provides binary implementations of VBScript for the 32-bit Windows API, the 16-bit Windows API, and the Macintosh.

That offer went nowhere. Netscape never implemented it, Opera never implemented it, and the browsers that came later - Firefox, Chrome, Safari - never considered it. JScript, the sibling, was Microsoft’s dialect of the JavaScript that Netscape submitted to Ecma, and Microsoft took part in the ECMAScript standardisation that followed; VBScript was never standardised by anyone and never had a second implementation of consequence. Client-side VBScript was a single-vendor dialect from the day it shipped, and every serious web developer learned that lesson within a couple of years.

The pivot that saved it: ASP and Windows Script Host

What rescued VBScript was that Microsoft put it on both ends of the wire and then in the operating system.

In December 1996, Active Server Pages 1.0 shipped in Internet Information Server 3.0 with VBScript as the default server-side language. Nobody had to care what browser the visitor was running; the script executed on the server and emitted HTML. Classic ASP is the reason VBScript appears on résumés. Microsoft’s version table records IIS 3.0 as carrying VBScript 2.0, and IIS 4.0 - a year later - as carrying 3.0, in step with Internet Explorer 4.0 for the first time.

The second and more durable pivot was Windows Script Host, which arrived in the Windows NT 4.0 Option Pack and then in Windows 98. WSH gave .vbs files a double-click execution model with no browser and no web server involved, and suddenly the language that had been designed for animating web pages was the most convenient way to write a logon script. Wikipedia’s summary is accurate: VBScript “has been installed by default in every desktop release of Microsoft Windows since Windows 98” and in Windows Server since the NT 4.0 Option Pack.

From there, VBScript’s real standard library turned out to be COM. The language itself has about ninety functions. Everything interesting comes from objects created at run time by name:

None of that is VBScript. All of it is reachable from VBScript in one line, from a text file, with no installation. That is the entire value proposition, and it explains both why the language was adopted so widely by people who were not programmers and why it turned out to be so dangerous.

One data type

The single most consequential design decision in VBScript is stated in the first sentence of Microsoft’s own data types page:

VBScript has only one data type called a Variant. A Variant is a special kind of data type that can contain different kinds of information, depending on how it is used.

A Variant carries a subtype - Empty, Null, Boolean, Byte, Integer, Currency, Long, Single, Double, Date, String, Object, Error - and converts itself as context demands. "10" + 5 is 15. "10" & 5 is "105". If x = "" Then is true for an uninitialised variable. IsEmpty, IsNull, IsNumeric, IsObject, IsArray, IsDate and VarType exist because you routinely need to ask what you are actually holding.

Two consequences shaped how VBScript is written in practice.

The first is Option Explicit, present since version 1.0. Without it, a misspelled variable name silently creates a new empty variable, and the class of bug this produces in a 500-line administrative script is genuinely hard to find. Every VBScript style guide ever written opens with the same instruction, and it is the closest thing the language has to a compiler.

The second is Set. Because a Variant can hold an object reference or a value, and because assignment of an object must be distinguished from assignment of its default property, object assignment requires a keyword:

Set conn = CreateObject("ADODB.Connection")   ' object assignment
name = conn.DefaultDatabase                    ' value assignment

Forgetting Set produces Object required or, worse, silently assigns a default property. It is the single most common error a VBScript beginner makes, and it is a direct tax on having one data type instead of two.

Error handling is the other place where the smallness shows. There is no Try/Catch. There is On Error Resume Next, which suppresses the error and sets a global Err object, and On Error GoTo 0, which restores normal behaviour:

On Error Resume Next
Set svc = GetObject("winmgmts:\\" & host & "\root\cimv2")
If Err.Number <> 0 Then
    WScript.Echo host & ": " & Err.Description
    Err.Clear
    On Error GoTo 0
    Exit Sub
End If
On Error GoTo 0

Used with discipline this is workable. Used the way it usually is - one On Error Resume Next at the top of the file, never turned off - it converts every failure in the script into a silent wrong answer. A great many production VBScripts are written that way.

What version 5.0 added, and why it was the last real one

The 1999 release with Internet Explorer 5.0 is the only version that substantially changed the language rather than the plumbing. Microsoft’s feature table dates all of the following to 5.0:

• Classes. Class, Property Get, Property Let, Property Set, Class_Initialize, Class_Terminate. No inheritance, no interfaces, no static members - but enough to write something you could call an object.
• Regular expressions. The RegExp object, with Pattern, Global, IgnoreCase, Test, Execute and Replace. Version 5.5 added SubMatches, which finally let a script read the captured groups - a capability JScript already had.
• With, for repeated member access on one object.
• Eval, Execute and ExecuteGlobal, which run source text constructed at run time. Powerful, occasionally necessary, and a standing gift to malware authors who want their payload to be an obfuscated string.
• GetRef, function pointers, which made event handlers and callbacks expressible.

Class LogEntry
    Private m_when, m_text

    Private Sub Class_Initialize()
        m_when = Now
    End Sub

    Public Property Let Text(value)
        m_text = value
    End Property

    Public Property Get Line()
        Line = FormatDateTime(m_when, vbGeneralDate) & vbTab & m_text
    End Property
End Class

Dim e
Set e = New LogEntry
e.Text = "service restarted"
WScript.Echo e.Line

And then it stopped. In 2000, an MSDN article by Microsoft’s Andrew Clinick titled “What About VBScript?” explained that with the .NET Framework arriving, the scripting team would carry VBScript forward through ASP.NET rather than extend the engine, and that no new versions of the VBScript engine would be developed. Responsibility moved to a sustaining engineering team whose job was bug fixes and security. Everything after that - 5.1, 5.5, 5.6, 5.7, 5.8 - is maintenance, host integration and servicing, not language design. The 5.8 engine that shipped with Windows 7 in 2009 is, feature for feature, the 1999 language.

Wikipedia’s infobox claims a version 6.0 released in September 1998. Microsoft’s version table lists no such release, and the numbering makes it impossible: 5.8 comes after 1998’s 4.0. There was never a VBScript 6.0.

ILOVEYOU, and what it cost

On 4 May 2000 a VBScript file called LOVE-LETTER-FOR-YOU.TXT.vbs arrived in inboxes worldwide. It automated Outlook to mail itself to every entry in the victim’s address books, overwrote files by extension, and spread faster than any malware before it. CERT Advisory CA-2000-04, issued the same day, reported more than 250 sites and over 300,000 individual systems affected by two in the afternoon, Eastern time. The Anna Kournikova worm, built with a point-and-click VBScript worm generator, followed in February 2001.

Nothing about ILOVEYOU exploited a bug. It used documented features exactly as designed: Windows Script Host executed a double-clicked .vbs file with the user’s full privileges, the file created an Outlook.Application object with CreateObject, and the object model let it read the address book and send mail. Windows hid the .vbs extension by default, so the file appeared to be LOVE-LETTER-FOR-YOU.TXT. The properties that made VBScript so useful to administrators - no installation, no compilation, no sandbox, total access to COM - are the same properties that made it the ideal malware vehicle.

The industry’s response reshaped Windows: attachment blocking in Outlook, software restriction policies, group policy controls over Windows Script Host, and eventually the extension-based blocking that every mail system now performs by default. VBScript never recovered its reputation. Two decades later, when Microsoft finally announced deprecation, most of the commentary treated it as overdue on security grounds - and the engine had gone on producing evidence, as with CVE-2018-8174 in May 2018, a use-after-free in the VBScript engine exploited in the wild through Internet Explorer and Office documents before the patch shipped.

The long removal

The end of VBScript has been unusually well documented, which is rare for a language and worth setting out precisely.

In the browser. In April 2017 Microsoft made VBScript execution in Internet Explorer 11 configurable per security zone, documented in KB4012494. In July 2017 it announced that from the Windows 10 Fall Creators Update, VBScript would be disabled by default in the Internet Zone and the Restricted Sites Zone. With Internet Explorer itself retired from Windows 10 in 2022, client-side VBScript on the web is finished.

In the operating system. In October 2023 VBScript appeared on the Windows deprecated-features list: “VBScript is deprecated. In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system.”

The schedule. On 22 May 2024 the Windows IT Pro Blog published the phases:

Microsoft’s recommended replacements are PowerShell for automation and installer custom actions, and JavaScript for anything web-facing. The blog post also spells out a case many organisations had not thought about: VBA in Office can call .vbs scripts directly, and can reference the VBScript type library - the regular-expression object in particular - so a great deal of Excel and Access code that nobody thinks of as VBScript will fail in Phase 3.

Where it actually still runs

Deprecated is not the same as gone, and in September 2026 VBScript is a live dependency in more places than its obituaries suggest.

• Classic ASP applications. IIS still ships an ASP role feature, and line-of- business web applications written between 1997 and 2005 are still serving pages inside corporate networks.
• Test automation. OpenText UFT One - the tool that was Mercury QuickTest Professional, then HP, then Micro Focus - has used VBScript as its test language since QuickTest Professional appeared in the early 2000s and still documents it as such, with Python offered alongside only in recent releases. Enterprise regression suites representing many thousands of person-hours are VBScript source.
• Installers. MSI custom actions written in VBScript are embedded in shipping products whose vendors may no longer exist.
• Administrative scripts. Logon scripts, WMI inventory scripts and ADSI reporting scripts that have run untouched for fifteen years, precisely because nothing ever forced anyone to touch them.

Anyone planning for Phase 2 has a straightforward if tedious task: find the .vbs, .wsf, .hta and .asp files, find the MSI custom actions, find the VBA that references the VBScript type library, and decide what happens to each one. The people who wrote them have generally moved on.

Why it matters

VBScript is the clearest case study available in how a language wins by distribution rather than by design.

Judged as a language, it is unremarkable and in places poor: one data type, no inheritance, no exception handling worth the name, no module system, no package manager, no standard library beyond what COM provides, and a design frozen in 1999. It was never standardised, never had a second implementation, and never had a community outside the Microsoft ecosystem.

Judged by reach, it is one of the most successful languages ever shipped. It was present on essentially every Windows desktop and server for a quarter of a century. It taught a generation of system administrators to program - people who would never have called themselves developers, who found they could automate their jobs with a text file and a double click, and some of whom are now software engineers because of it. It was the server-side language of a large fraction of the commercial web during the years the commercial web was being invented.

And it stands as the canonical demonstration that convenience and security are the same lever pulled in opposite directions. Everything that made VBScript useful - zero installation, zero ceremony, full access to the machine from an unsigned text file - is precisely what made ILOVEYOU possible and what has kept the engine on security teams’ lists for twenty-five years. Microsoft’s replacements learned the lesson: PowerShell shipped with an execution policy and signing infrastructure from the start, and the browsers that outlived Internet Explorer sandbox their scripting engines aggressively.

The three-phase plan will finish sometime after 2027. When the DLLs finally come out of Windows, it will close a language that was designed for a browser war that was effectively over by the early 2000s, frozen by a strategy decision made in 2000, kept alive by sheer installed base for another two decades, and used - by people who mostly did not know they were programming - to run a very large part of corporate computing.