Some of the main topics in this chapter are
This chapter looks at OS/2 and Windows NT, both separately and comparatively. OS/2 merits discussion for several reasons. Not only is it one of the longest-lived network operating systems for the PC/Intel platform, but like various breeds of UNIX, OS/2 is a NOS that you'll find Windows NT Server both competing with and interoperating with on a regular basis.
The first version of OS/2 debuted in late 1987, with many of its critical components, such as development tools, not available until 1988. In 1988, Microsoft released Windows 2.0, a big improvement over 1.0, and the first version of Windows that excited both developers and users. By Windows 3.0, Windows outsold OS/2 enormously.
1.0 debuted in late 1987 with many downfalls. One of the major pitfalls of OS/2 was the high memory demand of the operating system. IBM recommended that OS/2 be run on a system with 8M of memory in a day when 2M of memory was quite expensive. OS/2 also needed a high-end graphics sub-board and a larger than average hard drive to gain the benefits this OS had to offer.
OS/2 had a clear advantage over DOS, and early versions of Windows, in that it was able to make use of every byte of user memory. DOS and windows were both landlocked by the restrictions of the lower 640K of RAM in the PC: Every program that ran had to occupy at least some memory in that space--it didn't matter how much extended or expanded memory remained free; the result was and "out of memory" error that had many users tearing their hair out in disgust. In contrast, OS/2 never suffered from this limitation. Drivers and programs could be loaded into any available memory space.
OS/2 1.0 still had it's shortcomings; the development tools for the operating system were not available until almost a year after the operating system's release. Also in 1988, Microsoft released Windows 2.0, a big improvement over 1.0, and the first version of Windows that excited developers and users alike. Once Windows 3.0 was released, it outsold OS/2 enormously.
IBM gritted its teeth and came out with OS/2 2.0, a big improvement over 1.0 because it featured a lower memory footprint and a graphical shell, the Workplace Shell. The shell was designed to be as extensible and intelligently designed as possible, enabling a smartly written program to take full advantage of the way objects behaved in the shell. Drag-and-drop operations, for instance, could be implemented from any object and to any other object. Also, REXX, OS/2's extremely powerful scripting language, became popular.
OS/2 sold strongly--one million copies were shipped in six months of 1992 when it was first released. It attracted many high-level users and network administrators (OS/2's LAN Manager, their network extension for OS/2, was already available and was being refined as OS/2 2.0 came out). Features such as REXX attracted UNIX users, who were intimately familiar with high-level scripting as a way of life in UNIX-land, and the graphical shell made it an appealing alternative to entirely command line-based operating systems. From then on, OS/2 established a strong and seemingly impenetrable niche in the market, as government agencies, financial institutions, law-enforcement groups, and corporations slowly abandoned their now antiquated UNIX mainframe hardware and migrated to the more flexible PC with OS/2 platform.
OS/2 had a clear advantage over DOS, and later Windows, in that it was able to make use of every byte of user memory. DOS and Windows were both landlocked by the restrictions of the lower 640K of RAM in the PC: Every program that ran had to occupy at least some memory in the lower 640K zone. When DOS or Windows ran out of memory in that space, it didn't matter how much extended or expanded memory remained free; the result was an "out of memory" error that had many users tearing their hair out in disgust. In contrast, OS/2 never suffered from this limitation. Drivers and programs could be loaded into any available memory space.
However, even the first version of OS/2 was shipped with very high memory demands. IBM recommended that OS/2 1.0 be run on a system with 8M or more of memory. OS/2 also needed a fairly high-end graphics sub-board and a larger-than-average hard disk to achieve the best results.
Today, OS/2 can be found in many of the same places--managing databases, handling mail, Web, or ftp servers, and sundry other formerly UNIX-only tasks. It has also been packaged and sold more blatantly as a desktop operating system (OS/2 Warp), positioned as a competitor against Windows 95. It's also a staple in travel reservation systems, point-of-sale systems, internal banking terminals, and automated teller machines.
After the limited success of OS/2 2.0 on the desktop, IBM decided to try marketing OS/2 more aggressively as a desktop product, but with snazzier packaging, a more user-friendly interface, and built-in Internet connectivity. They renamed the product OS/2 Warp to bring it more into line with their new sensibility about it.
The first version of OS/2 had a GUI, known as Presentation Manager, but it was not widely exploited by software at first. For the most part, OS/2 1.x programs used a character-based interface. This was generally not seen as a deficiency because at the time, GUIs were extremely rare, even on mainframes. The memory and processing overhead required by a GUI was at the time considered to be exorbitant. OS/2 1.0's command-line interface worked very much like DOS, and in fact many of the same commands existed--FORMAT, DIR, and so forth--with only minimal changes.
OS/2 version 2.0 introduced the user interface called the Workplace Shell. The Shell used established conventions of many different GUIs; for example, the "icons-on-the-desktop" look was borrowed from the Macintosh, and "right-click-for-context-sensitive-menus" was borrowed from Motif and the whole X Windows genre of user interfaces. There were some cosmetic changes to hide this; for example, instead of a trash barrel, there was the Shredder.
From OS/2 version 3.0 on, the Workplace Shell has featured a "Launchpad" to enable better organization of the most commonly used desktop objects. This was probably conceived in response to many reports of even expert computer users being bewildered by OS/2's 2.0 desktop--many users were at a total loss about how to do certain extremely simple things, such as shutting the computer down! The Launchpad has configurable buttons and "drawers" that can hold collections of objects and can be docked anywhere on-screen.
For Warp 4, the WarpCenter was added, exhibiting one of the ironies of the evolution of OS/2's desktop design: Warp 4's WarpCenter resembled, more than anything else, the cascading Start-button/Taskbar design of Windows 95 and Windows NT 4.0. It's actually a little closer to the kind of desktop controls that Norton Desktop for Windows 95 features, such as the free disk space and free memory gauge. In any event, it's strongly inspired by Windows 95 (and in turn, Windows NT) and shows how far OS/2 has come to emulate its more commercially successful rivals.
At the time Windows 95 and OS/2 Warp were introduced, the Internet was reaching the mainstream. Originally, ISPs wrote specialized programs that would enable access to the Internet, but eventually the scope shifted to enabling OS-wide exploitation of Internet connectivity. In both Windows 95 and OS/2, this was done by providing a program that automated the process of dialing up and making the connection, leaving the user free to run whatever Internet-enabled programs he or she sees fit. This ease of functionality was added to Windows NT 3.51, as well. Those who use either NT or 95 know it as Dial-Up Networking--or at least one of the many ways Dial-Up Networking is put to use.
OS/2 Warp also bundled a series of Internet programs--a USENET newsreader, mail program, simple Web browser, and Gopher and ftp clients. Windows 95 and NT also came with a simple ftp client and a mail client (the Microsoft Exchange client), but until recently, news and Web browsing were only available separately. Microsoft now addresses this deficiency by bundling Internet Explorer 3.0 with Windows NT and Windows 95, which includes not only a Web browser, but e-mail clients and a USENET newsreader. Also, the OS/2 dial-up system is not as tightly integrated into the OS as the Dial-Up Networking components are in Windows; the OS/2 Internet dialer has more the flavor of an add-on program such as Trumpet Winsock, rather than a core component of the operating system.
More disappointingly, the whole of OS/2's networking stack has this same flavor. Although there's a standard set of system-wide APIs for networking, the system was not designed from the ground up to integrate networking and its associated processes as tightly as Windows. Part of this is almost certainly due to the way OS/2 manages system components.
To give OS/2 users real-world productivity out-of-the-box, IBM bundled a small office suite with OS/2 that includes a word processor, spreadsheet, and flat-file database program. These are native OS/2 applications. Ironically, these native OS/2 applications were not as fast, at least in their first OS/2 Warp incarnation, as Microsoft's then-16-bit Office suite, which ran under OS/2 in Windows emulation mode. Those programs were also later dwarfed by Lotus's program suite, which was a functional duplicate of the one for Windows. NT is not nominally sold with commercial applications, but many system bundles now include Office 97 as a standard addition.
An advanced voice recognition technology that integrates tightly with OS/2, VoiceType comes bundled with Warp 4 and enables you to command any OS/2 program, including the shell, by speaking. IBM even went so far as to bundle a microphone with OS/2 Warp 4 to promote the use of VoiceType. Development tools are sold separately. NT has no such features out-of-the-box, but VoiceType for 32-bit Windows is available from IBM as a separate product, making obsolete OS/2's claims to exclusivity in that regard.
Following closely on the heels of expanded Internet support for OS/2 came Java support. Unlike Windows NT, which only comes with Java support through its Internet browser, OS/2 comes with a discrete VM engine that enables you to run standalone applications in their own windows. Many hope that the availability of Java and application suites written specifically for Java will give OS/2 the "applications edge" that it needs.
Windows NT 4.0 also ships with Java support but only in the form of applet support under Internet Explorer 3.0. NT 4.0 does not ship with a standalone application executor for Java, but one is downloadable free of charge from Sun Microsystems at http://www.sun.com.
A longtime OS/2 feature, REXX is a high-level scripting language that enables users to create fairly powerful programs without having to do a lot of work. REXX has been one of the major attractions of OS/2 since REXX's inception, and a great many custom scripts and REXX development tools have been produced, both commercially and as shareware.
With the addition of Internet connectivity tools to OS/2 came a revision of REXX named NetREXX. NetREXX is derived from both REXX and Java and enables users to create programs and applets for Java with greater ease than if they used Java. IBM also provides a NetREXX compiler, NetREXXC, that runs on Java, enabling NetREXX to go cross- platform.
The closest thing to a scripting language in NT is the command-line batch language that is an offshoot of the original batch-file processing language included with DOS. Although it has been made slightly more robust with features such as a task scheduler, it's still not comparable to something as refined as REXX. Future releases of NT will be designed to include Visual Basic as a system-wide scripting standard.
Another recent addition to the REXX family is Object REXX, which extends the functionality of REXX with object-oriented features. The best thing about Object REXX is that it has been announced for 32-bit Windows (both 95 and NT). Object REXX provides open interfaces to many system functions and to other applications, such as TCP/IP sockets, DLLs, and C++ programming functions. The upshot of this is that another of OS/2's formerly exclusive features is now available for Windows NT.
OS/2 and Windows NT share a good deal more than first glance might reveal. Most of the important similarities are "under the hood," or matters of design and the policy of standards. Some of the similarities relate to the way certain features are implemented on both platforms.
Before Windows NT, 95, or OS/2 came along, there was DOS, and later Windows 3.1. Windows was written as a 16-bit program and not designed to exploit the full capacity of the 386 processor (and later the 486 and Pentium). This meant many restrictions of performance and memory handling.
With OS/2 and Windows NT, applications can address all available memory, period--no page or block address schemes. Also, device drivers can be loaded anywhere in memory, making it possible to write very sophisticated and powerful drivers--and enabling many more of them to be loaded simultaneously because both OS/2 and Windows NT rely on whole suites of drivers as their way of talking to the hardware in the machine.
As computer hardware became more modular and interchangeable, a demand arose among operating systems. Because the number of application programs was in- creasing and the work required for each of those programs to support all available hardware was exploding exponentially, programmers and hardware manufacturers alike pushed to have a scheme on the PC that resembled what was already available on UNIX machines. Instead of having programs talk to hardware directly, they would talk to a device driver, a piece of software that sat between the program and the hardware, standardizing communications between both. Good examples of early hardware drivers for DOS were the FOSSIL drivers, which were used by many BBS programs to standardize communications between the BBS software and the modem (or modems). When OS/2, and later, Windows took off, the driver model became much more UNIX-like, in that the programs would talk to the OS, and the OS in turn would talk to the driver.
UNIX's implementation of drivers was--and still is, for the most part--far different from the way DOS, OS/2, and Windows have used them. UNIX requires that device drivers be compiled directly into the kernel. Most UNIXes use the compiled-into-the-kernel method because it saves space and processing power although the overhead gained by doing so is, on current computer hardware, rather minimal. This is an outgrowth of when UNIX was designed to run on machines that are now routinely outperformed by and have less storage space and RAM than the lowest-end desktop computer.
OS/2 and Windows NT both load their drivers at boot-time. The advantages of dynamically loading drivers at boot-time far outweigh the disadvantages. It makes configuring and testing an NT or OS/2 machine far easier and faster and minimizes the amount of work done by the administrator. Adding and removing driver references in NT and OS/2 involves little more than selecting or deselecting an item from a list and then shutting down and rebooting the computer. Sometimes a reboot isn't even needed.
OS/2 software can be run under Windows, and Windows software can be run under OS/2. However, there are exceptions in both directions:
Windows NT 4.0 uses the now-famous Windows 95 interface; earlier, in its 3.1 and 3.5 versions, it used the classic Windows 3.x interface. OS/2 has Presentation Manager and the Workplace Shell. One significant difference between OS/2 and Windows NT is the way the GUI is integrated with the OS.
The graphical interface used on OS/2 is Presentation Manager, which is not the graphical shell but rather the standardized interface used by all graphical OS/2 programs, including the shell, to interface with OS/2's core. Presentation Manager was written in some of the same spirit as X or GEOS: It was loaded only if needed and could be removed for running character-only apps. The concept was actually closer to GEOS than X in its eventual deployment--a window manager and font handler not just a set of primitives for displaying graphics.
Today, Presentation Manager is more or less the de facto standard for OS/2, even though it can still be decoupled from the OS/2 kernel in a pinch. Many remarkable products that substitute for the shell and use Presentation Manager, such as Stardock's Object Desktop, have been developed.
By contrast, NT's graphical interface, while not strictly speaking part of the kernel, is still inseparable from it. NT loads its graphical interface shortly after the kernel has finished loading all of its needed device drivers. A different graphical interface cannot be substituted for the one already built into Windows NT. A different shell could be integrated into NT, and such products have been written, but the underlying interface methodology is unchangeable. Microsoft decided to commit to a basic interface structure for Windows early on, with revisions to the look and feel only coming every so often (as they did, quite dramatically, with Windows NT 4.0). This way, applications developed for Windows NT would always have a certain amount of consistency of look and feel. Consider the number of applications written for Windows (3.x, 95, and NT alike), and the ways they successfully exploit the interface and the extensions that have been written for it.
Both OS/2 and Windows NT have been deployed in special "server" editions, respectively named OS/2 Server and Windows NT Server. The reason for the discrete editions of both programs is plain from the point of view of the companies that produced them: The network components of OS/2 and NT are some of the most critical and long-wrangled-over components of the whole OS, and it makes sense for the companies to try to recoup their development expenses in a way that charges the people who make the most use of them.
OS/2's and NT's server editions both support many of the most common server-based functionalities:
One of the incentives provided by Microsoft to encourage the purchase of Windows NT Server for use as a server, as opposed to NT Workstation, is the implementation of a kernel-level inbound connection limit on NT Workstation. No more than twelve inbound connections from separate machines can be made to an NT Workstation machine at any one time. NT Server does not have a kernel-level limit but does require per-seat or per-machine licensing for the number of connections to be made to the system. Conventional OS/2 Warp has no such restrictions, but like Windows NT Workstation, does not come with many of the tools needed to properly administer and maintain a server or domain.
NT Server also has many internal differences from NT Workstation that make it more suitable for a server, such as a network stack that more intelligently balances loads and makes more use of live RAM. Because of this, NT Server is not as suited for desktop-type applications. It's certainly possible to run desktop applications on NT Server, but NT Workstation is more designed for it.
Like NT Server versus NT Workstation, the OS/2 Warp Server product also has more than one edition. The distinctions between them are rather subtle:
This section addresses a problem common to system administrators who are migrating between OS/2 and Windows NT. Both operating systems have a tendency to lionize the system on which they're installed, making it difficult to have more than one operating system exist gracefully on the same computer.
There's a real need in various situations to have OS/2 and Windows NT operating in a dual-boot fashion on the same machine. Most commonly, the user is trying to migrate software or data from one platform to the other. Sometimes, a software developer might test a program that enables interoperability between the two operating systems. Other times, a user of one OS might try to recover data from another OS partition in the same system.
Normally, OS/2 and Windows NT are not designed to coexist on the same machine, due to a fair number of incompatibilities in disk formats, handling of boot sequences, and so on. However, there are a few techniques you can use to allow Windows NT and OS/2 to interoperate on the same system.
CAUTION: Be forewarned that none of these methods are sanctioned by either Microsoft or IBM, and that anyone using them must take responsibility for the consequences! Make full backups of all critical data before proceeding, and if running Windows NT, create an Emergency Repair Disk that enables you to recover the most critical information.
See "Planning for Downtime," for instructions on creating an Emergency Repair Disk, p. 695
There are a few inherent difficulties in allowing OS/2 and NT to coexist on the same computer:
OS/2's High Performance File System (HPFS) was directly supported in earlier versions of Windows NT. If an HPFS volume existed on a system that also had NT 3.5x, NT would be able to read and write to that volume directly. However, the support was limited--for instance, there was no direct way to make use of HPFS's security systems.
Originally this was designed, among other things, to enable Windows NT more direct access to OS/2 1.x character-mode programs that it supported, and to make migration from OS/2 to NT on the same system easier. The first purpose has been rendered all but obsolete, and the second purpose has been mostly obviated by the addition of a utility that, during Windows NT setup, enables the user to automatically convert HPFS partitions to NTFS.
This set of instructions enables a Windows NT 4.0 machine to read from and write to an OS/2 HPFS-formatted partition. It enables basic file operations but does not enable control over security structures. Also, using a defragmentation utility on an HPFS partition accessed in this fashion is not recommended. In short, this technique is recommended as an interim solution only, not for long-term use.
TIP: It's strongly recommended that you back up your NT 4.0 configuration--use a newly-created Emergency Repair Disk and Registry backup--before doing this.
This technique requires that you have both the NT 3.5x and NT 4.0 CDs or a running copy of Windows NT 3.5 or 3.51. It also assumes that you have an HPFS partition on one of the drives in your local machine. Here are the steps:
2. Run REGEDIT.EXE. Look in the Registry for the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
3. Right-click the Services key and select New, Key. The name of the new key is Pinball.
4. Inside the Pinball key, add the following values exactly as shown:
| Value name | Data type | Data |
| ErrorControl | REG_DWORD | 0x1 |
| Group | REG_SZ | Boot file system |
| Start | REG_DWORD | 0x1 |
| Type | REG_DWORD | 0x2 |
5. Shut down and reboot. After rebooting, you should be able to read and write to HPFS partitions.
Boot Manager is an OS/2 program that resides in its own partition on a hard drive, enabling a user to set up multiple partitions from which to boot. Boot Manager can be installed during OS/2 setup or after OS/2 has already been installed. Boot Manager has several drawbacks, however:
2. When the list of available partitions appears, select the free space on the hard drive and press Enter. Select Install Boot Manager from the menu that appears.
3. FDISK prompts you to install Boot Manager at either the beginning or end of the available free space. Either is fine.
4. After the Boot Manager partition is created, select a partition to add to the Boot Manager menu, and press Enter. Select Add to Boot Manager Menu, press Enter, and then type a name used to refer to that partition in Boot Manager.
5. Shut down the system and reboot. Boot Manager appears when the system restarts.
6. To add partitions, boot OS/2 and run FDISK, and follow steps 4 and 5.
One advantage to this technique is that it also works when OS/2 and Windows NT are dual-booted by using the technique described as follows.
This set of instructions helps you get OS/2 and Windows NT to dual-boot cleanly on a machine that doesn't contain either OS. Original OS/2 and Windows NT system disks are required, as well as at least one Windows 95/DOS bootable disk with the system utilities FDISK, ATTRIB, and FORMAT.
This technique requires that OS/2 and Windows NT reside together on a FAT16 partition. Here are the steps:
2. Install Windows NT normally. When Windows NT is next rebooted, there will be a boot-menu option in the OS Loader that says Windows 95 or DOS.
3. Boot Windows 95 or DOS from the OS Loader menu. Use the DOS floppy to run the ATTRIB program on the hard disk's root directory, and enter the following:
attrib -r -h -s *.*
Then enter:
ren nt*.* xt*.*
4. Boot the OS/2 installation disks and install OS/2 normally.
5. To switch between OS/2 and Windows NT, launch the OS/2 command line and enter:
boot /dos
Do this once to confirm that Windows NT can boot correctly, and then select the Windows 95 or DOS option from the OS Loader menu, and enter the following at the command line (remember to substitute a different wild card for xt*.* if you used a different one previously):
ren xt*.* nt*.*
This restores your NT system files to a bootable state.
6. To switch between Windows NT and OS/2, select the Windows 95 or DOS option from the OS Loader menu, and then enter:
cd os2
boot /os2
Because of the increasing number of people who work with multiple operating systems on the same computer, a few software products have been developed to enable a system to multi-boot between OSs and to enable the safe installation and removal of OSs.
One such product is System Commander, from V Communications. Version 3.0 is compatible with the latest developments in the Windows 95/NT world, including the FAT32 file system. System Commander also password-protects partitions--something Boot Manager doesn't do--and can more flexibly control which partitions are rendered invisible at boot-time.
Although OS/2 continues to enjoy a relatively solid base of users and continuing support from IBM, there's no denying that it has drawbacks that Windows and especially Windows NT do not have.
Many third-party software publishers, with the exception of Lotus (now owned by IBM), do not provide OS/2 versions of many software programs. Many key markets, such as engineering, design, illustration, software development, and multimedia have a staggering array of software to choose from in the Windows domain, with Windows NT being better supported and represented with each passing month. OS/2 users don't completely lack a pool of software, but the pool they do have to draw from is small and slowly shrinking. A person who commits to OS/2 as their desktop platform of choice is facing a rather limited menu of application programs, with no signs of a deluge of new choices coming any time soon.
While OS/2 works with a fair amount of available hardware--display controllers, disk controllers, and multimedia devices--many new devices, especially multimedia hardware such as soundcards or scanners, are not supplied with OS/2 drivers. Their respective manufacturers mostly have no plans to support OS/2 in the future, either. The only good news is that most peripherals, such as printers or storage devices, are supported.
C2 security is a governmental standard for how an OS and its attendant workstations and servers can be secured against intrusion. (See Chapter 26, "Securing NT Server," for more details on C2 security.)
Without additional software, OS/2 is harder to make C2 compliant. Windows NT can be made C2 compliant with some work but does not require additional software, because many of the most important OS-level elements for C2 security are already in place.
Unicode is the two-byte standard for coding text for international use and has support for just about every language on the face of the Earth, with room for more. Windows NT was written to support Unicode in its kernel, making it possible to develop sophisticated translingual applications without too much difficulty. The fact that OS/2 doesn't have kernel-level Unicode makes it harder to "internationalize" OS/2 and its programs, to make them work in other countries, without significant amounts of work. However, Java is designed to use Unicode, which takes some (but not all) of the sting out of internationalization. NetREXX has also been rewritten to support Unicode as of its 0.82 update.
OS/2's methods for managing system components are primitive and have not been updated to reflect the increase in the sophistication of component technologies.
When OS/2 was introduced, it kept a number of conventions familiar to DOS users, to lessen the shock of transition. This included the practice of defining what device drivers would be loaded at boot-time in a file named CONFIG.SYS. DOS and Windows 95 users remain familiar with CONFIG.SYS, the correct operation of which depends on what order the driver statements are supplied in.
IBM designed OS/2 to work with OpenDoc object model specifications, a very open-ended and flexible object description criterion created by a consortium of companies including IBM and Apple. From its design parameters, OpenDoc is powerful and flexible enough to enable an object-model design such as DCOM/OLE/ActiveX to reside within it--to not only coexist with it, but enrich it and enhance it. OpenDoc implementations have also been developed for the Macintosh and even Windows; in fact, the Macintosh version of OpenDoc has gained a good deal of ground, and plans are well under way to make OpenDoc a fully active subset of the next iteration of the Macintosh OS.
Unfortunately, the number of commercial applications that actually make full and robust use of OpenDoc in OS/2 are vanishingly small. Windows uses Microsoft's DCOM/OLE/ActiveX specification, and the number of applications that don't support it on the Windows platform might in fact be smaller than the number that do. OpenDoc development has just not proceeded with the same pace and vigor that DCOM/OLE/ActiveX development has. The result is an object model that is more theory than practice, and that is well-intentioned in its design but has not been widely embraced by the software development community--even the developers for OS/2 itself.
© Copyright, Macmillan Computer Publishing. All rights reserved.