Windows 95 vs. OS/2 Warp: Shootout at the OS Corral

by Randall C. Kennedy



Unless you've had your head buried in the sand for the last year you've undoubtedly heard the rhetoric: Microsoft wants your desktop computing business, and so does IBM. Both are fielding 32-bit operating systems designed to take your organization's desktops into the world of 32-bit operating system (OS) computing.

Microsoft's solution is based on its popular Windows 3.11 operating environment. IBM's -- OS/2 Warp -- is the third major version of OS/2, a tried-and-true, industrial-strength 32-bit OS. And, of course, both vendors are doing their best to portray the other guy's solution as inferior.

In a perfect world, a simple head-to-head comparison would silence such rhetoric. The product that fared best overall would win, and anyone with half a brain would then switch to the superior product.

Unfortunately, such a comparison is currently impossible for most desktop computer users since, despite all the media hype, only one of these products -- OS/2 Warp -- is actually shipping and available to anyone who wants to use it. As of this writing, Windows 95 is still in beta with a promised ship date of August.

Fortunately, enough of the Windows 95 architecture has been publicly exposed to allow at least a preliminary examination of its design. And upon close scrutiny, Microsoft's next-generation Windows product doesn't look like much of a contender for the 32-bit desktop crown -- which currently goes to OS/2 Warp by default. In fact, Windows 95 looks suspiciously like a stopgap product designed to placate current Windows users until desktop hardware and application software catch up to the resource hungry Windows NT.

"I do have one machine running (Windows) NT, but overall I found Warp much more compatible with Windows 3.1 applications." -- John C. Dvorak, PC Magazine, March 14, 1995

To overcome the limitations inherent in Windows 95, it appears that Microsoft wants users to buy all new 32-bit applications. Which raises an interesting point: The biggest appeal of Windows 3.xx was that users could keep their "old faithful" DOS applications. DOS -- and DOS-based applications -- have been around for 12 years. Is everyone suddenly going to be willing to walk away from that?

Probably not. Which is a big point in OS/2's favor; it lets users enjoy the benefits of an industrial-strength 32-bit OS, without giving up their favorite DOS applications. With Windows 95, you'll need to buy new 32-bit Windows applications to exploit similar benefits.

Of Apples and Oranges
A careful scrutiny of Windows 95 reveals an architecture that appears to be very weak. Once believed to be a completely new 32-bit operating system -- and thus a serious challenger to OS/2 -- Windows 95, judged on the merits of its basic, technical architecture, is essentially an extension of the DOS/Windows 3.1 hybrid.

While Microsoft is doing its best to blur this particular issue by including lots of bells and whistles with the product, it has become painfully clear that, in areas that count -- such as internal architecture, object orientation, and application support -- Windows 95 doesn't measure up to the architectural strengths of OS/2 Warp.

But comparing Windows 95 to OS/2 Warp is really comparing an apple to an orange: The only thing they have in common is that they are both pieces of fruit. OS/2 is a fully 32-bit, preemptive multitasking, object-oriented operating system. Windows 95 is not.

OS/2 is capable of juggling dozens of complex, multithreaded applications simultaneously with true preemptive multitasking. Windows 95 is not.


 * WIN 95 Beta Lays Egg
 * Operating System Freezes Running 32-bit Multitasking Apps.
 * "What was publicized as the largest beta program in history failed to turn up a fundamental architectural flaw in Windows 95 that causes the operating system to freeze when multitasking a 32-bit application..."
 * -- Cover article in InfoWorld, March 27, 1995

OS/2 features robust inter-application protection and can gracefully recover from the most severe application failures. Windows 95 cannot.

If you think you see a pattern beginning to emerge, you're right.

Unfortunately, many in the industry insist on making just such an "apples and oranges" comparison. And sadly, most are missing the real point: Bells and whistles mean very little to a user who has just lost a week's worth of work because of an OS that was unable to recover from a simple application failure.

Unless you get the plumbing right, you might as well forget about adding fixtures, installing tile, and positioning the toilet paper rack; there's simply no point in dressing up a kludge.

To provide a slightly different perspective, I offer the following alternative to the OS/2 Warp versus Windows 95 status quo. In the following pages I'll take a look below the surface and examine just how well Windows 95 really stacks up to the industry leader in the three areas that matter most: OS architecture, user interface, and applications.

All of the observations here are based on my personal, first-hand experience with the latest release of OS/2 Warp and the Windows 95 beta and the many technical documents each vendor is currently circulating. And since examining a moving target like the current Windows 95 beta is inherently difficult -- designs change, features are added and removed, and so on -- I've done my best to stick to the core characteristics, i.e., those that are fundamental to each operating system's design, and those that will likely remain unchanged in the commercial release.



OS Architecture
In terms of architecture, OS/2 Warp and Windows 95 occupy opposite ends of the OS spectrum. From the beginning, IBM designed OS/2 with heavy multitasking in mind. All components in the OS -- from input/output subsystems to memory management routines -- accommodate the likelihood that multiple, concurrent applications would vie for their services at any given time. Concepts like reentrancy, where a piece of code's architecture lets more than one program execute it at once, are fundamental to the overall OS/2 architecture. In short, OS/2 was born to multitask.

On the other hand, Windows 95 is a direct descendant of Windows 3.1 and, as such, has inherited many of its predecessor's flaws. To fully understand the nature of these limitations, it's necessary to first examine the origins of the Windows 3.1 architecture and how they differ from OS/2's.

Microsoft originally designed Windows as a graphical extension to DOS. Early versions of the product, most notably Windows 2.0, were real-mode DOS applications that used a combination of conventional and Expanded Memory Specification memory to run relatively simple, single-threaded application programs. Barely functional, it was a crude design. Needless to say, most in the industry rejected it wholesale.

With the introduction of Version 3.0 in 1990, Microsoft attempted to enhance the capabilities of Windows by porting much of its code to 16-bit protected mode. The idea was to make Windows a more attractive development platform by eliminating one of the major complaints about its design: the lack of access to extended memory, which required protected mode. Moving to protected mode meant more memory for applications which, in turn, meant that developers were free to design larger, more complex products.

When combined with the popularity of such Microsoft applications as Excel and Word, this strategy worked. Independent software vendors flocked to Windows in droves, and the product's relatively modest resource requirements and excellent backward compatibility -- after all, it's just another glorified DOS shell -- proved attractive to a skittish marketplace that balked at the idea of a "new" operating system. So, while early versions of OS/2 languished for a variety of reasons, Windows Version 3.0 -- and later, Version 3.1 -- filled the void.

However, in making its move to protected mode with Windows 3.0, Microsoft made a number of dubious design decisions that are coming back to haunt it. One of these decisions was to favor backward compatibility (with real mode Windows applications) over pre-emptive multitasking. Instead of isolating an individual application into its own private address spaces, as is the case with OS/2, Microsoft lumped them together into a single 16-bit Virtual Machine (the System VM). There they shared central processing unit (CPU) time and memory resources with the operating system code itself; both the OS and applications occupy the same memory space under Windows 3.xx.

While this compromised architecture helped to ease the transition from real mode to protected mode for application developers, it also made it impossible for the operating system to effectively multitask programs. Pre-emptive multitasking, the preferred technique on the Intel CPU architecture, requires each program to exist in its own address space. Windows' single System VM model simply won't allow this, so applications must compete with one another -- and the operating system -- for what would normally be a single application's processor time slice in a true pre-emptive system.

Microsoft did attempt to provide a stop-gap solution to this problem by encouraging application developers to yield control of the CPU from time to time and thus allow other programs to execute. This modification spawned the now infamous term "cooperative multitasking" and in general has made life miserable for anyone trying to develop time-critical applications under Windows. Windows simply cannot guarantee CPU time to any particular application in a cooperative system, since the currently executing program has complete control of the processor.

Early in OS/2's design phase, IBM chose to avoid this limitation by insisting that each application be isolated into its own private address space, or Virtual Machine (VM). This implementation guaranteed that the operating system would have ultimate control of the CPU, and that it could give sensitive programs extra processing time, as needed. The wisdom of this decision has been verified by members of the development community, who praise OS/2's multitasking prowess.

With Windows 95, Microsoft is attempting to make up for past sins by grafting pre-emptive multitasking on top of the original single System VM Windows design. It can do this because the new Win32 applications it is encouraging software developers to write are 32-bit programs and, as such, can be isolated into their own virtual machines without disrupting the existing System VM model.

Unfortunately, these applications still need to call on the operating system for fundamental services, such as drawing windows and managing bitmaps. And these functions are, by and large, still handled by 16-bit code residing in the System VM.

The result of this 32-bit design relying on 16-bit model (typically referred to as "thunking") is that the 16-bit, non-reentrant, single-threaded Windows 3.1-era code in the System VM forms a bottleneck that impairs the environment's ability to effectively multitask applications.

So, while the Windows 95 architecture is adequate for light to moderate multitasking on a fast computer, it begins to break down under many multithreaded applications. In my view, the situation is even more grim when you introduce a 16-bit Windows 3.1 application -- because the environment essentially reverts to the cooperative multitasking model as long as the 16-bit application is executing.

User Interface
Beauty, some people say, is only skin deep. With Windows 95, it's only shell deep. Instead of building a true, object-oriented user interface, Microsoft has chosen to dress up the existing Windows shell components, adding new capabilities without changing any of the underlying support structures. Basically, Microsoft has cut corners with Windows 95 -- and it shows.

"People who like computers will like OS/2 Warp. People who are still weaning themselves from DOS programs will love Warp. And people who have found true multitasking useful have few alternatives." -- John C. Dvorak, PC Magazine, March 14, 1995

The best way to demonstrate the shortcomings of the Windows 95 interface is, ironically, to compare it with OS/2 Warp and the Workplace Shell. OS/2 has long been praised for its sophisticated, object-oriented user interface. But, while the environment is indeed visually appealing, its real power lies below the surface, in the operating system's System Object Model (SOM).

SOM is the foundation for OS/2 Warp's object-oriented capabilities. It's the plumbing that makes all of those Workplace Shell features work so well. When manipulating an object on the Workplace Shell desktop, SOM is there, working in the background to ensure that the operation is interpreted properly and that the resulting action(s) obeys the established guidelines of object-oriented behavior.

You can see SOM in action by simply working with OS/2 Warp for a while. When you drag an object's icon across the desktop, SOM tracks the movement and records the object's new position. Move an object between folders, and SOM notes the change in the object's location. Drag a document to a printer icon, and SOM responds by launching the associated application's printing code, letting it service the print request.

All of this object tracking and monitoring is a critical part of the Workplace Shell's architecture. Without SOM, OS/2 Warp would have no way of maintaining the many complex object interactions -- print operations, object shadows, templates, etc. -- that make the Workplace Shell such a powerful user interface environment.

Now that the benefits of a comprehensive SOM are apparent, I can summarize the flaw in the Windows 95 interface in just four words: It doesn't have SOM.

Windows 95 has nothing comparable to OS/2's SOM; its entire interface is based on static graphical images and fragile .INI files. As is the case with Windows' internal architecture, the fixtures are quite pleasing to the eye, but the plumbing's a mess.

Just as the power of SOM is apparent when working with OS/2 Warp and the Workplace Shell, so are the flaws in Windows 95's user interface when performing even simple housekeeping chores. For example, both Windows 95 and OS/2 Warp support a form of object aliasing, or the ability to create a reference to an object and then place this reference anywhere in the system. OS/2 calls them shadows; Windows 95 calls them shortcuts. But whatever the name, only one of these environments, OS/2, actually implements the concept reliably -- e.g., in a manner that is flexible and won't break under stress.

Under Windows 95, a shortcut is a static link based on path information extracted from the underlying file system. Move the original -- for example, drag its icon to a new folder -- and the link is broken. This limitation is caused by a link that is static and is based solely on path information. Such a model is inherently fragile because of the inflexible nature of the link itself. Shortcuts are based on the assumption that the original will remain in the same place.

To its credit, Windows 95 does a respectable job of repairing broken shortcuts by scanning the disk volume where the original last resided for a file with a similar size and date stamp. However, it doesn't always locate the correct file and, since the scan is limited to the original volume, it will fail completely when the object is moved to a different disk or a network drive.

"There is little doubt that Warp is a more mature operating system than its perceived nemesis, Windows 95." -- Barry Nance, Byte magazine, March 1995

So, how does OS/2 Warp handle such a situation? It doesn't have to, since SOM dynamically tracks the link between the original and its shadow. Whereas Windows 95 must search for the original and make a "best guess" at its location, OS/2 Warp never breaks the relationship in the first place. SOM is on the job, tracking all object interactions in the Workplace Shell and making sure that sensitive relationships -- including shadows -- remain valid.

Application Support
If the comparison of Windows 95 and OS/2 Warp is beginning to look a bit lopsided, don't say I didn't warn you. The final nail in the proverbial coffin involves the manner in which each OS provides support for various application types.

As noted earlier, both OS/2 Warp and Windows 95 run native 32-bit applications in their own separate address spaces, or Virtual Machines. This is also how each OS handles the execution of DOS applications, though there are some limitations in the Windows 95 implementation, most notably the need to specify any required DOS device drivers at boot time as part of CONFIG.SYS. (OS/2 lets the user load them dynamically, as part of each Virtual DOS Machine, using the Settings Notebook.)

But where the two differ the most is in the way that each handles the execution of legacy 16-bit Windows applications. OS/2 Warp treats a Windows application just like a DOS application: by creating a Virtual DOS Machine (VDM). OS/2 then loads both a runtime copy of Windows and the application itself into this VDM, creating an amalgamation known as a Win-OS2 session. OS/2 can create lots of these Win-OS2 sessions, and 16-bit Windows applications can either share a single VDM, or users can isolate each into its own private VDM.

"So, while you're waiting for Windows 95, Warp may make you forget about Windows 95 completely." -- Bernie Yee, PC Today, March 1995

This latter option is one of the major Windows-specific benefits of OS/2. By isolating individual applications into their own VDMs, OS/2 achieves a level of inter-application protection that is impossible under Windows' single System VM model. Additionally, OS/2 is able to pre-emptively multitask these applications, since each VDM has its own address space and thus its own time slice on the CPU.

In stark contrast, Windows 95 is stuck with the limitations it inherited from Windows 3.xx and the single System VM model. All 16-bit Windows applications execute in the same address space, just as they did under Windows 3.xx. A failure in any one application can create a domino effect, causing all other applications in the System VM to crash.

Worse still, the original Windows 3.xx design placed the OS code in the System VM, alongside the code of all running applications. Windows 95 continues to rely on this code for key system services; so, in addition to crashing other applications, the failure of any one application potentially can bring down the entire OS. Anyone who's ever experienced a general protection fault (GPF) under Windows 3.xx knows this problem not only may occur, but is likely to occur. The GPF is alive and well in Windows 95.

Yet another impact of Windows 95's reliance on the single System VM model is that it is impossible to get around the cooperative multitasking of 16-bit applications. Since they're still lumped together in the System VM, Windows 95 has no way of assigning them individual time slices, like OS/2 does with separate Win-OS2 sessions. Thus an "ill-behaved" application that doesn't yield CPU well can make life miserable.

To overcome Windows 95's limitations, it appears as if Microsoft expects users to buy all new 32-bit applications.

A Fruitful Conclusion
I said at the beginning of this article that comparing OS/2 and Windows 95 is like comparing an apple to an orange. I hope the reasoning behind this statement is now more clear.

"Corporate customers who have outgrown Windows 3.1 and are waiting for Windows 95 to come to the rescue could be in for countless problems and a colossal disappointment." -- Nicholas Petreley, InfoWorld, March 27, 1995

Byte for byte, OS/2 is a superior product. Its architecture is far more robust and capable than the Windows 95 hybrid, and its support for DOS and Windows applications is both more flexible and more reliable, thanks to the separate Win-OS2 sessions option. Finally, while the Windows 95 interface may look object oriented, it's purely superficial. The lack of a true object model can make complex interactions nearly impossible to track or maintain.

Once again, Microsoft is poised to release a cosmetically sophisticated product into the marketplace. With Windows 95, what you can't see can hurt you. This scenario happened earlier with Windows 3.xx -- Microsoft paid scant attention to the internal details and instead focused on aesthetics. The key difference then was that Windows 3.xx provided a superior graphical interface for the legions of DOS users, who were (and largely still are) perfectly happy with the performance and utility of their current, DOS-based applications.

Windows 95 is, in my opinion, just the latest in an ongoing stream of products that are short on technical merit and long on hype.

Meanwhile, OS/2 Warp awaits those who yearn for something more: more power, more sophistication, more reliability. So, before you get caught up in the imminent Windows 95 hysteria, give today's 32-bit OS/2 Warp a test drive, and see for yourself why a good foundation can make for a much more productive workplace.


 * Don't Take My Word for it
 * Despite the fact this article is written by an independent consultant, you may question its reliability, simply because it's appearing in an online IBM publication.
 * Fair enough. But, consider this: As a consultant I've done as much work with Microsoft products as I have with IBM products. A quick glance at the author's biography accompanying this article reveals that I was a contributing editor at Windows Sources magazine for nearly two years, and when it comes to Windows NT, I've literally written the book.
 * Still not convinced? Fine. Don't take my word for it. In fact, I strongly urge you to get a copy of OS/2 Warp, Version 3 and check it out for yourself. And while you're waiting for Microsoft to deliver Windows 95, you might want to consider what other independent industry experts have to say about these two operating systems.
 * To help you do that, I've included a number of citations and quotes from recent computer industry reports. I've included the publication's name and date in case you want to read the entire report.

Author
Randall C. Kennedy is a freelance writer and computer industry consultant. He is author of Migrating to Windows NT and a contributing editor with Windows Sources. A Certified NetWare Engineer, Randall is recognized as an expert on desktop operating system technology, and consults on a regular basis with information technology companies.

Reprinted of Software Quarterly: IBM's Magazine of Software Technologies.