The Last 10 Minutes

Will Windows NT develop into a super-OS or an unmanageable disaster?

By Nicholas Petreley

To borrow an expression from claymation genius Nick Park's character, Wallace (of "Wallace and Gromit"), it's no use prevaricating about the bush. The conclusion of the Last 10 Minutes is simple -- Windows NT is likely to take one of the following paths:

Mail this article to a friend

• Microsoft will split Windows NT into two product lines, one for the client and one for the server.
• Windows NT 5.0 will only have incremental improvements over Windows NT 4.0, and those will appear at the cost of stability. In other words, Microsoft will fail to deliver on most of its promises for the product.
• Microsoft will deliver on its promised features set but Windows NT 5.0 will rank among the greatest programming disasters in American history.

I regret that it wasn't possible to lay the entire foundation for this conclusion before NC World closed its doors. But I believe we'll be able to pour enough cement, in this one last installment, to create a foundation that fully supports the above conclusions.

Microsoft's MO
Before we lay the rest of our foundation, let's recap the points we investigated in our prior installments: Searching for the next Windows NT, The new UNIX alter's NT's orbit, and Is NT paranoid or is UNIX really out to get it?.

At this point, we've established Microsoft's mode of operation when it comes to product design and marketing. For the most part, it's a mirror image of IBM's strategy when IBM was in the dominant industry position.

• Microsoft understands that given the choice between technical superiority and "only good enough, but it's from Microsoft," most customers will choose the latter. So, when it feels threatened by a new product or technology, Microsoft downplays, criticizes, and spreads FUD (fear, uncertainty, and doubt) about it.
• Microsoft pre-announces alternatives that, if possible, are incompatible with threatening technologies, thus stalling the growth of new outside technologies.
• Meanwhile, Microsoft buys, copies, and develops software to combat any given threat -- even if this means eventually selling a product nearly identical to the one it's currently (and very publicly) criticizing.
• Microsoft eventually provides a flashy alternative solution that is "good enough" but locks the user into a Microsoft-centric buying-and-upgrade pattern.
• If necessary, Microsoft will always leverage its desktop monopoly to create exclusive contracts that guarantee penetration into and eventual dominance of any new market.
• Microsoft keeps a strategic eye on the DOJ while attending to all of the above goals.

Is that a threat or a promise?
Despite what many people may think, Microsoft doesn't have 100 percent control over the market. The market does have its own momentum. And this momentum poses the following threats to Microsoft:

• Unix is increasing in popularity, due to its economy, scalability, stability, technical superiority and, in some cases, freely available open source. This presents a direct threat to NT market penetration in the enterprise-server space.
  • In particular, open-source Unix is rapidly gaining market penetration, popularity, and credibility. Linux recently reached an important milestone when a trade publication ran a story about how Oracle sees no reason to support Linux. While on the surface this seems to detract from the credibility of Linux, anyone in the publishing industry knows that an OS has graduated from irrelevance to a threat to Windows when publications start printing articles about the ISVs that aren't going to support it.
  • Unix is also making covert penetration into the NT space. Many companies run Samba on Unix to provide native Windows NT file-and-print services because that combination is faster and more stable than NT itself. (Ironically, the Samba team claims Samba on Windows NT is even faster than the native Server Message Block (SMB) services in Windows NT.)
• The Internet encourages the tendency to strive toward platform neutrality in every area of computing (as manifested by the rapid growth of Java, HTML, XML, TCP/IP, IMAP, POP3, and other standards).
• IT departments are beginning to understand that the concept behind the network computer is client/server done right.
• IT departments are beginning to understand that the design of Windows is the root cause of rapidly increasing cost of ownership. The design issue is specifically that Windows expects to have a local user context at every desktop.

A terminal approach to computing
Given that we have only one installment with which to wrap up this topic, we'll limit our scope to the most crucial issues. So far, we've discussed Microsoft marketing tactics and the threat from Unix and X11. In our most recent installment, we explained how the root of the runaway cost-of-ownership problem in Windows boils down to its expectation of a local user context at every machine.

We can gain further insight by tackling three more questions:

• What must Microsoft do to provide Windows services to thin clients?
• What must Microsoft do to deliver a managed PC?
• What must Microsoft do to provide comprehensive directory services competitive with NDS or StreetTalk?

Microsoft's original thin
It turns out the first problem is a whopper. And if you've been following this series closely, the reason for this should come as no surprise to you: The problem Microsoft faces in turning Windows into a thin client-friendly operating system is one of local user context.

In order to mold Windows NT Server into something that can serve thin clients well, NT must learn to treat thin clients as if each client has its own user context. And it must keep client user contexts in isolated sessions and manage them at the server. While several clients can share common code libraries at the server for the sake of efficiency, they shouldn't share user contexts.

As obvious as these design issues may seem, Microsoft isn't even close to meeting them. In fact, you may be surprised to find out that this is not how Citrix WinFrame works today. Citrix WinFrame can manage multiple user sessions, but in order to do so, it goes to great lengths to mask the fact that both Windows NT and most Win32 applications were built to run only one local user context at a time.

In other words, WinFrame isn't a true multiuser version of Windows NT. It's NT patched up with bubble gum, black tape, and bailing wire to look like a multiuser version of NT to a thin client. That's not to say that Citrix WinFrame isn't an excellent product. It simply reflects what Citrix had to work with -- the limitation of a Windows NT built to be a desktop operating system, not a server operating system.

The legacy problem
So Microsoft must face a twofold dilemma in order to transform Windows NT into a true multiuser server operating system. First Microsoft has to work around the limitations of Windows NT itself. Then it must find a way to work around the limitations of Win32 applications, and provide hooks for other ISVs to do the same. Finally, Microsoft has to institute a logo program or "seal of approval" process in order to force ISVs to follow strict design guidelines that don't conflict with a multiuser environment.

If Microsoft is going to take this advice, it will need to start with its own OS and applications. For example, Microsoft must modify the architecture of Windows NT Server so that 50 users can run Microsoft Office on the same machine at the same time without one user interfering with the work of another. Microsoft will have to modify its Office suite (or play some tricks on it) in order to make it serve 50 users simultaneously.

It's the applications, stupid
The point is that Microsoft can't fix Windows NT and stop there. The applications themselves have been designed from a single-user viewpoint -- a fact that poses interesting problems when you try to make them work in a multiuser setting.

Take Microsoft Office's Find Fast utility, for example. This utility builds a searchable index file on every non-removable drive in your system. These index files make it easier for you to search through your Office documents.

The problem is that Find Fast runs under the assumption that a single user is running Office on a single machine. When you allow multiple users to run Office simultaneously on Windows NT, each user ends up running his or her own independent copy of Find Fast. If you have 50 users running Microsoft Office, you have 50 instances of Find Fast running on the server.

Each of these instances can easily end up competing to update the same index files on each drive. But that isn't the worst design problem. The real problem stems from the fact that Find Fast sucks up between 90 and 100 percent of your CPU processing power every time it's triggered.

When a utility like Fast Find drains the CPU on your desktop for a moment, the consequences are minimal. But whenever any one of 50 users on a shared system triggers Find Fast, that user momentarily brings the response time for all the users on the system to a complete standstill. If multiple users trigger Find Fast at the same time, the system will turn into a virtual popsicle. According to Citrix, the only solution for this problem is to disable Find Fast for all users.

The HKEY to your success
The single-user desktop mindset runs deep into Office 97 in many other ways. Office 97 was designed to keep many of its user customization files in the Office application directories by default. These files include but are not limited to the following:

• normal.dot
• mailbox.pab
• username.fav
• username.prf
• outlprnt
• frmcache.dat
• custom.dic
• pptools.ppa

The fact that these files are stored in the an Office 97 application directory betrays Microsoft's single-user mindset when it designed Office 97. Had the company assumed Windows NT was a true multiuser system, a transparent setup program would automatically create a set of these files in the home directory for every user on the system.

This practice is typical and taken for granted when using true multiuser systems like Unix. For example, when you run Netscape Navigator on Unix for the first time, it automatically creates a set of local user files in the current home directory. That way each user automatically has his or her own window settings, cache, mail files, etc. If you run Netscape from an X terminal, these settings are kept and managed at the server. That means your Netscape settings are server-centric and don't change when you run Netscape from one desktop or another.

Unfortunately, if you intend to use Office 97 on WinFrame, you'll have to emulate this practice manually. First you'll copy the configuration files to each user's home directory. Then you'll have to edit the registry settings under HKEY_CURRENT_USER so that Office 97 will look in the proper home directory for every user on the system.

Reading you your rights
Then there's the problem with a user's access permission settings. Administrators look at file permissions on a multiuser system with a different pair of glasses than they would use for a single-user system (and well they should).

Unfortunately, most Windows applications were not designed with this factor in mind. To take Microsoft Office as the example again, Office allows you to insert hyperlinks into your Office documents. When you click on one of those hyperlinks, Office tries to launch Internet Explorer to bring up the linked information.

Whether or not the sysadmin deems it a security risk, the only way these links will work is if you give your users full access control for the Temporary Internet Files, Cookies, and History directories. These directories appear immediately under %SYSTEMROOT% or a subdirectory somewhere beneath %SYSTEMROOT% in the directory tree. %SYSTEMROOT% is usually \WINNT, or \WINFRAME. If you don't give users full control over these directories, clicking a hyperlink will result in an error message telling them to run scandisk or reinstall IE. On the other hand, it's potentially dangerous to give any user full control over a directory branch off the system root.

CPU resource usage, concurrency conflicts, managed configuration files, and access control rights are but a few examples of issues that arise when you try to turn a desktop operating system into a multiuser system. In summary, here are some costs, benefits, and problems associated with the fact that Microsoft is getting into the business of competing against X terminals and other thin clients:

Windows NT everywhere
Here's where things begin to get interesting. Not surprisingly, Microsoft doesn't really want thin clients to succeed. A world of thin clients is a world where Windows is no longer necessary on every desktop. Microsoft would much rather sell you Windows NT at both the server and the workstation.

If you want evidence for this theory, you need look no further than Microsoft's pricing structure for Windows Terminal Server Edition. Microsoft will sell Windows NT Terminal Server Edition for $1,129, which includes a 10-user license. Each additional client license costs roughly $35.

But that's not all. You have to pay $269 per seat for a Windows NT Workstation license. That's right. To Microsoft, 50 thin client users running applications on Windows NT Terminal Server Edition is the functional equivalent of 50 users running Windows NT Workstation. And it's prepared to charge the same amount of money for either approach.

By pricing Terminal Server this way, Microsoft not only discourages the use of thin clients, it makes a mockery of those who have been arguing that the dropping price of personal computers makes the network computer irrelevant. Not only did the publications and analysts who bought into that argument miss the entire point of network-centric computing (lower total cost of ownership, not lower entry price), but they also supported an alternative that starts at about $300 per seat before you even add the cost of the client hardware!

At those prices, the software alone for a 50-user installation of Windows Terminal Server Edition will cost just over $13,000.

But wait, there's more. Should you decide to use inexpensive non-Windows terminals for your clients, you'll have to add Citrix MetaFrame to this mix. Microsoft isn't supporting non-Windows terminals until after the year 2000.

With MetaFrame added, you're looking at an additional $4,995 for 15 concurrent users. Additional users run just under $200 per seat, depending on how many licenses you buy.

This brings the total cost of your software solution to $20,000 for 50 users. And we still haven't added the cost of the client or server hardware. Fortunately, you can opt to run your client software on existing machines. Citrix client software runs quite well on 486 computers.

But you could, instead, turn those 486 computers into X terminals simply by installing Linux or FreeBSD. Since the client hardware and software investment is minimal in either case, Microsoft has not only made those who argued against the NC look foolish, it makes a mockery of the claim that Windows NT is the inexpensive alternative to Unix.

Solaris x86 with unlimited user licenses comes to $3,885. That means the comparison between Solaris-based thin client computing and Windows NT computing (whether or not it's thin client) is a contest between $3,885 for unlimited users and $13,000-$20,000 for 50 users. Windows NT 5.0, anyone?

Local user context football game
Since Microsoft charges for a Windows NT Workstation license for every user whether or not the user runs Windows NT Workstation, it's likely that most customers will opt for the managed PC. Therefore the contest isn't likely to be Windows NT Terminal Server with Thin Clients vs. Unix with X terminals. Rather, it will boil down to an all-Windows NT environment vs. an application server and the network computer.

Why? The promise behind network computers is that they lower TCO without sacrificing too much desktop power. Instead of putting all the processing at the server (as you would with Windows NT Terminal Server Edition or Unix with X terminals), you can distribute processing by running some or all of your application locally at the NC.

This gives you the benefits of centralized management of resources without losing the power of a local processor. The only way Microsoft can compete with that is to promise that the managed PC will lower costs as well as a network computer environment does.

In this case Microsoft must retrofit Windows NT Server and Workstation to work together in a unique way. Windows NT must be able to extract a snapshot of local configuration files and application trees and store it all at the server. In short, Microsoft must be able to treat the local user context like a football that it passes around -- from client to server to another client and back to the server again. And the only way Microsoft can match the reliability of the network computer is to keep the two images synchronized virtually in realtime.

Unfortunately, this is going to be a pretty big football. Consider what constitutes a local user context these days. It may include everything from registry settings to JPEG image files, full application trees, and even megabytes of browser cache files. Microsoft's attempt at keeping all this synchronized while throwing it around isn't going to be a pretty sight.

The paradox for Microsoft
Assuming Microsoft can achieve this lofty goal, or even get close enough to satisfy a portion of the market, astute readers will begin to see a huge conflict emerging at this point. The solution for the first goal -- making Windows NT Server appropriate for use with thin clients, and making some form of Windows appropriate as said thin client -- is in direct conflict with the solution for the second goal -- mirroring the local user context and passing it around.

On the one hand, it's Microsoft's goal to patch NT to work around the single-user glitches in its multiuser environment. On the other, it's working to patch NT to save and restore the local user context -- which preserves the very feature that prevents Windows NT from becoming a usable multiuser server for thin clients.

Add to the above design conflict the problem of supplying a global directory service, and Microsoft is in quite a pickle. It is faced with the following problems:

• It must rearchitect Windows NT so that it doesn't expect a local user context at every client
• It doesn't want to do the above, because that weakens its Windows-everywhere leverage
• It must rearchitect Windows NT to preserve the local user context and pass it around like a football
• It must create a directory service that provides access to server-based user contexts and local user contexts that live primarily at a workstation but are mirrored at the server

One doesn't have to introduce any more pertinent factors to future Windows NT design to understand that Microsoft is either misrepresenting what it can and will deliver, or Windows NT is headed for almost certain disaster. That's because Microsoft is between a strategic rock and a hard place.

If it solves the problem of distributed local user contexts the right way (by moving the local user context to the server permanently to be called upon as needed) two major problems crop up. First, it removes the need or desire to put Windows NT at every workstation. Why would you want Windows NT Workstation if you can use anything that resembles a thin client and it works just as well? Second, if Microsoft changes the way Windows NT handles user context, Microsoft and every other third-party ISV must rewrite all their Win32 applications. Even Microsoft Office will have to be rewritten to handle multiuser contexts.

It may be tempting for Microsoft and all its supportive ISVs to rewrite their applications, because this would fuel one massive upgrade cycle. But that's a risky venture -- it's possible customers won't want to dump the millions or even billions of dollars necessary to jump from their current environment to a new one.

Worse -- if customers are faced with an upgrade path that essentially replaces their entire infrastructure, they might just take the opportunity to switch to a more stable and scalable environment than Windows. As demonstrated above with our Solaris x86 pricing example, a wholesale switch to a Unix-based environment could save corporate America a load of money. And the introduction of Java-based network computers as Windows replacements could save even more. This isn't something Microsoft wants to encourage.

The alternative for Microsoft
It's clear that the thin client alternative is too risky for Microsoft to take if it wants to maintain control over its largest "asset": the Windows desktop. Add the pricing of Windows NT 4.0 Terminal Server Edition to the absence of many promised Terminal Server-support features and it does begin to look like Microsoft is discouraging the move to thin clients and leading its customers down the managed PC path instead.

The managed PC has very little chance of success, however. It's easy for Microsoft and its IT customers to speculate on what it would be like to build on a managed PC environment. But it's also easy for them to ignore many of the finer details that could turn the managed PC into a catastrophic strategy.

For example, as we pointed out, as long as Microsoft insists on keeping so much of the user context at the desktop, it will have to build a Windows NT capable of synchronizing and moving huge footballs of user-context details as users roam. In addition, Windows NT has very fine-grained access control lists (ACLs). This is one of Windows NT's features that Microsoft could leverage against Unix, which doesn't use the ACL by default (optional Unix file systems provide this feature).

But if Microsoft insists on keeping the user context at every desktop, the ACL feature simply adds to the already overwhelming amount of information Active Directory will have to pass around and synchronize.

As you can see, as Microsoft addresses each of its competitive problems, the problems of how to address these threats grow exponentially.

Active quilt
The question is, which road is Microsoft traveling? Will Microsoft redesign Windows NT from the ground up to support multiple user contexts, and at the same time rewrite (and demand that its ISV partners rewrite) all Win32 applications to support simultaneous access by multiple users? Or can we expect Microsoft to patch the problems that will naturally result from failing to take that path?

It may be the year 2000 before we know for certain. But since Microsoft's promised goals surely lead to complex and in some cases contradictory design strategies, it appears as if Windows NT is going to become a product Microsoft could easily call Active Quilt. That is indeed the only path Microsoft can take if it wants to keep the competition from penetrating its desktop monopoly.

That's why we predict that, of the possible directions cited, Windows NT will most likely become a huge OS disaster. Microsoft has demonstrated in the past that it's more interested in market control than the needs of the customer. If Microsoft stays true to form, it will take the only option that maintains its control of the desktop -- patches, patches, and more patches.

Already evidence is mounting that this is exactly the direction Microsoft is taking. You simply have to know what to look for. What we're looking for in this case is sheer code size.

Size does matter
Here's why. Whenever programmers are faced with conflicting design goals, there are really only three choices they can make. (1) They can rewrite their product from the ground up; (2) they can add a layer on top of what they already have (thus attempting to emulate the behavior the product would have if the programmers could do it all over again); or (3) they can add layers upon layers of conflicting patches to satisfy every demand and problem that crops up. In this case, Microsoft's programmers not only need to solve the original design goals, they'll have to patch the resulting conflicts between the patches.

This last approach results in a huge, nearly unmanageable code base. To illustrate, I need to borrow an example coined by WPI President Michael McCarthy.

You build a calculator that answers 5 when you add 2 plus 2. Now you have a problem addressable from one of three levels of abstraction. (1) You can fix the core mathematics engine in your calculator; (2) you can add a layer to the existing mathematics engine such that it redirects all addition to a new engine; or (3) you can add a lot of little layers that check for specific patterns that break the mathematics engine. For example, if a user presses the key sequence 2 + 2 =, a patch is triggered to see if answer is 5. If so, the patch replaces the number 5 with the number 4.

Any good programmer understands the occasional necessity for patches that work around inadequate design. But every good programmer also understands the danger of patches: Someone is sure to come along and press the key sequence 2 + 3 [Backspace] 2 =, which will slip by the aforementioned patch. The programmer can add another patch. But someone is always bound to stumble on an unanticipated way to add 2 plus 2 and get 5.

If you patched a calculator in the way we described, you would end up writing thousands of lines of unstable code just to make a simple adding machine work most of the time. Even then, you'd have to download and apply updates on a continual basis just to keep it running as people discovered new key combinations that resulted in incorrect math.

We're not missing the bloat
With that in mind, consider the predicted size of the new code in Windows NT. According to Giga Information Group, Windows NT 5.0 will have 30 million lines of code, 85 percent of which will be new. To put this in perspective, this means Windows NT 5.0 will have more new code in it than the total amount of existing code for some competing versions of Unix!

What could Microsoft possibly be adding that would cause such a dramatic increase in new code, other than patches, patches, and more patches? If Microsoft were redesigning Windows NT from the ground up, other evidence would surface.

For example, Microsoft would be warning customers and developers that, in order to use Windows NT 5.0, they would have to migrate to an entirely new Windows application model. (For example, it might announce the upcoming need to switch to a new, Windows NT 5.0-compatible version of Office, since a redesigned Windows NT 5.0 would surely manage user contexts in entirely new way.)

Such evidence is nowhere to be found. It is therefore most likely that the increased new code is bubble gum, black tape, and bailing wire. For example, NT 5.0 may include code that checks if a user is running Fast Find, checks to see if this is an installation of Terminal Server, and then checks to see if there is more than one user on the system. If all these conditions were met, Terminal Server would know not to start another instance of Fast Find on the network. This solves a problem with Office 97. But it adds complexity and more moving parts that can interfere with other moving parts, bringing down the entire house of cards.

But bloat and instability aren't the worst results. The worst thing about the patchwork approach is that it eventually becomes entirely unmanageable. An army of the best programmers cannot untangle a project that goes beyond the boundaries of all reason. There is a point of no return when using a patch strategy. At some point, you have to start from scratch or face the fact that each new patch has a near 100 percent chance of creating problems in some other piece of the product.

Thank you and good night
What we've presented thus far in this series is by no means the entire story. For example, Microsoft is suffering from bad timing on several fronts. Novell is strengthening its image at a time when the Novell Directory Services have matured and Active Directory is nothing but delayed vaporware.

The DOJ vs. Microsoft debate is drawing attention to the issue of Window's dynamic link libraries (DLLs). This is dangerous for Microsoft. It increases the possibility that IT departments will realize that Microsoft's approach to DLLs are at the heart of many of their financial problems. That is bad news for Microsoft because its customers are suffering simply because Microsoft insists on using DLLs to squash competition.

There are other challenges Microsoft must face that will have more or less impact on the design of Windows NT. We touch on some of them, which you can peruse in the tables in our sidebar, below.

Finally, we want to thank you for all your comments on the preceding Next 10 Minutes series. Without the overwhelming degree of encouragement and response by so many NC World readers, this Last 10 Minutes would never have been written. We encourage you to continue to post your comments. Positive, negative, or irrelevant, we will continue to eagerly await and read them all.

Whether our predictions hit the bull's-eye or are off target, whether you invest in Windows NT or not, whether or not your chosen strategy turns out to be the most or least successful for you, we wish you the best of luck in your computing career.

About the author
Nicholas Petreley is a columnist for InfoWorld and NT World Japan. Reach him at nicholas.petreley@ncworldmag.com and read his column Down to the Wire in InfoWorld. Reach Nicholas at nicholas.petreley@ncworldmag.com.

JUNE  1998