This month, let's move from how to fix Active Directory (AD) and look at the broader topic of fixing the Windows OS, or I should say OSs--because the desktop and server versions of Windows are two different OSs. Unfortunately, Microsoft doesn't want to admit that the server and professional editions are different OSs, and I think that stance is hurting both products. (I have no idea why Microsoft created the home versions of its OS, so I'm not going to consider them. In fact, I wish the company would get rid of the home versions. But that's a topic for another day.)
Microsoft originally decided to build both the server and desktop versions of Windows NT on top of the same OS kernel. It seemed like a good idea at first because that approach would save Redmond a lot in development and maintenance costs. For example, suppose Microsoft released a new version of NT Server 4.0 and NT Workstation 4.0, only to find a heinously vicious bug in the virtual memory manager. (That did happen soon after NT 4.0 was released, leading to a staggeringly fast release of NT 4.0 Service Pack 1--SP1.) Because both NT Server 4.0 and NT Workstation 4.0 are built on the same foundation, Microsoft could release one service pack that served both versions of the OS. A common code base also makes implementing new ideas easier. For example, Microsoft will need to build Indigo--a new Web services-based communications infrastructure built on the Windows .NET Framework--only once (in theory). Indigo's benefits then will quickly spread to Longhorn Server, Longhorn professional edition, home edition, web edition, media edition, and so on.
The above-mentioned benefits of a common code base are attractive, but I think that forcing the Windows Server kernel to be identical to the desktop OS kernel has its dark side--sort of like Ford deciding that the Focus and F350 truck should use the same engine. That approach would certainly lead to easier engine development--developing a fuel-electric hybrid engine for the Focus would immediately make a hybrid F350 engine possible--but in the end, you'd have either a woefully fuel-wasting Focus or a laughably underpowered F350. Trying to serve multiple masters often just doesn't work.
Here's a great example of why server and client OS versions should have separate code bases: the question of whether video and printer drivers live in kernel mode or user mode. Here's why that question is important. When NT first came out, graphics and printer drivers lived in user mode rather than kernel mode. User-mode programs have strengths and weaknesses. The strength of a user-mode program is that if it crashes, it can't usually take the whole OS with it. Bad user-mode programs kill only themselves; bad kernel programs trigger blue screens. But implementing programs as user mode rather than kernel mode has a price--user-mode programs usually are slower than kernel-mode programs.
Originally, developers built NT 3.1 by putting as many programs into user mode as they could. They thought that an OS driven largely by user-mode components would be hard to crash. But that reasoning goes only so far; there's no point in putting the file system in user mode because if it crashes, you can do nothing on your system that involves your hard disk, rendering your system virtually useless. But disk drivers are a mite more fundamental to keeping a server running than printer or graphics drivers are. So Dave Cutler, the original architect of all things NT, decreed that graphic and printer drivers live in user mode, not kernel mode. So on one hand, a bad graphics or printer driver can't crash a server; on the other hand, that server won't process graphics or printing as quickly.
Personally, I'd take that trade-off. My multipurpose server might lose its ability to share a printer when the badly written printer driver dies, but Microsoft SQL Server, Microsoft Exchange Server, and the file-server software continue to run. I get to choose when to reboot the server to bring the printer shares back online, or I can simply restart the Spooler service. Sounds like reliability, doesn't it?
Oops, I forgot: The server and desktop OSs share a kernel. So although your Windows client won't crash from a bad printer or video driver, it also performs poorly when handling graphics. In short, the Windows desktop OS is terrible for games. For whatever reason, Microsoft upper management decided that NT Workstation 4.0 needed to be a great gaming platform and moved NT 4.0's graphics and printer drivers (it would be hard to change the graphics driver and not the other) from user mode to kernel mode.
Now, if the two NT versions had two different code bases, then Microsoft could have left the printer and graphics drivers in user mode for NT Server and moved only NT Workstation to kernel mode. NT Workstation would need different drivers than NT Server would, but people might have been willing to take that trade-off in return for reliability.
The recent spate of JPEG viruses highlights another example of a problem that a common code base creates. The graphics device interface (GDI) is the part of Windows that handles graphics. It worked fine for years, but in Windows XP, Microsoft decided to replace GDI with GDI+. Again, high-performance graphics are king in the desktop world. The old GDI programs handled JPEGs without trouble. But the JPEG code in GDI+ has, as you probably know, a nasty hole--another buffer overflow. Because Windows Server 2003 and XP use the same code base, Windows 2003 got the buggy JPEG code and is vulnerable to JPEG-carried viruses.
Consider how much more powerful Windows Server could be if it weren't tied to the Windows desktop code. You could have a version of Windows Server that lacks a GUI or one that lets you turn off the GUI. And a far smaller version of the Windows desktop OS is possible because an OS built to be just a desktop OS can be smaller and simpler.
Microsoft has denied itself opportunities by working so hard to keep the Windows Server and Windows desktop code bases the same, but in reality they're not the same. For example, XP SP2 shipped in August, and Windows 2003 SP1 will ship some time in late 2004 or early 2005. That's hardly what you'd expect from a "common code base." Microsoft, give up and split the code base or, as programmer types say, fork the code base. The split might mean higher maintenance costs, but it'll offer much more flexibility.
