KiXtart
A free-format logon script processor and enhanced batch language for Windows, begun in 1991 by Ruud van Velsen of Microsoft Netherlands as a spare-time project and adopted by a generation of LAN Manager and NT domain administrators.
Created by Ruud van Velsen, a Microsoft Netherlands (Benelux) employee who began KiXtart in 1991 as a spare-time project and has maintained it personally ever since
KiXtart is a free-format scripting language for Microsoft Windows, described by its own documentation as “a logon script processor and enhanced batch scripting language.” Begun in 1991 by Ruud van Velsen of Microsoft Netherlands as a spare-time project, it filled a gap that Microsoft’s own tooling left wide open for more than a decade: native LAN Manager and Windows NT logon scripts were plain batch files, and batch files could not easily read the registry, query group membership, or ask who was logging in from where. KiXtart could, in a few readable lines. Its name is a portmanteau of “kick start,” and that is exactly what it gave Windows network administration - years before Windows Script Host, and a decade and a half before PowerShell.
; KiXtart logon script
IF InGroup("Domain Admins")
USE Z: "\\server\admin$"
ENDIF
USE P: "\\server\public"
? "Welcome, " + @FULLNAME
History and origins
KiXtart began in 1991, when Ruud van Velsen - an employee of Microsoft’s Netherlands (Benelux) subsidiary - wrote the first version in his spare time to provide real logon scripting for Microsoft LAN Manager networks. It was never a Microsoft product and was never officially supported by Microsoft; it was one engineer’s tool that happened to solve a problem thousands of administrators shared. Its simplicity and the near-total lack of competition made it popular with LAN Manager administrators almost immediately.
The decisive moment in its spread came in the mid-1990s, when Microsoft included KiXtart (as “KiXtart 95”) in the Windows NT Server Resource Kit. Installing the Resource Kit placed the KiXtart files in the Ntreskit\Kix95 directory, and official Microsoft Knowledge Base articles - Q162793, “How to Set Up KiXtart Logon Scripts for a Windows 95 Client,” and Q175732, “Installing and Using the KiXtart Login Processor Tool” - walked administrators through deploying it. For a personal side project, this was extraordinary placement: the Resource Kit sat on the shelf of essentially every serious NT shop, and KiXtart rode it into corporate networks worldwide.
Van Velsen distributed KiXtart as careware: the software is free and closed-source, and users are asked to show their appreciation with a charitable donation rather than a license fee. He has maintained it personally for its entire life - a continuity of individual stewardship spanning more than three decades, from LAN Manager to Windows 10 and beyond.
Design philosophy
KiXtart’s design goal was pragmatic to the point of bluntness: give the administrator, at logon time, everything a batch file couldn’t. Three ideas define the language:
- The script knows the environment. KiXtart exposes dozens of built-in macros, prefixed with
@, that resolve to live system facts:@USERID(the logon name),@FULLNAME,@WKSTA(the workstation),@LDOMAIN(the logon domain), and many more. A logon script rarely needs to shell out or parse anything - the answers are simply there. - Enhanced batch, not a new world. Variables are
$-prefixed and need no declaration; the language is free-format and forgiving about layout;?prints a line. An administrator who knew batch files could read a KiXtart script on first sight and write one within the hour. The learning curve was the feature. - Conditions over configuration. The core idiom is conditional logic against identity:
IF InGroup("Accounting") USE Q: "\\server\acct" ENDIF. One script, checked into the NETLOGON share, could express an entire organization’s drive mappings, printer connections, and per-group settings.
Beyond that core, the built-in function library reached deep into Windows: reading and writing the registry, connecting and disconnecting network drives and printers, setting environment variables, launching programs, and displaying message boxes. Later versions opened the door to the whole COM universe - ADSI for directory queries, ADO for databases, WMI for hardware and OS inventory - so the same unassuming logon language could interrogate Active Directory or enumerate installed software.
Key features
Macros and variables
The @-macro system is KiXtart’s signature. Where a batch file author had to fight %VARIABLES% and external utilities to learn who was logging in, KiXtart made user, machine, network, and OS facts first-class citizens of the language. User variables ($name) are dynamically typed and coexist cleanly with the macro namespace.
User-defined functions and COM automation
KiXtart 2001 (version 4.00, November 2001) transformed the language from a script processor into something closer to a general scripting tool. Administrators could now write their own UDFs (user-defined functions), and the community traded them enthusiastically - the kixtart.org forums accumulated a large shared library of UDFs for everything from string handling to Active Directory manipulation. The same release generation added COM automation support, putting ADSI, ADO, and WMI within reach, and new FOR loop constructs rounded out the control flow.
The surrounding toolkit
Two community-ecosystem pieces extended the language’s range. KiXforms, an object-oriented forms component, let scripts present real graphical interfaces - windows, buttons, grids - so KiXtart could power small internal tools, not just invisible logon logic. Kix2Exe packaged scripts into standalone executables for distribution. Documentation shipped in CHM, Word, and PDF formats, and the language remained notably consistent across Windows versions - scripts written for one release of Windows generally ran unchanged on the next.
Version 4.70’s engine-as-component
The most recent release, 4.70 (October 2022), made the script engine itself COM-automatable: KiXtart scripts can be invoked from VBScript and other COM hosts without rewriting - a fitting late-life feature for a language whose users’ chief asset is decades of accumulated working scripts.
Evolution
KiXtart’s release history tracks the history of Windows networking itself. The 1.x-3.x era (1991 through version 3.63 in October 2000) served LAN Manager, Windows for Workgroups, and NT 4.0 domains. The KiXtart 2001 series (4.00, November 2001, through 4.23, December 2004) modernized the language with UDFs and COM for the Windows 2000/Active Directory era. The KiXtart 2010 series carried it forward from version 4.50 (July 2005) through 4.60 (October 2007), 4.61 (September 2009), 4.66 (July 2015, adding Windows 10 support), 4.67 (October 2016), and finally 4.70 (October 2022).
What did not change is as notable as what did: one author, one closed-source codebase, one careware license, for over thirty years. KiXtart never became a foundation project, never took venture funding, never spawned a standards committee. It simply kept working.
Current relevance
KiXtart today is dormant. PowerShell - backed by Microsoft, object-oriented, and preinstalled everywhere - has been the presumptive standard for Windows automation since the 2010s, and Group Policy Preferences absorbed the drive-mapping and registry chores that were KiXtart’s bread and butter. There has been no new release since 4.70 in October 2022, and no announced roadmap.
Yet KiXtart’s retreat has been remarkably slow, because its installed base is logon scripts - infrastructure that organizations touch as rarely as possible. Scripts written in the NT 4.0 era have, in many shops, simply kept running through every domain migration since, and the language’s Windows-version independence meant they seldom broke. KiXtart remains downloadable as careware, its documentation remains available, and the accumulated UDF libraries of its community remain a working resource for anyone still maintaining it.
Why it matters
KiXtart matters for three reasons. First, it documents a real gap in computing history: for roughly the entire 1990s, the world’s dominant desktop operating system had no adequate built-in scripting for its own network logon process, and the gap was filled not by a product but by one Microsoft employee’s spare-time careware. Second, it is a case study in distribution: inclusion in the NT Resource Kit - semi-official, unsupported, but Microsoft-blessed - gave a hobby project enterprise reach that many funded products never achieved. Third, it exemplifies a species of software that rarely gets written about: the quiet administrative glue that ran corporate computing for decades. Nobody built a startup on KiXtart. But millions of Windows users, logging in on millions of mornings, got their drive letters, printers, and welcome messages from a few dozen lines of it - which is exactly the kind of load-bearing, invisible history a code archaeologist digs for.
Timeline
Notable Uses & Legacy
Windows domain logon scripts
KiXtart's defining use: at logon it mapped network drives and printers, set environment variables, wrote registry keys, and displayed messages, driven by conditions like InGroup() and macros like @USERID and @WKSTA - automation far beyond what native batch files offered LAN Manager and NT domain administrators
Microsoft Windows NT Server Resource Kit
Microsoft distributed KiXtart in its NT Resource Kits and documented it in official Knowledge Base articles (Q162793, Q175732), giving a personal side project semi-official status on countless corporate NT networks
KiXforms GUI utilities
The companion KiXforms component (kixforms.org) let administrators build graphical front-ends - forms, buttons, list boxes - on top of KiXtart scripts, turning logon-script logic into small interactive admin tools without a compiler
Admin scripting literature and community
KiXtart was prominent enough to anchor published references such as Jesse Torres's Windows Admin Scripting Little Black Book, and the kixtart.org bulletin board accumulated years of shared scripts and user-defined functions contributed by working administrators