Administrators seek a Cure for the Common Code

Does Datacenter need a flashy GUI?

When the US Human Genome Project completes its goals, it will have a complete map of the genetic structure of the human race. And although this mapping is an incredibly complex task, we already know that humans share a significant percentage of their genetic makeup with other mammals—in fact, we share more than 90 percent of our genetic material with the family of great apes. But given the differences between simians and humans, it's pretty obvious that the differences matter more than the similarities.

Microsoft has long expressed a desire to maintain a common code base for the Windows family of products. At the moment, the company is dealing with three very different sets of code: Windows NT, Windows 9x, and Windows CE. Although these three OSs share a common Win32 programming model, their code is quite different. The multiple NT platforms available (i.e., NT Server; NT Workstation; NT Server, Enterprise Edition; and Embedded NT) share the Microsoft goal to have a common code base. The only real differences between these NT platforms are the way Microsoft optimizes the code, the applications the company includes, and in the case of Embedded NT, the DLLs that the company adds to enable operation in a specific environment. NT Server 4.0, Terminal Server Edition is a special case. Because of Terminal Server's ancestry, many of the core system components use a different code base. However, Windows 2000 (Win2K) rolls terminal services in as a part of the base server OS.

Now, no one expects NT and Windows CE to ever share a common code base. The target markets for NT and Windows CE are very different (with the exception of some overlap with Embedded NT in the set-top device market), so Microsoft has little reason to try to create these very different products from the same code. Regarding Win9x, all we can hope is that eventually the need will lessen for legacy applications that directly touch the hardware. Gaming vendors might decide that some future version of DirectX is the preferred platform for game development, removing one of the major reasons why Win9x is still a force in the consumer market. In any case, Win9x won't likely receive a major investment from Microsoft in terms of future development.

Win2K and NT are the future for Microsoft and its corporate OSs. Microsoft has announced five Win2K products based on the same code: Win2K Datacenter Server (Datacenter), Win2K Advanced Server (Win2K AS), Win2K Server, Win2K Professional (Win2K Pro), and a 64-bit version of Win2K. Microsoft wouldn't plan to release so many versions of the same common code base without markets for OS versions with different features. Now, consider this: All the code and features of the least powerful version of the OS will carry up to the next version, from Win2K Pro to Datacenter. In most cases, the features and performance optimizations for servers are different from those of workstations. So what about the workstation-specific code that's included in the server versions of the OS?

When you look back at the history of PC-based networks, you can see that servers don't really need a flashy GUI and all the baggage that the interface entails. NetWare has never had a huge GUI layered on top of the OS at the server console. And in the original release of the OS/2 LAN Manager, 3Com removed the OS/2 GUI and used only command-line and text-based tools to manage the server. Vendors of UNIX servers tend to prefer command-line controls, though these vendors have started offering GUI front ends for more common management applications. In the world of big iron, the response to the question of whether a server needs a GUI might be, "What's a GUI?"

I'm not saying that GUIs are necessarily a bad thing. NT's CUA interface and GUI-based management tools are certainly easier to use than UNIX's command-line tools. Microsoft has completed quite a bit of Win2K interface work to make it easier for novice users to navigate and manipulate the system. But the usability improvements aren't a selling point to the administrator running Datacenter or Win2K AS. And although you don't have to install the games and multimedia applications that ship with Windows, you don't get an option not to install the user interface (UI).

When Microsoft shipped Service Pack 4 (SP4) for NT 4.0, the company required Microsoft Internet Explorer (IE) 4.01 for the service pack installation. This requirement brought a cry of anguish from NT Server administrators who didn't want to have to install a Web browser on their server systems, especially a browser that replaced several system DLLs when installing. When SP5 shipped earlier this year, the Web browser requirement was gone; Microsoft heeded the complaints of administrators and responded accordingly.

The problem with service packs is that they offer no granularity; you can't install a piece of a service pack (though you have this option with the inevitable hotfix releases). Also, the administrators responsible for maintaining servers don't want to patch code that affects only workstation users. "If it ain't broke, don't fix it" is an adage that many systems administrators live by. No one wants to touch a system that is up and stable, but many software packages require NT to have a specific service pack installed.

Servers that provide more than basic file and print services exacerbate upgrading problems. As the applications and environments become more complex, they become correspondingly more sensitive to system-level changes.

For Win2K AS and Win2K Server, the GUI and the Win2K Pro code are unlikely to be much of a problem. But Microsoft still faces difficulties, because Datacenter needs to play in the midrange and mainframe world. In this world, folks don't ever want to see a blue screen.

I've mentioned these concerns to the Win2K Server folks at Microsoft, but the UI isn't their bailiwick. For now, the server team has to live with whatever the desktop team decides is necessary to improve the end-user experience.

I think the time has come to drive a stake through the heart of the 100 percent common-code-base argument. I acknowledge that Microsoft needs to derive the majority of the core components from a common code base, but the teams developing market segment products should control the enhancements (or de-enhancements) necessary for those specific markets. Given the tight integration of the UI with applications in the Windows environment, separating out the necessary components won't be trivial. However, with Embedded NT 4.0 (and its pending Win2K descendent), Microsoft has shown that the company can pick and choose the OS pieces for a specific application. Microsoft still has time to leave out of Datacenter some of the usability improvements in Win2K. Administrators neither need nor want those improvements that are possible obstacles to widespread adoption.