Introduction
To understand how these two operating systems are linked, their ancestry must be known. Are the similarities coincidence, a migration of ideas or do Windows NT and VMS stem from some common source?
What is VMS?
Today, VMS is little known of outside of computer science circles, and rarely used by anyone other than diehard fans. However, in the 70s, VMS was probably UNIX's main competitor.
Before DEC produced VMS, it was famous for creating the PDP series of computers, most notably, the PDP-11 architecture. As well as creating the hardware, DEC also produced a range of 10 OSes for the PDP-11. One of these operating systems was called RSX-11M, which was developed under the direction of a budding software engineer Dave Cutler.
It was because of his success in creating RSX-11M that Cutler was chosen to lead the development of a unified operating system for DEC's new architecture, the VAX. It was this OS that would become known as VMS.
Version 1.0 of VMS was released in 1977, and was quickly accepted as a capable, scalable and backwards-compatible operating system. It was chosen as the OS of choice for a multitude of applications, from desktops to servers.
Cutler continued to develop VMS for four years, until 1981, when he became dissatisfied with the resources DEC were making available to him. Realizing what a valuable asset a man like Cutler is, DEC bent over backwards to accommodate him, setting up a new development center in Seattle, putting a massive team of hardware and software engineers at his disposal. His new task was to create a next generation CPU architecture and associated operating system to win a share of the massive PC market for DEC.
However, in 1988, DEC axed Cutler's project and made many of his members of staff redundant. Unsurprisingly, Cutler was livid, and was thinking about leaving DEC once and for all, as he had threatened in 1981.
Bill Gates was quick to learn of Cutler's disillusionment, and worked hard to try and get the software engineer to defect to Microsoft. Finally, in October 1988, Cutler decided to leave DEC to go and lead Microsoft's new NT project.
What is Windows NT?
In the late 80s, Microsoft, in conjuction with IBM, were developing a new operating system, which was called OS/2. Initial releases were not well accepted, and soon, a follow-on was started, trying to remedy some of the problems OS/2 had had. This project was called NT OS/2 (the NT standing for "New Technology"). This is the project Bill Gates managed to persuade Cutler to come and lead, bringing many ex-DEC employees with him. It's main objectives were:
Out of these requirements, the POSIX compliance, portability and extensibility would be the hardest to implement. As such a wide range of functionality had to included, Cutler decided to adopt a highly modular, layered approach for the OS, with a true microkernel. In this way, Windows NT is very similar to MACH, a flavour of UNIX. The compatability requirement demanded that many separate APIs were presented to userspace programmes, all abstracted away from the kernel mode device drivers and HAL (Hardware Abstraction Layer). Because of the layered design, any use of the user-visible APIs would involve drilling through many levels of internal abstractions. This made all the above requirements relatively easy to implement, as new elements could simply be `plugged in' to the existing framework, but performance suffered.
In April 1990, Microsoft launched Windows 3.0, which was a massive success. In fact, this success made Gates realize that his company could easily produce and distribute NT OS/2 totally independent of IBM. In due course, the two companies split from the joint venture, IBM taking the code that formed the basis of OS/2 and Microsoft taking the code that would become Windows NT. Cutler no longer had to adhere to the OS/2 API, and instead created a new API that would become known as Win32.
Windows 3.0's massive success had more effect than this on Cutler's project. It was decided to rename NT OS/2 as Windows NT in order to associate the new product with the established market leader. Also, emphasis was placed on interoperability between the two emerging flavours of Windows, so Cutler included a Win16 API compatability mode alongside the new Win32 API and sidelined POSIX and OS/2 APIs.
Initial releases of Windows NT were very poor indeed. The strict microkernel approach taken meant that the system was very bloated and slow and despite portability being design aim, the OS was still not available for most architectures. Cutler's response was to push many of the abstracted layers into the kernel, notably the graphics rendering code. This violated the clean and attractive modular design, but performance improved dramatically.
As I write this, the cutting edge Windows NT incarnation is Server 2003. Although there have been many cosmetic changes and new additions to the NT system, as Cutler said in an interview in 2000, "The basic, internal architecture has not changed, except for Plug and Play".
Quite apart from the similarities in VMS and Windows NT, there a number of striking coincidences between what Dave Cutler did during his time at DEC and Microsoft. It is almost as if he had a couple of goes at making an OS at Digital, then left and had another go for a different company.
When Cutler was creating his first true operating system, RSX-11M, he had to decide how to distribute the memory between the kernel and user's applications. It was decided that memory should split in two, with the top half of the addresses for kernel use only and the bottom half for other programmes. This feature survived into VMS, where addresses 0-7FFFFFFF is mostly user-mode accessible only and addresses 80000000-FFFFFFFF is mostly kernel-accessible only. After moving to Microsoft, when Cutler was organising the memory management of Windows NT, he again had to work out how to distribute memory addresses, and again he used this same scheme - a half and half split down the middle.
One of the reasons DEC felt the need to produce a new architecture, the VAX, was to increase the number of address bits. On the PDP-11, it was only 16, which put an impenetrable ceiling on the size of memory, and hence, the effectiveness of the computer. DEC's competitors had already started this transition, so one of their demands of Cutler was that his new VAX/VMS system must have 32 address bits, while retaining backwards-compatability.
Back at Microsoft, one of Cutler's main tasks was to reconcile the 16-bit Windows 3.x API with his new 32-bit system. Obviously, he was well equipped to do this.
VMS wasn't a perfect operating system. One problem was that it was written almost entirely in VAX assembler, which meant code maintenace and revision was very difficult. In 1993, Cutler said "The biggest mistake we made in VMS was not writing it in a high level language". In contrast, Windows NT was written entirely in C and C++. Had Cutler been given another chance to implement VMS, but in a high level language as he so desired?
One of the distinguishing features of VAX/VMS was the level of backwards compatability it offered to RSX-11M programmes. With absolutely no adjustment whatsoever, binaries designed to run in another operating system, on another CPU could be loaded and run in VMS. That's like seamlessly running GNU/Linux PowerPC binaries in Windows on an x86!
In Windows NT, interoperability was again required of Cutler, who had to make his operating system present POSIX, OS/2, Win16 as well as Win32 APIs.
However, it's not just what was asked of Cutler that was similar. What he did to acheive those things, and how he accomplished a lot of tasks in the Windows NT project bear more than a passing resemblance to decisions he had made more than a decade before.
An overview of the similarities
The I/O Manager
Windows NT has a very distinctive and unique I/O manager. Actually, it's not quite unique, because it the same as the VMS manager. Unlike many other systems, VMS and NT I/O is packet based and asynchronous. To communicate with the outside world, a programme asks the kernel to send some information to a device, and potentially return the reply. This is when the kernel uses the I/O manager.
As well as being asynchronous, the manager is distinctive in that it consists of a number of dynamically loadable and stackable layers, through which each packet must pass on its way to or from a device. This means that the OS is very extensible (as required); new device drivers just slot into place inside the I/O manager. In this diagram, packets flow from the top, through of the drivers stacked on the right, then through to the HAL. When replies are received, they must propagate up through the driver stack and back out of the manager.
+---------+
| I/O |
| Request |
| Packet |
+---------+
|
| +--------------+
V | Driver Stack |
+---------+ +--------------+
| | <==> | File System |
| I/O | +--------------+
| Manager | <==> | Intermediate |
| | +--------------+
| | <==> | Device |
+---------+ +--------------+
|
|
V
+----------+
| Hardware |
+----------+
The description above could be used for both
VMS and
Windows NT, with the different
terminology and different structures above and below the
I/O manager.
Memory management
As mentioned above, NT, VMS and even RSX-11M, VMS's predecessor, split the memory in two - half for the kernel and half for the user. However, the similarities go deeper than this.
As RSX-11M was expected to work on such a small machine (the PDP-11), its memory management was very efficient and sophisticated. One of the ideas that it, and VMS, used were `working sets'; every process had one. What a working set did was define the upper and lower limit of the amount of physical memory allocatable to that process. This system ensures that one process using large amounts of memory will not squash other, smaller processes into smaller and smaller amounts of memory. Windows NT's memory manager also uses working sets, along with all the other optimizations, algorithms and methods used by RSX-11M to get the most out a computer's memory, no matter how small.
As well as this, Windows NT has the same method of demand-paged virtual memory as VMS and both operating systems rely heavily upon memory-mapped files. The terms "Paged Pool", "Nonpaged Pool" and "Look aside List" all refer to exactly the same things and all perform the same task on both operating systems.
VMS and NT both maintain levels of abstraction inside the OS called the executive. This consists of various client/server systems including an "Object Manager", "Process Manager", "I/O Manager" and "Cache Manager". This prevents the kernel from becoming bloated and monolithic, and aids extensibility and portability.
In NT and VMS, these managers operate in privileged mode (they can use the kernel's memory) although they still communicate to the hardware through the kernel and device drivers.
Although the ranks of
interrupts are called
Interrupt Priority Levels (IPLs) on
VMS and
Interrupt Request Levels (IRQLs) on
Windows NT, they represent exactly the same thing.
In both
operating systems, there are 32 such levels, all of which correspond to equivalent priorities between
VMS and
NT. Here are a few of them, from low priority to high:
- Passive level
- VMS: Asynchronous System Trap (AST), NT: Asynchronous Procedure Call (APC)
- VMS: Fork, NT: Dispatch
- I/O Response Packets IRPs
- Hardware maintenance: Power failure, timer, etc.
- `HIGH_LEVEL'
I/O in general
Although there are striking similarities in the I/O manager, the other structures necessary for I/O in the two operating systems also share some notable coincidences. The only real difference is the names used to refer to the various entities, and the explicit Object-oriented approach that NT takes. The following list gives the names of certain I/O-based elements that perform the same task in NT and VMS:
- In VMS, the I/O manager receives I/O Request Packets, as it does in Windows NT.
- VMS: Unit Control Block (UCB), NT: Device Objects
- VMS: Channel Request Block (CRB), NT: Controller Objects
- VMS: Adapter Control Block (ADP), NT: Adapter Objects
- VMS: Function Decision Table routines (FDT routines), NT: Dispatch Routines
- VMS: EXE$QIODRVPKT, NT: IoStartPacket
- VMS: StartIO routines, NT: StartIO routines
- VMS: Fork routines, NT: Deferred Proceedure Call routines (DPC routines)
- VMS: Asynchronous System Trap (AST), NT: Asynchronous Procedure Call, (APC)
Again, NT and VMS share a distinctive feature: the scheduler. The most obvious similarity is that they use hybrid static and dynamic priorities, split so that priorities 0-15 are variable and priorities 16-31 are fixed. For threads with dynamic priorities, VMS and NT share a number of `priority boosting' mechanisms.
- when a thread requests I/O, with an IRP, its priority is increased by a driver specific amount.
- there is a boost for GUI threads awaiting input: current priority boosted to 14 for one quantum (but quantum also doubled)
- if a priority is boosted, it decays by one after every completed quantum.
- all threads have a base and a current priority. The current value is increased by a boost, but never decays below the base priority.
In order to highlight just how different this system is from other systems, I'll quickly look at UNIX scheduling.
In UNIX,
Clearly, this is a vastly different system, from the basics all the way up to the general idea.
Miscellaneous
There are various operating system components scattered around that share some striking similarities, such as both VMS and NT representing the system's resources as objects, under the control of an object manager. Also, both VMS and NT implement security measures by associating an Access Control List (ACL) with every object and NT's administrative utilities Performance Monitor and NT Backup are clones of VMS's MONITOR and BACKUP tools.
Counter Arguments
Although it is hard to argue that Windows NT is an entirely new operating system, that is not to say that Microsoft's software engineers have simply ported VMS to new architectures and rewritten it in C. Not at all. Microsoft have managed to create a good, new filesystem with NTFS, a new API: Win32 as well as a new GUI and ports to a wide range of architectures.
Also, some would argue that NT cannot be VMS because NT's not good enough! Microsoft products are infamous for their unreliability and insecurity, and although the NT series is better than 3.x, no one could claim it is secure compared to other OSes if they had any idea what they were talking about. And it's not like VMS is an insecure OS. At DefCon 9, a meeting of many of the best hackers in the world, a VMS box open to attack, running all the services an ISP would, was never compromised, while all the other OSes were dropping like flies!
As of July 2003, the new incarnation of VMS, OpenVMS, has never been infected by a virus and has not been affected by a worm (since the internet worm of 1988). Compare this to the track record of Windows NT. Almost every, if not all, major virus, worm or trojan over the past five years has exploited Windows or software running on Windows, and most Windows boxes aren't even offering services such as a HTTP or FTP server. How could an OS derived from VMS be so insecure, especially with the security subsystem copied across almost intact?
Another argument many people would present is that VMS looks nothing like Windows NT, it has a different GUI and API, and is less `point-and-click', especially nowadays. However, the similarity I am talking about here is not the API, GUI or whatever, it's the system internals, the jobs the kernel and executive deal with, the parts of an OS that make it good or bad. The Windows trademark `look and feel' might be how a normal user would identify an OS, and in this way, NT and VMS are very different. However, under the hood is where an OS's identity truly is. The X windows environment ported to Windows NT is still Windows NT, it just looks better.
Conclusion
Obviously, DEC weren't happy with the apparent similarity of Windows NT and their product, VMS. In fact, when DEC's engineers noticed the problem, and brought their concern to the senior management, suing Microsoft for intellectual property violation was a possibility. Instead, there was an out of court settlement with Microsoft.
As a result, `Affinity for OpenVMS', a scheme to train DEC's technicians and promote NT and OpenVMS as complimentary pieces of a networking solution was announced in summer of 1995. Plus, Microsoft promised to maintain NT support for the DEC Alpha processor and paid DEC up to $100 million. I'd say Bill Gates got off quite lightly.
An argument often provided to support the point of this writeup is that WNT shifted backwards in the alphabet gives VMS. However, as NT was so named before Dave Cutler joined Microsoft, and before any major design decisions would have been made, I think this is a funny coincidence, and nothing more.