Incredible Shrinking Windows

Microsoft Windows, as virtually everyone knows, is the dominant desktop operating system, running on some 90+ % of the world’s personal computers.  It has also established a significant presence as a server OS, although it does not dominate that space (and is conspicuously under-represented on large Internet sites).   I’ve written before about the complexity of the Windows system, in part an artifact of its development history.  That complexity works against Windows in the server world in at least two important ways:

• Complexity is the enemy of security and reliability.  More complex code has more bugs; and the bugs tend to be more subtle and difficult to find, because many of them result from interactions between different parts of the system that are poorly understood, even by the system’s developers.
• The presence of many complex interactions makes it very difficult to run just those parts of th e system that are needed for the required function.  There is no particularly compelling reason that a mail server should have a graphical user interface [GUI] for the mail administrator, but it is not possible to run Windows without a GUI.  The only kind of code that never crashes or causes security problems is code that is never run.

This issue, as one would expect, has not escaped the notice of Microsoft.  Beginning back in 2003, Microsoft assembled a project team to look at “slimming down” Windows, a project known internally as “MinWin“.  Ars Technica has a very interesting article on MinWin’s progress to date, and the challenges faced by the project team:

Windows NT served as the technological basis for what can fairly be described as the most successful and well-known software product of all time: Windows XP.

But there’s always been a dirty little secret hiding underneath that iconic field of green grass. From an engineering and security standpoint, the foundation of Windows 2000 and Windows XP is absolutely horrible.

Microsoft’s problems with security have been adequately chronicled in many places; it is noteworthy that even now, more than five years after the release of Service Pack 2 for Windows XP, the rate of discovery of new vulnerabilities has barely diminished.

Even if the security problems suddenly went away, the lack of modularity of the Windows OS would continue to be a significant issue.

By the time Windows Server 2003 was released, Microsoft had come to accept that while it was pretty good at producing a fully-featured NT-based operating system with an extensive graphical user interface, it was wholly unable to produce a fully-featured NT-based operating system without one.

Although some Windows partisans might argue otherwise, server administrators do not resist the use of GUIs solely because they are unreconstructed Luddites.  Not running a GUI on a server means not running millions of lines of code, and not experiencing the bugs that all those lines contain.  A command-driven interface is also easier for scripting (experienced UNIX/Linux server admins write scripts as a matter of course), and requires significantly fewer resources for remote administration.  (Even back in the early 1990s, we were routinely providing backup admin services from London for servers located across the Atlantic in New York City, over a 64 kbit leased line.)   But doing without the GUI in Windows was impossible:

Evidence of reliance on the presence of a graphical user interface can be seen all through older Windows 2000 and Windows XP. For example, there were no command-line tools to configure and install patches and software from Windows Update, nor was it even possible to select the updates to install without using Internet Explorer.

With more than 5500 components in the core operating system, it was effectively impossible to make changes and be sure of what the side effects would be.

The Windows Server 2008 system offered, for the first time, a “Core installation”, a slimmed-down version of Windows that included just a set of components needed on a server:

The first real manifestation of this componentization effort was the Windows Server Core installation option in Windows Server 2008. The Server Core pitch is simple and compelling enough—it’s still Windows, but without the vast majority of the desktop components that have no place on a dedicated server.

This was a big step forward, but there was still a lingering problem: even the Core installation was enormous, in comparison to a server installation for competing operating systems.

Microsoft says there are still about 600 interconnected DLLs and other binaries, totaling hundreds of megabytes. None of these could be safely removed without causing other parts of the system to break. Even Mark Russinovich, widely regarded as one of the world’s top experts on Windows internals, admits that they still can’t predict what exactly would break.

Clearly, there is still some work to be done before a Windows installation can be described as svelte.

For old-time UNIX/Linux users, like me, there is a small amusing footnote to this.  Windows fans have long dismissed the value of the command-line interface.  There is a simple command, whoami, that was frequently a target of scorn.  The command’s function is very simple (from the ‘whoami(1)’ manual page):

NAME
 whoami - print effective userid

The idea that one would not know one’s own identity struck people used to the Windows paradigm of one user = one PC as ludicrous.  But the command is actually useful in scripts, for error checking:


rgibbs@rich90:~$ cat tod.sh
#! /bin/sh
# run ntpdate to fix up system TOD clock
#
# Rich Gibbs 14 February 2003
#
MyUser=`whoami`
if [ "X$MyUser" != "Xroot" ]; then
echo "You must be root to run this script !"
exit 1
fi

[snip]

(Enclosing a command in reverse quotes, as `whoami` in the above example, causes the output of the command to be substituted for the expression.)  In looking through the Command Reference for Windows Server 2008, I notice that a new command has been added, called whoami. And, yes, it does basically the same thing.

The article goes on  to explain why making these changes is so complicated; once again, accumulated complexity is the kernel of the problem:

Software written for Windows has always been written with a certain set of assumptions. It is expected that the basic Windows API functions are located in KERNEL32.DLL, USER32.DLL, ADVAPI32.DLL and GDI32.DLL. These four DLLs contain over 6,000 function calls that cover an enormous variety of common tasks, from creating new processes, to drawing bits of the Windows user interface, to displaying pages from Windows Help. The origins of these DLLs date back some 20 years, and each successive release of Windows has piled on new bits of functionality.

Untangling all this is quite a job.  But it’s good that Microsoft has bitten the bullet and taken it on.  Given its presence in the industry, a more stable and reliable Windows platform has to be in everyone’s interest.