Back in the dark ages, when Microsoft released Windows NT 3.5, I decided to use NT as my primary desktop OS. I was tired of Windows 3.x's tendency to fault at inopportune times, and my business didn't require me to run legacy applications that NT couldn't handle, so migrating to NT seemed like the right move.
But after I migrated to NT, I discovered an interesting phenomenon: Although NT rarely crashed, poorly written applications often locked up the console. Even though the system didn't go down and background processes continued to function, I couldn't make the system respond. Sometimes the system recovered console control and sometimes I was able to kill the offending application from Task Manager, but significantly often, NT behaved like a Windows 3.x system that had generated a General Protection Fault (GPF). In those cases, my only option was to hit the power switch for a hard reboot. This problem was unsolvable from the user perspective, and my complaints to software vendors generally fell on deaf ears. Few vendors were concerned about the behavior of their applications on a system they considered to be Microsoft's server OS.
When Microsoft released NT 3.51, I got one of the first-generation multiprocessor workstations for NT. With 90MHz dual-Pentium processors and a whopping 32MB of RAM, this Intergraph workstation was the ultimate desktop NT system. But most important to me, neither bad applications nor faulty Win16 on Win32 (WOW) execs prevented the system from working. Rather than only occasionally being able to recover from a hung application in the foreground, I was almost always able to get to the Task Manager and kill the recalcitrant application. And as I worked with the system, I discovered something else: This dual-processor box was much peppier than a one-CPU system with the same processor (or a processor of similar speed).
NT seemed to run well with two processors. Only a few of the available vertical applications could take advantage of the dual-processor configuration, but typical office-automation applications and 16-bit applications running in the Virtual DOS Machine (VDM) ran better with two processors. The second processor let NT go about its business unencumbered by the applications, and the applications didn't have to share a processor with the OS. In addition, the few vertical applications that could take advantage of the second processor (e.g., Microsoft Excel performing background recalculations) received a noticeable performance boost.
When Microsoft released Windows 95, I was still running this 90MHz system (although I had upgraded to 128MB of RAM). When the 32-bit Win95 applications hit the market, I made two discoveries that really annoyed me. First, vendors were still using the single-threaded development model even though they were writing 32-bit applications. Most vendors didn't use the serious threading that lets NT and symmetric multiprocessing (SMP) hardware make the most of their applications. Single-threaded applications with a linear behavior pattern didn't really take advantage of either the OS or the hardware. Second, the Windows Logo program was meaningless. Originally, the program required applications with the Windows logo to run on NT (or have an NT version in the same box), provide similar functionality, or degrade gracefully. However, without fanfare (or a press release), Microsoft removed the NT support requirement from the program. This move didn't exactly encourage vendors to write applications that took full advantage of NT, much less an SMP desktop.
By this time, my work habits had changed. Instead of opening and closing applications as I needed them, I had 10 to 15 applications open at once. I kept applications that I frequently used (e.g., Lotus Notes, Post Office Protocol 3—POP3—email program, word processor, spreadsheet) open for days (if not weeks) at a time, and I kept applications that I used less frequently (e.g., compilers) open only when I needed them. This approach was much easier than working on Win95 and having to keep track of open and active applications so that I didn't run out of memory. However, the ability to keep applications open and be productive was not only because of NT, but also because of the dual-processor hardware.
When Microsoft released NT 4.0, I upgraded my system software and began a serious campaign demanding that application vendors write well-threaded applications that would run on Win95 systems but really shine on NT—and especially SMP NT—systems. This campaign pretty much failed. Vendors (including Microsoft) didn't see the value of building standard business applications that took full advantage of NT's capabilities. Meanwhile, processor speeds increased, and I tested and reviewed just about every state-of-the-art system released but didn't discover one that ran NT significantly better than my now lowly 90MHz dual-Pentium processor system did. I almost upgraded when the 200MHz dual-Pentium Pro workstations arrived, but the price difference for what was only an incremental performance improvement held me back. In addition, when it came to running office-automation applications, writing HTML, managing networks, and performing the occasional C++ compile, the difference between the two systems wasn't enough to merit the aggravation of upgrading to a dual-Pentium Pro.
When Intel released the Pentium II processor, I upgraded my main server first. My custom-built 133MHz dual-Pentium processor's CPU utilization rate was consistently in the 60 percent range when I ran NT Server 4.0 with Internet Information Server (IIS) 4.0 hosting a half dozen Web sites and an NT implementation of MetaInfo's Sendmail. Web server and mail-processing capabilities were quick enough, but console response was slow, and everything worked best when I managed the system remotely. I upgraded the system with a first-generation Pentium II motherboard and moved every component from the old system (except the processors) to the new computer. I solved some minor bugs by upgrading or installing NT, and the new system ran the same applications with a CPU utilization rate averaging less than 10 percent. This operation was much more efficient and convinced me that a desktop upgrade was due.
For the desktop upgrade, I saved only the SCSI subsystem and its attached devices. When I moved to a second-generation Pentium II motherboard with a pair of 266MHz processors and Fast Synchronous DRAM (SDRAM), I expected my new desktop's performance to really wow me. However, the system seemed only slightly faster than before. The upgrade didn't disappoint me—for some applications (e.g., when I loaded a half dozen 12MB TIFF files into an image editor), the performance difference was amazing. Compared to a uniprocessor Pentium II, my system's performance was definitely better, but it wasn't a showstopping performance that made me scream, "SMP for the desktop!"
Then a box containing Dell Computer's new entry-level 410 workstation system showed up. This system had dual 450MHz Pentium II processors, 256MB of RAM, and Fast/Ultra Wide SCSI hard disks. The software setup went quickly, and the system performed very well. When I started using applications (the Office 2000 beta and Visual Studio 6.0, primarily), I thought, "Wow! This sucker really smokes!" Compared to my 266MHz dual-Pentium II processors and a 400MHz Pentium II uniprocessor, the Dell 410 was noticeably faster. Given the Dell 410's relatively low cost and the fact that most major system vendors offer similar products, I think I can finally declare that the desktop is ready for SMP for all users. I can only imagine what will happen when application developers take advantage of these platforms.
