Service Control Manager Versions

The SERVICES.EXE program appears only in NT versions of Windows. Each new Windows package brings at least a change of the minor version number.

Builds

The following builds have been inspected for these notes. Most are from MSDN discs. Some, especially since Microsoft greatly reduced its shipment of operating systems on MSDN discs, are from service packs downloaded (typically as self-extracting executables) from a Microsoft website.

Special mention must be made of the very oldest builds. Even among the many discs that I retain from MSDN subscriptions in the mid-1990s, what was then the new Windows that is entirely its own operating system rather than a large DOS program goes no further back than Windows NT 3.51. For all practical effect, Microsoft informally disowned the early versions, even for its so-called Archive editions. For decades I had little choice but to treat Windows NT 3.51 as the dawn of time for these notes. In 2017 someone pointed me to an online collection of earlier builds. The sample is inevitably incomplete. The provenance is unknown. I have since sought more: the WinWorld online museum is notable.

Builds are arranged in increasing order of the file version as recorded in the executable’s resources. This version number is readily visible using Windows Explorer either in a so-called infotip for the file or by accessing the Version tab in the Properties dialog for the file. Programmers know this version number as coming from the so-called root block of the version-information resource, specifically from the dwFileVersionMS and dwFileVersionLS members of a VS_FIXEDFILEINFO structure.

The date stamp shown for each version is more obscure. File dates are easily modified after the executable is built and are anyway liable to be shown differently when read from different time zones. However, there is in each executable’s header a date stamp which is set when the executable is built and which is not commonly changed afterwards. It is readily accessible to anyone with programming knowledge and appropriate tools, e.g., Microsoft’s own DUMPBIN utility.

Any one-person study of Windows—and please remember that the list below exists only as a catalogue of which builds I have obtained for study—is much too intensive for practical coverage of pre-release builds, hot fixes and other updates.

Access to pre-release builds anyway tends to come with constraints and compromise that other researchers may tolerate (and even be happy with) but which I do not. None of this work is done with any sort of assistance from Microsoft beyond the binaries, as published by the tens and even hundreds of millions, and the same documentation and other support, e.g., public symbol files for debugging, that’s available to all Windows programmers.

There seems to be no SERVICES.EXE in Windows 2000 Service Packs 1 or 2. The binaries distributed with the original Windows XP and Service Pack 1 are identical.

Assemblies

Starting with Windows Vista, there is also a copy of SERVICES.EXE among the assemblies. The assembly identity is Microsoft-Windows-Services-ServiceController.

An assembly is represented by an executable and a manifest. Both are in the tree beneath the WinSxs subdirectory of the Windows directory. The executables are all named the same, but different versions can be in different subdirectories. The executable in the subdirectory named assembly has the manifest named assembly.manifest in the Manifests subdirectory.

In practice, the SERVICES.EXE that gets executed is the one in the Windows system directory.