Windows NT vs. UNIX

Updated September 10, 2000

It should not be news to anyone reading this file that people have very strong feelings regarding the relative virtues of UNIX and Windows NT. I'll give my views here; naturally, there will be a lot of disagreement. My opinions are based on 35 years in the computer industry (in short, I've seen it all), dealings with advocates of both systems, a brief stint in the "open systems" business, recent dealings with mainframes, and more. Nonetheless, my statements are personal opinions, which undoubtedly reflect some personal bias. In some cases, I've said things such as "to the best of my knowledge" which, of course, means that I have not checked my facts thoroughly. If you have a response to these statements, please send them, and I'll attempt to incorporate them in this section.

First, assume that Windows 95/98 is not a part of this discussion. Bear in mind, however, that Windows 95/98 provides the very cheapest Win32 platform, although Windows 95/98 will not support some Win32 functionality (such as security).

Opening Position Statement

As programmers and users, we hope for several things:

• A standard, technically up-to-date API that is well-understood and supported. It should also be stable but capable of evolving with the technology.
• Platforms supporting the API that range from the smallest systems (palmtops, embedded systems) to the desktop, and then on to departmental and enterprise systems (in short, we need scalability). The platforms should always be the most cost-effective in the industry and available through numerous channels with a wide range of choice and tradeoffs regarding price, quality, delivery, support, performance, and so on.
• A wide range of cost-effective applications and supporting software, such as programmer tools (one could argue that this will result automatically from the first two characteristics).
• Assurance of long-term support and evolution of the API and its platforms so as to support evolving hardware and increasing software demands (support for 64-bit addressing is one example of this).
• Enough competition at all levels so that no one becomes complacent or totally dominant.

The actual technical form of the API is secondary, assuming it is functionally complete. Nonetheless, the API should possess intangible properties such as simplicity, consistency, elegance, and so on.

Accordingly, Windows NT and Win32 come out even or ahead in almost every category (we could argue about the intangible properties!) although many voice concern regarding the last point. There is one major exception: UNIX still has a leadership position as an enterprise or large departmental server. Let's take up several dimensions of this, one at a time.

Sept. 10, 2000. Now that LINUX is popular and widely available, and also well supported, it's much more difficult to argue that Windows has the same advantages that it had in early 1998.

Win32 vs. POSIX

What more can be said about the Win32 API in comparison to the POSIX standardization of the UNIX API? Not much, but here is a summary:

• Win32 is nearly complete and fairly consistent. While it can be criticized (see the criticism section), POSIX is at least as vulnerable. For example, there is no real concept of a handle. File descriptors and process IDs are treated very differently.
• POSIX lost a lot of its original conciseness and simplicity once the BSD - AT&T divide occurred. How many careers have been shipwrecked trying to straighten that out? Threads and synchronization, in the form of pthreads, definitely destroyed any remaining simplicity. Sept. 10, 2000. Now that I've come to appreciate Pthreads, I'd like to withdraw the above comment! I do not much like the Pthreads naming conventions, however.
• When all is said and done, you are dealing with matters of taste (short names vs. long names, for instance) and prior experience. A person who has invested time and energy in mastering one API will naturally not want to learn the other.
• Concluding point: Win32 applications really are source compatible, and even binary compatible in some cases, across supporting platforms. Thus, it is trivial to port source code to a Digital AXP system. Of course, AXP is the only other platform at this time, so this may not be saying much. Nonetheless, the last time I tried porting UNIX source code (1995), I ran into difficulties. Editorial Note: In my opinion, the UNIX vendors missed a wonderful opportunity in the late 80s and early 90s to address this issue. How they failed to seize the opportunity is a story worth a good book. Sept. 10, 2000. Some recent experience with LINUX and several UNIX versions have been very positive in terms of portability.

The Very High End

UNIX (and other operating systems such as VMS and MVS) still has an advantage at the high end (enterprise servers and the like) and, while that lead may be eroding, it should endure for some time. Here are the primary reasons, in my opinion, and these reasons have nothing whatsoever to do with inherent properties of the underlying APIs (people have tried to tell me that it does, but it's hard to understand the argument).

• 64 Bits - The Most Significant UNIX Advantage. There are several robust 64-bit UNIX offerings. Win64 (or whatever it will be called) is not on the horizon. Many, but not all, enterprise applications really do require 64-bit addressing. Sept. 10, 2000. Win64 is on the way (see Edition 2, Chapter 16); the impact should be interesting.
• Clustering. NT clustering lags what can be achieved with UNIX systems in terms of the numbers of systems that can be clustered. Sept. 10, 2000. Clustering does not seem to be as important as it once was. Advances in network attached storage (NAS) and related technologies have offered viable alternatives to clustering.
• Scalability and Performance. UNIX systems can, in general, support more physical memory and processors that NT can. This, in turn, leads to higher performance even though both systems can be supported on the same microprocessors. To my knowledge, there is no significant difference in the disk storage available for the two systems.
• Quality, Robustness and Reliability. The very highest levels of these attributes do not appear to be among the Microsoft priorities, although I may not be properly informed on this. In the meantime, UNIX vendors continue to invest here. Sept. 10, 2000. No change in opinion.
• Manageability. Windows 2000 will address many of these issues; time will tell if this version will close the gap.

It is ironic, of course, that as recently as the early 90s, UNIX was still regarded as a technical, flaky, not-quite-ready operating system that could not possibly run an enterprise. Suddenly, around 1994 or 1995, however, UNIX became the high-end enterprise server ready to take on the mainframe. NT is sometimes criticized in the same way that UNIX was in 1990. I've heard it phrased as follows: "UNIX threw away its blue jeans and sandals, got a haircut, and put on a three-piece suit."

Therefore, the UNIX evolution proves that if Microsoft and its partners have the will and the money to invest (I believe that they do!), in a short time (3-5 years) they will be able to satisfy the most demanding enterprise requirements.

There is an additional factor here. All but one of the major U.S. UNIX vendors also support NT. These vendors may find it more effective to downplay UNIX, or to force it into a niche, over time.

Departmental Servers

I see figures that show the server market evenly divided between UNIX and NT (about 40% each) with the remaining 20% going to other systems, such as the AS/400. Some of the high-end advantages may also benefit UNIX here as well, but, again, Microsoft can invest to narrow or remove any of these gaps.

The Desktop

I've heard several CEOs and other high-level executives of UNIX vendors all but concede the desktop to Windows. On the desktop, UNIX seems to be confined to high-end technical or very specialized workstations. Of course, the Mac still plays a small desktop role. (Mac OS, to my knowledge, does not really support multiple processes, much less threads.)

Nearly everything a desktop user might want is cheaper, with more choice, under Windows than UNIX. This is certainly true for "personal productivity" applications (word processors, spread sheets, and so on), application development tools and environments, etc. Sept. 10, 2000. LINUX may change this situation.

Embedded Systems, Palmtops, etc.

Windows CE seems to be gaining in this space as well. I do not have any knowledge of UNIX's role, if any, in these smaller systems.

An Illustrative Anecdote

The combined experiences of some of my clients illustrate many of the advantages of Windows over UNIX. These clients build and sell applications that were originally supported on a single vendor's UNIX system. (It was too expensive to support an application on more than one vendor's system.) The UNIX decision was generally due to either history (development was started before NT was available), concerns over NT performance, or even existing programmer skills. The UNIX-only, single platform vendor, product strategies led to several problems:

• Customers required a month or two to order and acquire the UNIX platforms, and costs were high ($10,000 to $50,000).
• The high cost led to client/server architectures (with Windows clients) which added to the costs and the administrative headaches (a full-time administrator was required).
• Customers objected to being required to purchase a system that was not on their "approved" list and which they did not know how to support.
• Deficiencies in the optimizing compilers led to shipping sub-optimal code with sub-optimal performance. The vendors essentially said that there was no return on investment to fix the compiler optimizer (so much for the UNIX quality advantages).
• Ports to Windows NT solved all these issues, and performance on an equivalent system was double that on the UNIX system. Ironically, one of the reasons for shipping on UNIX in the first place was misplaced fears regarding NT performance.
• Development costs were also reduced as a result of cheaper development systems and tools.

Needless to say, not everyone will have similar experiences, but this illustrates the challenge the UNIX world faces.

Reader Comments

Mike Innes, corresponding from the UK, would like to put in a word for UNIX, particularly at the high end. Mike's message is as follows:

"I think the technical (low-level) issues are valid, although I think the biggest issue around the enterprise is scalability. NT currently will not scale to the same level as UNIX, partly because of the OS, but mainly because of the hardware. Even NT5 is not predicted to scale to the level of a cluster of 4 Sun Starfires. [JMH Note: I assume that the hardware limitations really refer to clustering limitations, as NT runs on Digital Alpha servers, which consistently provide leadership performance. Sept. 10, 2000. Windows 2000 does not run on any non-Intel platforms, so the note is no longer relevant]

"The Wolfpack cluster is at least a generation behind UNIX clustering. We may start to see the peak of SMP soon, which means that hardware such as MPP or NUMA will have to be at the forefront if we are getting little or no advantage from faster processors. UNIX will be at this cutting edge for at least the next ten years, if only because of the UNIX momentum. The low-end systems will not be UNIX; this is definite, I think if we are going to have a revolution on the desktop then Java will do it, for mainly of the same reasons that UNIX has taken off: the standards, compatibility and more importantly multi-vendor. Can you see any reason why a Java/browser based thin client can't be used in most companies? [JMH Note: I said five years, but the outcome probably really depends upon Microsoft's commitment and strategy.]

"As I learn more about NT/Win32, my belief that UNIX is a superior OS gets stronger. However, I am often pleasantly surprised by NT/Win32."

Mike further reports that there is an article in Network News, 22 April 1998, that Microsoft is using a Sun Solaris server to run its Hotmail service. There is talk in the article Mike forwarded that thread performance is part of the problem with NT. Perhaps they ran into the Critical Section issue, or one of the other thread performance issues illustrated by the sample program, described elsewhere, or is it possible that they really need a large address space? [JMH Note: I have not verified this. More information would be appreciated.]

Jeff Krob sent me the following comment, "I work with both Windows NT & *NIX (UNIX & Linux) and my biggest view of differences is in the Command Shell. Here *NIX wins hands down, and I think this is one of the BIG things keeping some *NIX types from going over to MS Windows. As far as I know, MS Windows only as 2 shells to do any scripting from (including Perl) where any of the *NIXs have 3, 4, or even 5 to choose from. Also, the primary shell in MS Windows has progressed little from DOS 6.

"Now, if you are a system admin who does a lot of work from the command line or with scripts, and you have to choose between a system which has a weak, lame shell or one with a strong, rich shell...which would you choose (all else being equal)? In my opinion, Microsoft has missed the boat on this. They are so "windows-oriented" they ignore the shell and try to convert *NIX users by saying, 'You don't need the command line, everything is in the windows!' Of course, the *NIX users all laugh at that. If MS could stop forcing things on its users and start listening to what the "high-end" users would want (where they are trying to oust *NIX with MS Windows), like porting/adding Bourne, C, Korn or some shell like that to MS Windows, I think they would have a much easier time and a better chance of dislodging *NIX. However, I fear, the MS Command Console may be getting more "Macish" as time goes on; it's only there if the system crashes or it won't boot so you go to the command line for emergency repairs... how sad."