FAQ: Should I buy OS/2 Warp 3.0?

From OS2World.com Wiki
Jump to: navigation, search

By Rod Smith - Published on The Warp Pharmacy.


This file is intended to serve as an answer to the above question, which is being posed with increasing regularity to various OS/2 newsgroups. I am posting this to comp.os.os2.advocacy, where it really belongs, and to comp.os.os2.misc, where people will read it who may give me feedback, and where potential OS/2 buyers are more likely to see it. This file is undergoing continual, but mostly minor, revisions. Please feel free to e-mail me with corrections or additional information. Sections which have changed since the previous version are marked with the new icon (like this text).

Unfortunately, the question of whether to buy OS/2 has no simple "yes" or "no" answer. The answer depends upon the user's hardware, software, and purpose for having a computer. This FAQ therefore goes over some of the issues involved in answering the question, in the hopes that the reader can construct the answer from the individual sub-answers.

The nature of this FAQ necessarily means that it overlaps somewhat with other, more-established OS/2 FAQs. The interested reader is encouraged to examine one or more of the following OS/2 FAQs:

  • WARPFAQ3.ZIP - Tim Sipples' main OS/2 FAQ. This has information on what OS/2 is, OS/2 resources and programs, etc. It's thin on OS/2 installation and debugging tips, though.
  • GBU104.ZIP - John Altstadt's Good, Bad, & Ugly hardware list for OS/2, which lists hardware that's known to work well or not-well under OS/2. Updates to this file are normally posted to the OS/2 newsgroups every Sunday, but haven't been recently, due to time constraints on the author.
  • PCIWARE.ZIP - Pat Duffy's PCI hardware information for OS/2, which gives information on PCI chipsets, motherboards, SCSI controllers, EIDE controllers, and video boards under OS/2. Updates to this file are normally posted to the OS/2 newsgroups every Sunday.
  • PFAQ32.ZIP - Andreas Almroth's Programmer's FAQ for OS/2, which answers questions about programming under OS/2.
  • OS2FNFAQ.ZIP - Cliff Cullum's OS/2 Font FAQ. Addresses questions about fonts and their use under OS/2.
  • TMFAQ21.ZIP - Christian Scarborough's Team OS/2 FAQ, which tells you what Team OS/2 is, and what it does.
  • OS2D-FGA.ZIP - The OS2DOS Frequently Given Answers. This is a summary of most of the frequently given answers from the FIDONET OS2DOS echo, covering all sorts of issues of running legacy DOS and Windows applications under OS/2, from "Can I use DOS programs on HPFS?" through to "What about VxDs?".
  • PROSCONS.ZIP - The Highly Unofficial FIDONET OS2DOS C++ Compilers Pros and Cons list. The developer switching to OS/2 will want this in order to compare and contrast the main C++ compilers for OS/2 (Borland, Watcom, IBM, Metaware, EMX) and get further information about toolkits, DirectToSOM C++, and Developer assistance programs.

Most of these are available on ftp-os2.nmsu.edu or ftp-os2.cdrom.com, under the os2/newsltr or os2/info directory. The contents of the PCIWARE.ZIP file can be found on ftp.netcom.com under the pub/ab/abe directory (grab everything with "pci" in the filename). OS2D-FGA.ZIP and PROSCONS.ZIP FAQs are available on FidoNet from DoNoR by File Requesting from 2:440/4.0. Some or all of these may also be available on rtfm.mit.edu (an ftp site devoted to FAQs of all sorts) under the pub/usenet/comp.os.os2.misc or pub/usenet/news.answers directories. Many of these FAQs, as well as the one you're reading now, are available on many web sites. These sites can be found in the index page.

Note that I use "Windows" to refer to Microsoft Windows 3.10, MS Windows 3.11, MS Windows for Workgroups 3.10, and MS Windows for Workgroups 3.11. OS/2 treats all four versions more-or-less identically - solely as a means of running Windows programs. The networking and disk access mechanisms of WfW aren't used by OS/2. OS/2 provides its own disk access, which is either better than or worse than that of WfW, depending upon who's doing the judging. OS/2 Warp 3.0 includes no built-in networking, though there are add-on networking packages for it.

OS/2's History and Purpose

OS/2 was originally developed jointly by IBM and Microsoft as a multitasking successor to DOS for 286 and better CPUs, but version 1.x never really caught on except in a few specialized applications. With version 2.0, Microsoft dropped out of the OS/2 partnership, and IBM promoted OS/2 to a 32-bit OS requiring a 386 or better CPU. This basic configuration has not changed with OS/2 2.1 or 3.0.

OS/2 Warp 3.0 is a multitasking, 32-bit, single-user OS for 386SX and better CPUs with 4MB or more of RAM. It is very DOS-like in some ways (such as the commands used in its command-line interface, and the presence of a CONFIG.SYS file), but resembles the Mac in other ways (e.g., the iconic representation of files from the WorkPlace Shell) and has some similarities to other OSes in still other ways (e.g., pop-up menus when clicking on the desktop itself, which are reminiscent of X Windows under Unix). Warp includes a Graphical User Interface (GUI) known as Presentation Manager (PM), and a desktop metaphor for launching programs and manipulating files called the WorkPlace Shell (WPS). The PM bears some resemblance to Windows, though it's not identical. The WPS will be largely new to most Windows users, though it bears some passing similarity to the Mac's Finder. A Windows version of the WPS is available as WPSHELL.ZIP on OS/2 ftp sites.

OS/2 lacks security and networking features which exist in Windows NT and most Unix implementations. There are separate networking packages available for OS/2, however, so OS/2 isn't totally out of the running for some networking applications. If security and networking are paramount considerations, however, other OSes may serve better. A future version of OS/2 will include integrated networking and security features. When used with Windows for Workgroups, the WfW networking features are disabled under OS/2, though they can still be used if WfW is run from native DOS.

Out of the box, Warp can run OS/2 text-mode, OS/2 GUI, and DOS programs. Windows is a DOS program which Warp can run, and so OS/2 can run Windows programs if the user already owns Windows. A newly-released version of Warp ("OS/2 3.0 with Win-OS/2" or the "fullpack" version) includes a recompiled version of Windows ("Win-OS/2") in the box, just as the original OS/2 2.1 did. This version of OS/2 may run Windows programs slightly more quickly than does the "for Windows" version, and is easier to install if the user doesn't want to keep a DOS partiton, but is otherwise identical to the "for Windows" version of OS/2 Warp 3.0.

Most new OS/2 users should get the original, "for Windows" version of Warp. (The "for Windows" specification is not officially used any more, but is what the equivalent version of OS/2 2.1 was called, and indicates it's the version of Warp that does NOT include Win-OS/2 in the box, but relies upon an existing Windows installation to provide Windows support.) The "for Windows" version is slightly less expensive and will use less disk space than the "fullpack" version. Somebody who's upgrading from OS/2 2.1 fullpack should buy the upgrade package of the Warp "fullpack," which includes a "sniffer" to detect the old 2.1 code, and won't install if it doesn't find this. Somebody who's building a new computer and who doesn't already have Windows or OS/2 2.x, but who wants to run Windows programs, should buy the non-upgrade "fullpack" version of OS/2, which is the most expensive version, but more convenient than buying the "for Windows" version and a separate copy of Windows.

OS/2's primary raison d'etre is multitasking. Windows 3.1 can multitask programs using a scheme known as "co-operative multitasking," which means that a program must willingly give up control of the computer before another program can run. This works well if all the programs are well-behaved, but this is frequently not the case. OS/2, by contrast, uses "pre-emptive multitasking," in which the OS can take away control from one program and give it to another. This results in better multitasking performance when one or more CPU-intensive tasks are running than does co-operative multitasking. For instance, it's possible under OS/2 to run a high-speed download while simultaneously unzipping files, performing a spreadsheet recalculation, playing a game, formatting a floppy, or whatnot.

OS/2 also offers a number of ancillary benefits, any one of which may be important to some people.

  • OS/2 can optionally use a new file system for hard disks, known as HPFS (High-Performance File System), which is typically more robust than the FAT (File Allocation Table) file system used by DOS. HPFS is also faster than FAT and offers users long filenames (from OS/2 programs only; DOS programs run with HPFS are still restricted to the 8.3 filename conventions). Note that HPFS is optional; the new OS/2 user need not reformat his or her hard drive just to use OS/2, though HPFS offers enough advantages that this is often desirable.
  • OS/2 can protect programs from one another's crashes better than can Windows, because OS/2 uses the 386 CPU's features to set up separate address spaces for each program. This system is imperfect, but it's better than having no protection at all, as under Windows 3.1. Note that multiple Windows programs ordinarily run in one address space, and thus do not gain this benefit; but if the user wants to devote extra memory to them, they can be run in separate address spaces.
  • OS/2 can set up each DOS program with its own AUTOEXEC.BAT file and customized configurations for memory, hardware access, drivers, and so on. Thus, OS/2 allows running finicky programs that, under DOS, might require changing CONFIG.SYS and/or AUTOEXEC.BAT files, without rebooting, and even side-by-side with other DOS programs using different settings.
  • Because of its 32-bit address space, OS/2 programmers needn't worry about the so-called "64K limit" imposed by DOS's history. Under DOS, a single data structure is limited to 64K by the 16-bit memory addresses used by DOS, unless a 32-bit DOS extender is used. This 64K limit can be a pain to programmers, though end users needn't ordinarily worry about it. In fact, "32-bit" has been over-hyped by the media. Although some programs may get a speed boost from being 32-bit, others may win a speed DECREMENT if re-coded as 32-bit. Thus, the 32-bit address space is mostly a concern for those doing programming using large data structures.
  • OS/2's memory architecture also obliterates the so-called "640K barrier" imposed by DOS. While DOS programs are still limited to less than 1MB of RAM directly (plus whatever EMS, XMS, or DPMI memory they need), OS/2 itself is not so limited. The main upshot of this is that an OS/2 user need not juggle device drivers endlessly to maximize the available main memory. For many devices (such as CD-ROMs), OS/2 gives DOS programs access to the device without explicitly loading a DOS device driver, assuming that an OS/2 device driver is used.
  • OS/2's WPS provides a unified method of access to programs and files, compared to Windows' dual approach of Program Manager and File Manager. Perhaps my Mac background is biasing me here, but I find WPS to be far superior to Windows in this respect.
  • OS/2 allows programs to be multi-threaded. This is closely related to multitasking, but isn't quite identical. In multitasking, two separate programs can execute simultaneously. In multithreading, one program can do more than one thing at a time. For instance, a program can "spawn" a process which prints a document. This process can execute, and the user gets control of the application back immediately. Heavily multi-threaded programs feel much "snappier" than their conventionally coded counterparts.
  • Virtual memory. Most OSes these days, including Windows, allow the use of hard disk space as a slow sort of RAM, thus allowing the user to run more or larger programs than he or she ordinarily could. OS/2's virtual memory (VM) capabilities are more flexible than those of Windows, and the user gains these benefits even when running DOS and Windows programs - OS/2 handles the VM tasks instead of Windows.

These, then, are OS/2's primary features. If these features sound appealing, then score a point for the "yes" vote to "should I buy OS/2?". Somebody who just uses a computer to run, say, a word processor, and absolutely nothing else, is less likely to be drawn to OS/2, though, since these features offer relatively few advantages to such a person. Somebody who wants pre-emptive multitasking, or who runs lots of DOS programs that require conflicting configurations, may find OS/2 tantalizing. That may not be reason enough to buy it, though.... This is the THEORY behind OS/2's design. The PRACTICE is often less rosy, since there can be device driver conflicts, incompatible hardware, and a considerable learning curve in setting up an OS/2 system optimally. For whatever reason, some people find OS/2's promises of crash protection, better multitasking performance, or whatnot to be only partially fulfilled. This is sometimes the result of flakey or incompatible hardware, sometimes the result of a non-optimal configuration, and sometimes the result of bugs within OS/2. Unfortunately, the only way to know how well OS/2 will work for you is to try it, though at least some hardware problems can be caught before picking up the box (see the hardware section). Configuration problems can often be worked out by getting help on the net. In this respect, somebody who's unwilling to take some time optimizing and possibly debugging a system should probably avoid OS/2 - though such a person should also avoid DOS and Windows if s/he is new to the PC world, since DOS/Windows configuration can be as difficult to a PC newbie. Such a person should view Unix as the bubonic plague.

Software Issues

OS/2 is designed to run OS/2, DOS, and Windows (if the user already owns Windows, or if OS/2 with Win-OS/2 is purchased) programs. For the most part, it does so quite well; however, OS/2 runs some programs better than others, and how well it runs these programs depends to some extent upon the user's hardware and to a large extent upon how well the system is configured. Obviously, how well OS/2 runs an OS/2 program depends upon how well-written the OS/2 program is. Unfortunately, many OS/2 programs are quick "ports" of a DOS, Windows, or sometimes a Unix program, and these ports sometimes don't run terribly well. One of the worst offenders in this category is the (now-defunct) WordPerfect 5.2 for OS/2, which was a buggy and slow port of WordPerfect 5.2 for Windows. On the bright side, an increasing number of companies and shareware authors are learning how to utilize OS/2's features to produce fast and flexible software. Some examples: DeScribe 5.0 is a reasonably well-designed OS/2 word processor, and the new ClearLook word processor makes even better use of OS/2's features. The shareware ZOC terminal program and KWQ Mail/2 offline mail reader both perform well and utilize many of OS/2's features to good effect. Many OS/2 GIF and JPEG viewers are faster than their DOS and Windows counterparts.

DOS applications generally run as well under OS/2 as they do under DOS, and with the added benefit that they can be configured individually and run simultaneously. DOS programs sometimes present difficulties, however, if they are very timing-sensitive (such as terminal programs doing file transfers or tape backup programs) or if they need to access the computer's hardware or disks directly (such as disk defraggers). Some games (and even applications) require a lot of tweaking of the "DOS settings" to run well, and a few don't run at all under OS/2. CPU- intensive DOS programs may take a slight performance hit due to OS/2 stealing CPU cycles from them to perform its own tasks, but this generally isn't very great. As a rule, DOS programs don't multitask as well as OS/2 programs, since DOS programs tend to "busy wait" -- they tie up the CPU simply waiting for a keypress or other system event. Disk-intensive DOS programs may experience a performance hit or a performance gain, depending upon the hard drive setups. HPFS's advantages may give a performance boost for DOS programs that use the disk heavily.

Windows programs generally present fewer multitasking problems than do DOS programs. Windows programs are also less likely to want access to low-level hardware that OS/2 wants for its own. Because Windows itself is fairly memory-intensive, however, many Windows programs put enough of a strain on a computer's RAM reserve that they run more slowly under OS/2 than under DOS/Windows. This is especially a problem for users with relatively little RAM (say, 8MB or less) and/or those who installed OS/2's multimedia support and IBM Works, both of which chew up RAM. In addition, the video drivers which OS/2 provides to allow Windows programs to run "seamlessly" (side-by-side with OS/2 programs) necessarily result in a worsening of video performance, since these drivers must interface with OS/2's drivers, and this overhead slows things down. Video performance can usually be improved considerably by running Windows programs "full-screen" -- they take over the video display. These adverse speed effects can be reduced by careful management of OS/2's CONFIG.SYS file and other settings, and many people find that they can run Windows programs as well under OS/2 as under DOS/Windows. Others, however, particularly those with less RAM, become frustrated by OS/2's performance with Windows programs.

Since OS/2 runs Windows in order to use Windows programs, most Windows features, including TrueType fonts, are available to Windows programs under OS/2. TrueType fonts are not available to native OS/2 programs, however. Instead, OS/2 uses ATM fonts (also known as Type 1 or PostScript Type 1 fonts) for OS/2 programs. OS/2 also includes a version of ATM for Windows, so the same PostScript fonts can be used for both OS/2 and Windows. There are a handful of commercial font conversion programs, such as FontMonger, but there are no freeware or shareware programs for converting TrueType to PostScript fonts. One good source of ATM fonts that can be used with OS/2 is the Bitstream 500 Font CD for Windows, which sells for $20-$40. Another good ATM font collection is the Expert Software 2000 Fantastic Fonts for Windows CD, which costs about $15. Avoid the SoftKey KeyFonts Plus and KeyFonts Pro collections; the former, despite the label, does NOT include PostScript fonts; and the latter lacks the .AFM files that OS/2 needs (though these can be regenerated with the PFM2AFM program). There are numerous freeware and shareware fonts in the multimedia directory on ftp-os2.nmsu.edu, as well.

For all three types of software (OS/2, DOS, and Windows), a complete list of software that runs well and software that doesn't is beyond the scope of this FAQ. If you're concerned about a specific program or set of programs, post your question. (Do not e-mail me about this, please; I use few DOS and Windows programs, and so probably don't know the answer to the specific query.) Note that "does it run DOS games?" is too vague; list the specific games that you want to run. (There is a comp.os.os2.games newsgroup for such questions, too.)

Running OS/2 does not preclude running native DOS (with or without Windows), Linux, Windows NT, or any other operating system. OS/2 can coexist on a single FAT boot partition with DOS using a method known as Dual Boot; or OS/2 can be installed on a separate partition and a program (included with OS/2) called Boot Manager can be used to select the boot partition. Dual Boot is easier to install but more limited in its capabilities, while Boot Manager is more difficult to install but more flexible in use.

Thus, the type of applications used by a person will influence the answer to the question, "should I buy OS/2?". Somebody who runs mostly Windows programs, and who has no intention of or desire to switch to OS/2 programs, should give points to a "no" answer. Ditto for somebody who runs exotic games and/or DOS programs that must access low-level hardware. If the person is willing to investigate native OS/2 software, however, or if the person runs multiple DOS or Windows programs requiring different DOS CONFIG.SYS or AUTOEXEC.BAT files, OS/2 is worth consideration. OS/2 is also worth a look for anybody wanting to run multiple DOS programs simultaneously. OS/2's Dual Boot and Boot Manager features mean that the user need not abandon an old OS completely in order to try OS/2.

Hardware Issues

The OS/2 Warp 3.0 box lists as hardware requirements:

  • Intel 386SX-compatible or higher based personal computer
  • 4MB of random access memory (RAM)
  • 35-55MB free hard disk space
  • 1.44MB 3.5" diskette drive
  • VGA video support
  • IBM-compatible mouse
  • An OS/2-compatible CD-ROM drive [note: on CD-ROM version; not required for floppy version]
  • Multimedia-ready systems for sound

As with most software, these requirements, and particularly the RAM requirement, are optimistic. While there are people who are happy running OS/2 Warp 3.0 in 4MB of RAM, these people are rare, and frequently don't run Windows programs. Multimedia support chews up RAM, and so is an iffy proposition, even in a system with 8MB. OS/2 is more RAM-intensive than CPU-intensive. If you're satisfied with the speed of a 386 computer, there's no need to upgrade the CPU for OS/2, though even a Pentium computer might benefit from more memory. OS/2 frequently benefits from extensive "tweaking" of settings in the CONFIG.SYS file, and not all of the tweaks are obvious. (For instance, many OS/2 newbies assume that increasing the size of the disk cache will improve performance, but this often has the opposite effect.) OS/2 requires not only a 3.5" floppy drive, but a 3.5" A: floppy (though there are workarounds for this which allow installation on a system with a 5.25" A: drive). 35MB is enough to install a fairly minimal OS/2, but if that's the entire free space on the hard drive, it won't be enough. OS/2 also uses a swap file, which can grow to substantial size; and once the user starts adding OS/2 programs, 100MB of free space becomes a more reasonable minimum for serious OS/2 use. Video, CD-ROM, and SCSI support are complex issues, and will be dealt with individually below.


The OS/2 Warp 3.0 manual lists the following as supported video chipsets:

Non-accelerated devices:

  • ATI 28800
  • Cirrus Logic CL-GD5422, CL-GD5424
  • Headland Technologies HT209
  • IBM VGA16, VGA256C
  • Trident TVGA8900B, TVGA8900C
  • Tseng ET4000
  • Western Digital WD90C11, WD90C30, WD90C31

Accelerated devices:

  • IBM 8513, XGA
  • S3 86C801, 86C805, 86C928, 86C864
  • Cirrus Logic 5426, 5428, 5430, 5434
  • Western Digital WD90C24, 90C24A, 90C24A2, 90C31, 90C33
  • ATI Mach 32, Mach 64
  • Tseng ET4000/W32, ET4000/W32i, ET4000/W32p
  • Weitek Power 9000

In general, a video board using any of these chips will work fine "out of the box;" however, there are exceptions. Video board manufacturers frequently tweak their boards in ways which produce better performance, but which also make their boards incompatible with "generic" drivers such as those in OS/2. [I do not currently have a list of "problem" boards -- if somebody has such a list, please e-mail it to me and I can include it here.] If you don't see the chipset used on your board, post or contact the manufacturer to ascertain the availability of OS/2 drivers for the board. Include as much information on the board as possible if you post; for instance, simply saying you have "a Cardex board" doesn't give enough information. Give the precise model number and, if you know it, the chipset used on the board. Many manufacturers have their own OS/2 drivers, even if their board is supported by OS/2 "out of the box." These drivers are sometimes superior to IBM's drivers, but other times are not. [Again, specific information about this might be helpful. Thanks.]


There are three basic classes of CD-ROM drives for PC-compatibles:

  • SCSI drives. These connect to a SCSI controller. OS/2 includes "generic" drivers for SCSI CD-ROMs which work with all SCSI-2 units, to the best of my knowledge, and with most or all SCSI-1 units. The only tricky thing with SCSI drives is to find a driver for the SCSI controller (see below, under hard drives). There may sometimes be quirky interactions between specific controllers and specific CD-ROM models, however; for instance, I've seen a fair number of posts about problems with Toshiba CD-ROM drives driven by Adaptec controllers.
  • IDE drives. These connect to an IDE or EIDE controller. These are the newest class of CD-ROM drive, and as such have the least mature drivers under OS/2. OS/2 Warp 3.0 does include drivers for this class of CD-ROMs, but how well they work seems rather variable. Most people report no problems, but some can't seem to get their drives working under OS/2. There are many variables here, including the brand of drive, the brand of IDE controller, how the hardware is configured, and possible conflicts with other hardware.
  • Proprietary drives. These connect to a sound card or a dedicated controller, and use a variety of different (non-)standards. Various manufacturers sell these drives, and many are re-badgings of other models. OS/2 Warp 3.0 includes support for the major proprietary models (see below). There are a few oddball brands that may not be supported (for instance, OS/2 doesn't support Dolphin drives out of the box, but I understand there are now beta test drivers for these), so check to be sure if you're not positive of what you've got.

CD-ROM drives supported by OS/2 Warp 3.0 "out of the box" include:

  • All SCSI-1 and SCSI-2 drives, assuming a SCSI driver exists for the SCSI controller card
  • Most IDE drives, including models from Mitsumi, NEC, Philips, Sony, and Wearnes
  • Creative Labs OmniCD
  • Mitsumi CRMC-LU002S, CRMC-LU005S, CRMC-FX001, CRMC-FX001D
  • Panasonic 521, 522, 523, 562, 563
  • Philips LMS CM-205, CM-225, CM-205MS, 206, 225MS, 226
  • Sony CDU-31A,33A,7305,7405, CDU-531,535,6150,6201,6205,6251,7201,7205
  • Tandy CDR-1000

Note that for all CD-ROMs, there are potential "gotchas" during installation which are documented in the OS/2 manual. The plethora of conflicting "standards" and hardware means that extra parameters may be required on the driver line in CONFIG.SYS for some CD-ROMs to be used. Before posting with a CD-ROM problem, please check the CD-ROM troubleshooting section of the OS/2 manual. In a worst-case scenario, you can create a set of installation floppies from a CD-ROM version of OS/2 and install from that. DOS CD-ROM drivers can sometimes be made to work for DOS programs using a special DOS boot procedure. (Ordinarily, OS/2 provides DOS programs with access to the CD-ROM drive using its own drivers.)

Hard drives

OS/2 supports the vast majority of hard drives out of the box. EIDE, IDE, ESDI, MFM, and RLL drives all use the same driver -- IBM1S506.ADD. An increasing number of EIDE controllers have drivers optimized to the particular controller from their manufacturer; however, posts indicate that some of these introduce minor or major reliability problems, so they should be used with caution. SCSI drives use either the IBMINT13.I13 generic driver or a driver specific to the SCSI controller in use. SCSI drivers are included for many SCSI controllers:

  • Adaptec 1510, 1520, 1522, 1540, 1542, 1640, 1740, 1742, 1744, 2840VL, 2842VL, 2740, 2742, AIC7770, 2940, 2940W, AIC7870
  • BusLogic BusMaster SCSI Adapters
  • DPT PM2011, PM2012
  • Future Domain 845, 850, 850IBM, 860, 875, 885, TMC 9C50/C950, 16xx, 1790, 1795, MCS600/700, TMC 1800/18C30/18C50/3260/36C70, 7000EX
  • IBM PS/2 SCSI Adapter
  • IBM 16-Bit AT Fast SCSI Adapter
  • ProAudio Spectrum 16 with Trantor SCSI
  • SoundBlaster 16 with SCSI (uses Adaptec 1520 driver)

Drivers for QLogic, UltraStor, NCR 53c8xx-based boards, and probably others, are available from the manufacturer. If you have one of the latter boards and wish to install from a SCSI-based CD-ROM, you will need to acquire the appropriate SCSI driver and add it to the OS/2 Diskette 1, or else OS/2 will be unable to recognize your CD-ROM drive. Instructions should be included with the OS/2 driver. Note that OS/2 2.x SCSI drivers usually work under OS/2 3.0, so if you can only find a 2.x driver, try it. OS/2 support for parallel-to-SCSI adapters is limited at best. Unfortunately, I don't have more specific information on this, though.

The PC BIOS imposes a limit of 1024 cylinders (0-1023) upon hard disks. This limit, in conjunction with limits upon the number of heads and sectors, limits the size of IDE (and ESDI, etc.) hard drives to a bit over 500MB, and the size of SCSI hard drives to about 1GB. (Some SCSI controllers have an option to get around this.) If you have a hard drive larger than this value, it may have come with a DOS driver to allow access to the entire hard drive. If you've used that package, OS/2 may not be able to read the drive's partition table, and thus OS/2 will not install. OS/2 has a different way around this 1024-cylinder limit. The best way to utilize both OS/2 and DOS on a system with such a hard drive is to partition the drive with OS/2's FDISK such that OS/2's Boot Manager, all DOS partitions, and the OS/2 boot partition all fall under the 1024-cylinder limit. One or more OS/2 data partitions (using the HPFS file system) can be placed above the 1024-cylinder limit. DOS can then be booted WITHOUT the extender (running "FDISK /MBR" from DOS may be needed to remove it), but will be limited to use the space within the 1024-cylinder limit. OS/2 will be able to see the entire hard disk, however. DOS and Windows programs run from OS/2 will have access to the entire hard disk. Note that it may be necessary to enter a value in the PC's BIOS of less than 1024 cylinders for the drive size, and then either rely upon OS/2's independently discovering the drive's true size (which it can usually do) or passing the drive's true size to OS/2 via a the /GEO:(cyl,head,sector) parameter to the IBM1S506.ADD driver.

Alternatively, the file [ontrac.zip] on [ftp.informatik.tu-muenchen.de] in the directory /pub/com/os/os2/drivers/disk+scsi may allow DOS and OS/2 both to use the entire hard drive, at least if OnTrack software is used under DOS.

EIDE drives may include a way around the 1024-cylinder limit which involves patching the PC's BIOS. I've heard conflicting things about whether this scheme works well under OS/2. If it does work, it requires not only an EIDE hard drive, but also an EIDE controller card. If you have problems with this, try the solution suggested above for large IDE hard drives.

Sound Cards

OS/2 Warp 3.0 supports most of the common sound cards, including Creative Labs' SoundBlaster series and the Pro Audio series of boards. One notable exception is the Gravis UltraSound. Gravis has been promising OS/2 drivers "Real Soon Now" for well over a year, and finally has early (but reportedly buggy) drivers available. A shareware GUS driver is also available. GUS users should look for the [ULTRA06C.ZIP] (or newer) drivers in the os2/32bit/drivers directory on [ftp-os2.nmsu.edu] or [ftp-os2.cdrom.com]. Another exception to OS/2 sound board support is the Microsoft sound card, though rumor has it that IBM is working on a driver for this one. Many SoundBlaster clone boards don't work with the included SoundBlaster drivers, unfortunately. As mentioned above, multimedia support chews up a substantial amount of RAM under OS/2, and this degrades performance on low-memory systems. Therefore, those with 8MB or less RAM would be well-advised to install without multimedia support. It can be added later, if desired, and also uninstalled, if desired.

Tape drives

OS/2 does not provide direct support for any form of tape drive. There are, however, several packages which allow the use of tape drives under OS/2. These drives fall into four broad categories:

  • Floppy tape units. These connect to the system's floppy controller and generally use the QIC-80 standard. They are inexpensive and are increasingly popular. Unfortunately, they're also VERY timing- sensitive, as the CPU must monitor everything that goes over the floppy controller. This is tricky to handle under a multitasking OS, and so the DOS or Windows software which drives these units is generally unreliable under OS/2. Several OS/2 programs, including FastBack, BackMaster, Sytos, and one or two others, are available. Specific drive models tend to be slightly idiosyncratic, and these idiosyncracies interact with the motherboard, floppy controller, and software. It's therefore impossible to give a list of which drives work well and which ones don't.
  • Proprietary tape units. In some cases, these are floppy-based drives which use high-speed interfaces. These frequently work with the same software as the floppy units, but check with the software producer to be sure. In other cases, a true proprietary interface and drive are used. To the best of my knowledge, no OS/2 software yet supports such drives.
  • SCSI tape units. As with CD-ROM drives, these require the use of a driver for the particular SCSI controller involved. (See under hard drives, above.) They also require a tape backup software package. One, GTAK 2.43, is a freeware port of the Unix tar program. This uses an arcane command-line interface, but it gets the job done and is free. BackupWiz, FastBack, BackAgain/2, and Sytos are four commercial packages that come to mind. Note that, in theory, the specific brand of SCSI tape drive shouldn't matter, though there may be idiosyncratic problems with specific drives.
  • Parallel-port drives. These are usually QIC-80 devices similar to the floppy-port drives, but they connect to the computer's parallel (printer) port. There is support for these devices under OS/2, but it's relatively rare. BackMaster supports at least some of these, but I'm not sure precisely what packages support precisely what drives. Sometimes a SCSI tape unit can be hooked up via a parallel-to-SCSI adapter. These will depend upon OS/2 driver support for the parallel-to-SCSI adapter, and such support is still weak under OS/2.

PCMCIA Support

OS/2 3.0 includes support for PCMCIA devices. Unfortunately, I know next to nothing about this topic, and so can say no more about it at this time. [If somebody would care to send me some summary information, I can include it here in the future.]


Under DOS, the "sharing" of interrupts is frequently allowed. This is permitted, in part, because two separate programs are unlikely to try to access two separate devices using the same IRQ at the same time. Such occurrences aren't at all impossible or even uncommon under OS/2, however, and so the sharing of interrupts is much more likely to cause problems under OS/2. One common source of shared interrupts is an internal modem. The default setting for COM3 uses the same interrupt as COM1. The best solution is to reconfigure the modem to use an unused interrupt, or to disable an unused COM port and reconfigure the modem to take on that port's identity (COM number and IRQ). The shareware SIO serial drivers for OS/2 also permit serial port interrupt sharing, and so may be a worthwhile investment for those with crowded IRQ lists. Note that there's no way to determine which interrupts are being used by which components under the standard ISA architecture (and its derivatives), short of physically examining the boards and comparing jumper settings to manuals' listings. DOS's MSD program, which is useful for some things, will give totally inaccurate information on IRQ use, unless your system is relatively "plain vanilla" and therefore conforms to MSD's expectations.

General Hardware Comments

Cruddy hardware abounds, unfortunately. OS/2 pushes the PC's hardware more than does DOS, and so will sometimes crash on sub-standard motherboards or RAM chips on which DOS gets by. The cry "it works under DOS" is often heard, but means very little. "It works under Unix" will get more attention, however, since most Unixes push hardware in a way similar to what OS/2 does. Of course, this is not to say that an OS/2 crash must be a hardware issue; like all modern software, OS/2 is not bug-free. Nor should the potential buyer necessarily be scared off if s/he purchased a bargain-basement computer; many of these run OS/2 just fine. This is something to keep in mind, however. It may be beneficial for the potential purchaser to observe OS/2 running on a system similar to his or her own, particularly in the amount of memory that system has, to determine whether performance is acceptable. OTOH, OS/2 can benefit greatly from performance "tweaks," so observing a poorly-configured OS/2 system may leave the wrong impression.

In general, the hardware issues with OS/2 are very complex. An informed purchaser will research the major components of his or her system before purchasing OS/2, to be sure that OS/2 supports those components. Usually it does, but many people do find one or two components which give problems under OS/2, and this sometimes leads to frustration. If this happens, try posting a calm and rational request for help - posts with titles such as "Warp Sucks Moldy Lemons" gather more flames than helpful responses.

As to the initial question, the answer must depend upon all of the above hardware issues. Simply put, unsupported hardware adds to the "no" response, while supported hardware adds to the "yes" response. RAM below 8MB pushes towards "no," while RAM of 8MB or more pushes towards "yes." Available hard disk space below 100MB pushes towards "no," while more available disk space supports "yes."


Deciding whether to buy OS/2 is a complex decision to make. A potential OS/2 user should have a clear understanding of why s/he wishes to use OS/2, know what software would be run under OS/2, and have a good idea of whether his or her hardware is capable of running it. Failure of analysis in any of these three areas is likely to lead to frustration, wasted time, wasted money, and possibly wasted net bandwidth on flame bait and/or flames. In other words, look before you leap. (Any OS/2 newbie who's read this far is presumably attempting to do so -- good for you!)

The bottom line in deciding on an OS must be to select one which will allow the user to get his or her work (or play) done. OS/2 will fit the bill for some users, but not for all. It's my hope that the above tome will help some people to ascertain which category they fall into.

Please feel free to comment on this document. I'll incorporate what changes I can and re-post it in a week or two.

Many thanks to Jack Tan, who provided the list of supported CD-ROM drives and SCSI controllers, both of which I edited for brevity. Thanks also to JdeBP@donor2.demon.co.uk for providing the names of some FidoNet-accessible FAQs.