InstallScript

InstallScript is a proprietary, C-like scripting language built into InstallShield, the long-running Windows installer-authoring tool. It exists to do one job well: describe what happens when a user runs a software setup. Rather than being a general-purpose language, InstallScript pairs a familiar procedural syntax with a very large library of installation-specific built-in functions — for copying files, writing the registry, registering services, showing wizard dialogs, and managing uninstall logs — and an event-driven model in which the InstallShield engine calls your code at well-defined points in the install sequence. For much of the 1990s and 2000s, when most Windows software arrived on disc with a setup wizard, that wizard was very often an InstallShield program scripted in InstallScript.

History & Origins

The Stirling Group (1987–1993)

InstallScript’s lineage begins with The Stirling Group, founded in December 1987 by Viresh Bhatia and Rick Harold, both Northwestern University alumni, working out of a basement office in Roselle, Illinois. By 1990 the company was marketing the SHIELD Series, a bundle of six products that included InstallShield — the installer toolkit that InstallScript is the scripting layer for. In 1993 the company relocated to Schaumburg, Illinois and renamed itself Stirling Technologies, Inc.

The exact debut year of the InstallScript language as a distinct, named feature is not precisely documented in primary sources. What is clear is that InstallShield originated around 1990 and that a scriptable, C-like authoring language was an established part of the product through the InstallShield 3 era of the mid-1990s. The 1993 year used here should be read as an approximate anchor to the early-to-mid 1990s period in which the language took the form recognized today, not as a verified first-release date for InstallScript specifically.

The Windows 95 Breakthrough

InstallShield’s defining moment came with Windows 95. As Microsoft pushed a consistent setup experience for the new platform, InstallShield became a recommended installation tool, and its adoption exploded. By 1997 Stirling Technologies estimated that InstallShield was used in roughly 85 to 90 percent of all software written for Windows — a remarkable share that made InstallScript, by extension, one of the most widely shipped (if not most widely written) languages of the era. From 1996 onward the company increasingly operated under the InstallShield name.

Corporate Journey: Macrovision → Acresso → Flexera → Revenera

The product changed hands several times. Macrovision acquired the InstallShield business in 2004 for $76 million in cash plus up to an additional $20 million tied to sales targets. On April 1, 2008, Thoma Cressey Bravo acquired Macrovision’s Software Business Unit, forming Acresso Software, which was renamed Flexera Software in October 2009. In May 2020, Flexera rebranded its installation division as Revenera, which continues to develop InstallShield today — the latest release, InstallShield 2025 R2, shipped on December 11, 2025, and still includes the InstallScript language.

Design Philosophy

InstallScript is unapologetically a domain-specific language. Its design assumes you are writing an installer, and it optimizes for that:

• Familiar surface, focused purpose. The syntax is deliberately close to C so that working programmers can be productive quickly, while the standard library is dedicated almost entirely to setup tasks rather than general computing.
• Event-driven by default. In a modern InstallScript project, you rarely write a top-to-bottom program. Instead you implement event functions — OnBegin, OnFirstUIBefore, OnMoving, OnEnd, and many more — that the InstallShield engine invokes in a fixed order. This lets the engine own the overall install flow while your code customizes individual stages.
• Batteries included for installers. Hundreds of built-in functions cover file transfer, registry editing, INI files, shortcuts, services, the uninstaller, system queries, and a complete set of standard wizard dialogs (the Sd* family such as SdWelcome and SdLicense).
• High-level, but with an escape hatch. When the built-ins are not enough, InstallScript can call into the Windows API and the Windows Installer (MSI) API, so authors can drop down to lower-level platform calls without leaving the language.

Key Features

A C-like Syntax with Pascal Accents

InstallScript looks mostly like C, with some traits borrowed from Pascal. Variables are declared with explicit types in a declaration block before the function body, and function bodies are delimited by begin and end rather than braces:

// A simple InstallScript event function
function ShowGreeting()
    STRING szTitle, szMsg;
    NUMBER nResult;
begin
    szTitle = "Welcome";
    szMsg   = "Hello, World! Ready to install?";

    nResult = MessageBox(szMsg, INFORMATION);

    return nResult;
end;

A bare, procedural script can also be written between program and endprogram for simpler setups:

program
    Disable(BACKGROUND);
    MessageBox("Hello, World!", INFORMATION);
endprogram

Data Types

InstallScript uses a small set of built-in types, including:

Typing is static in that variables are declared with a type, but the language performs implicit conversions in many contexts, giving it a looser feel than strict C.

Event Functions and the Install Sequence

The heart of a modern InstallScript project is its set of event handlers. The engine calls them in a defined order, so customizing an installer is largely a matter of filling in the right event:

function OnFirstUIBefore()
    NUMBER nResult;
    STRING szTitle, szMsg, szLicenseFile;
begin
    // Standard welcome dialog
    szTitle = "";
    szMsg   = "";
    nResult = SdWelcome(szTitle, szMsg);
    if (nResult = BACK) then
        // handle the user going back
    endif;

    // Show the license agreement
    szLicenseFile = SUPPORTDIR ^ "license.txt";
    nResult = SdLicense2(szTitle, "", "", szLicenseFile, FALSE);
end;

Note the Pascal-style if ... then ... endif and the ^ operator, an InstallScript convenience for joining path components.

Preprocessor, Prototypes, and Headers

Like C, InstallScript has a preprocessor and a forward-declaration convention. Scripts use #include to pull in header files (.h) and #define for constants, and functions are forward-declared with the prototype keyword before they are defined:

#include "ifx.h"

#define COMPANY_NAME  "Acme Software"

prototype ShowDialogs();
prototype HandleError(NUMBER);

Built-in Library

The standard library is what makes InstallScript an installer language rather than a general one. Representative families include:

• File and directory operations: CopyFile, XCopyFile, CreateDir, DeleteDir, FindFile.
• Registry: RegDBSetDefaultRoot, RegDBSetKeyValueEx, RegDBGetKeyValueEx.
• Standard dialogs (Sd*): SdWelcome, SdLicense2, SdAskDestPath, SdFinish, plus generic MessageBox and SprintfBox.
• Services and system: functions to install and query Windows services, and GetSystemInfo / GetEnvVar for environment queries.
• Windows Installer APIs: callable from a main script and, importantly, from inside an InstallScript custom action embedded in an MSI package.

Project Types

InstallShield exposes InstallScript through a few project types, and the choice shapes how much control the language has:

Evolution

InstallScript’s biggest external pressure was the arrival of Microsoft’s Windows Installer (MSI) around the turn of the millennium. MSI introduced a declarative, database-driven model for installations that Microsoft promoted as the standard for Windows software, complete with transactional install/rollback and centralized management. Rather than abandon its scripting heritage, InstallShield bridged the two worlds with the InstallScript MSI hybrid project type and with InstallScript custom actions, letting authors keep their procedural logic and rich UI while gaining MSI’s data engine and system integration.

Over successive InstallShield releases, the language and its tooling accumulated support for newer Windows realities — 64-bit targets, modern UI dialogs, suite/advanced installers that chain multiple packages, and, more recently, MSIX packaging alongside traditional MSI. The core language, however, has stayed remarkably stable: a function ... begin ... end; block and an OnFirstUIBefore handler from years ago still read naturally in a current project.

Current Relevance

InstallScript is firmly in the “specialized but actively maintained” category. It is not a language anyone picks up for general programming, and Microsoft’s tooling has steered much of the ecosystem toward MSI and MSIX. Yet InstallShield remains a commercial, actively developed product under Revenera, with InstallScript shipping as part of the latest InstallShield 2025 R2 release. Its continued relevance comes from two directions:

• Legacy maintenance. An enormous body of existing installers — across commercial software, games, and enterprise deployments — is written in InstallScript, and those products still need updates, patches, and rebuilds.
• Hard cases in modern packaging. Even teams committed to MSI or MSIX reach for InstallScript custom actions when an installation needs imperative logic, complex conditionals, or platform calls that the declarative formats handle poorly.

A long-running community ecosystem (sites like InstallSite and Revenera’s own forums and language reference) continues to document patterns, pitfalls, and samples accumulated over decades of real-world setup authoring.

Why It Matters

InstallScript is a case study in how a tightly focused, domain-specific language can achieve enormous reach without ever being a “popular” general-purpose language:

1. It rode a platform inflection point. By being the recommended way to build setups in the Windows 95 era, InstallScript ended up inside a huge fraction of Windows software, shaping the first-run experience that millions of users had with new programs.
2. It proved the value of a setup-specific language. Treating installation as its own problem domain — with first-class functions for files, registry, services, and wizard dialogs — let teams build robust installers far faster than hand-coding the same logic in C or C++.
3. It aged by bridging, not breaking. When MSI threatened to make procedural installers obsolete, InstallScript adapted via hybrid projects and custom actions, demonstrating how a language can stay useful by integrating with the standard that succeeded it rather than fighting it.

For anyone studying the history of Windows software, InstallScript is a quietly ubiquitous thread: the language behind the “Welcome to the Setup Wizard” screen that defined how a generation of programs got onto people’s machines.