FAQ: Should I buy OS/2 Warp 3.0?
By Rod Smith - Published on The Warp Pharmacy.
Introduction
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 i
ncludes 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.
Video
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.]
CD-ROMs
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
- IBM ISA CD-ROM
- 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.]
Interrupts
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."
Summary
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.