This document is an attempt to consolidate information related to installing Warp 4 from a variety of sources, as well as offer additional hints and point out some specific problems you may encounter.

My purpose in creating this document was to get users operational under Warp 4 as soon, and as easily, as possible. Consequently, I'm not too concerned with making sure I have the description and location of the absolutely latest driver for an "IBM ZGA Display Adapter". I'm perfectly willing to leave that task to others (but see the section on Obtaining Device Drivers). However, I will provide information on driver-related problems that might prevent an installation or cause serious performance problems under Warp.

Where links to other sites and resources appear I have used the address (URL) itself as the link text rather than hiding it behind a shorthand text description. This was deliberately done to ensure that a hard copy of this document would be almost as useful as the live 'web version.

The material included has been compiled from verbal comments, private e-mail, messages posted in public locations (e.g. the Usenet newsgroups), the occasional manual, and my own interpretations of all of the above. I do not have access to all (or even most) of the equipment and software mentioned, so I am unable to personally verify all of this document's details.

I have tried to avoid the excessive use of jargon wherever possible. Unfortunately, describing an OS/2 installation is a technical topic, and requires the use of a certain number of technical terms.

I also have been known to make the occasional typographic errer (;-).

In all cases, you should use your own best judgement as to which of the following material applies to your situation.

Installation planning is a kind of insurance policy. It's the investment of a small amount of time and thought before starting with the aim of reducing your chances of spending much more time and effort later on - time that you could be spending exploring and using Warp 4.

Read First, Install Later:

The OS/2 Device Driver Pak CD, new with Warp 4, offers a handy reference for selecting a driver to use with a particular adapter. For example, if you have a Packard-Bell 144ASMP sound/modem adapter, you would discover that the DDPak CD recommends using the Sound Galaxy Wave 32+ driver supplied with Warp 4.

OS/2 Warp 4 shipped in September of 1996. Since then, new OS/2 device drivers have been written and old drivers have been updated. If you're looking for a driver or just want to see if a newer version is available, start by using a 'web browser to open the file \INDEX.HTM on the Warp 4 Device Driver CD. This set of browsable files contains pointers to files on the CD as well as links to IBM drivers or to manufacturer's 'web sites.

Many users install OS/2 without experiencing any problems. Still, it's always reassuring to know where you can turn if you do run into difficulties. In addition to the sources listed above, you may find help through any of the following:

When you are installing a new piece of software, especially one with as many components as Warp 4, it's easy to assume that any problem you see is due to the new software. I'm including the following items more as a reminder than anything else.

Workaround: Use the manufacturer's setup utility program to configure the display adapter so that the default mode is 640x480 at 60 Hz. If you are using a configurable display, make sure it can autoswitch to this mode.

Note: Some adapters will not completely reset for a "warm" boot (Ctl-Alt-Del), and a few apparently do not reset when the System Reset Button is pressed. If your reconfiguration does not appear to be taking effect, power off the machine, wait 60 seconds, then power it back on again to ensure a complete adapter reset.

When the WPS starts up, it will attempt to restart those processes which were active when it shut down (or crashed, or hung, etc.). If one of those processes was one which caused the initial problem, restarting it may cause the problem to recur.

To suppress this behavior, edit CONFIG.SYS and add the following line (note: "Folders" is plural):

Set RestartObjects=StartupFoldersOnly,ReBootOnly

Note: This will also prevent a DOS or MSWin31 app from running unnoticed in the background and keeping control of your sound adapter.

This can be due to several things, but most frequently occurs when OS/2 cannot locate a DLL required by the program. Attempting to start the program from an OS/2 command prompt will generally give an error message with the name of the missing DLL.

Likely causes: The directory containg the DLL has been erased, the directory name is not in the current LIBPATH setting, the directory name is misspelled, or LIBPATH does not have an entry for "current directory" as its first entry (LIBPATH=.;...).

Note: Always save a copy of your current OS/2 CONFIG.SYS and AUTOEXEC.BAT files before installing a new piece of software. If you experience problems following the installation, you can compare the resulting and previous versions of these files to see what changes have taken place.

By default, Warp 4 will check the hardware for COM1 at I/O address 0x3F8 and IRQ4 and for COM2 at 0x2F8 and IRQ3. If you have a COM3 or COM4 port or if the COM1 or COM2 settings at boot time do not match Warp's assumptions, you will need to modify CONFIG.SYS to override these assumptions.

Things to check for:

• IRQ conflicts. Under DOS, COM1 and COM3 could share IRQ4, since they could never be in use at the same time. Under OS/2 both ports could be active, so each COMx port must be assigned its own IRQ.
• Motherboard not recognizing COMx port(s) during POST (power-on self-test).
• Plug&Play BIOS selecting non-standard values for I/O address and/or IRQ.
  

Specifying the default COM1 and/or COM2 settings to the COM.SYS driver has made a difference in a few cases.

For more information on how to specify nonstandard values for COMx ports, read the COM.SYS driver section of the online Command Reference manual.

Warp installation checks for possible CD-ROM and LAN devices at various I/O addresses. Unfortunately, if a LAN adapter is present, this "adapter sniffing" may cause a hardware lockup. This is particularly true of NE2000-compatible Ethernet adapters located at I/O address 0x300, an address also used by ESS and SoundBlaster sound adapters and Philips, Mitsumi, and Sony CD-ROM adapters.

Workarounds:

• Prior to installation, configure the LAN adapter to use an address other than 0x300.
• Bypass hardware detection by adding the following line to the installation CONFIG.SYS:
  
  BASEDEV=RESERVE.SYS /P:300,20
  

Note: for Warp 4 these values are in hexadecimal.

For more details on Warp's autodetection, see the Warp 4 Command Reference section "Autodetection of Resources".

FDISK will not set a partition Installable if any portion of it lies beyond cylinder 1023 as reported by the BIOS.

The simplest way to see where the BIOS limit occurs is to type the following command at an OS/2 command prompt:

FDISK /QUERY

Where BIOS limits exist, FDISK /QUERY will list them under the affected drives as in the following examples:

Untranslated 700 MB IDE drive: **BIOS: 504MB
Untranslated 1.2 Gb SCSI drive: **BIOS:1024MB

Workarounds:

• Install to a partition or logical drive which lies completely below the 1024 cylinder BIOS limit. You may need to delete partitions and create new ones, or use a utility like PowerQuest's Partition Magic to shift partition boundaries to accomplish this.
  
  
• If no hardware or BIOS sector mapping (a.k.a.. Large Drive Support, CHS Translation, or LBA) is currently in use, it can be enabled through software (installing OnTrack Disk Manager, EZDrive, etc.) or hardware (enabling a BIOS feature, adding an EIDE adapter which supports CHS translation, or upgrading the System BIOS or motherboard).
  

Warning: Changes to a drive's sector translation (geometry) will render existing data on the drive unusable. For example, many Adaptec SCSI adapters have an option called "translate drives over 1 Gb". If this option is accidentally enabled, or a SCSI drive is switched to an adapter which has this option enabled, the drive's partition table may appear to be completely scrambled until the option is disabled.

If you change the geometry of an existing drive, make sure you have a verified backup of its contents prior to making the change.

Notes:

• FDISK may report problems with a drive if a virus is present.
• FDISK currently has a problem with drives which have more than 127 heads (tracks per cylinder), or which have been translated to appear to have more than 127 heads. This should primarily affect drives over 3-4 Gb.
• FDISK has been reported as requiring a re-boot after partitions have been deleted before newly-created partitions can be set Installable.

Related: IBM Service Tip OSINPART: Unable to set a partition Installable in FDISK during installation

Fix: Add the COPYFROMFLOPPY statement to the installation CONFIG.SYS file. For details on how to do this, see UAR p.74-75 and the README files on the DDPak CD.

Warp 4 boots cleanly to the point where PM starts up and a blue background is displayed. The system then waits indefinitely. The "clock" pointer remains visible, and responds to mouse movement. If MMPM/2 is installed, the System Startup sound may or may not be heard. This particular problem has been referred to as the Blue Screen of Death.

Note: a similar symptom will occur if you accidentally remove the FOLDERS keyword from the AUTOSTART setting in CONFIG.SYS.

While this problem does not occur on most Warp 4 systems, it is extremely noticeable when it does appear. Because of this, and because it is extremely frustrating to deal with, it is perhaps the most frequently reported problem with Warp 4. Based on the reports I've seen it looks like a case of improper serialization of some resource. An example would be (say) the WPS and WarpCenter (which runs as part of the WPS) each executing code between DosError() Disable/Enable calls with no interlock. Both would assume that their last setting would be the one in effect, and both might be correct.. most of the time.

Whatever the true cause, this problem appears to be highly timing-dependent. This means that apparently minor changes to seemingly unrelated areas of the system can trigger this problem... or cause it to vanish. Users have reported fixing or reducing occurrences of this problem through a variety of means, all of which alter the timing of portions of system startup rather than (IMHO) actually addressing the root cause.

Possible workarounds: If you should encounter this problem, try one or more of the following until a definitive fix (or workaround) is available:

• Use the System object to disable System Sounds and Window Animation.
• Press Alt-F2 at the OS/2 "boot blob" to display BASEDEV drivers as they are loaded.
• Press Ctl-Shift-F1 during bootup to suppress starting of objects in the Startup folder.
• Press Ctl-Esc when the system startup sound is heard.
• Remove the WARPCENTER keyword from the AUTOSTART setting in CONFIG.SYS and place a shadow of its icon on the Startup folder.
• Replace the Desktop bitmap with a plain colored background.
• Remove all icons from the Startup folder.
• Turn on Desktop archiving.
  

More serious efforts might include:

• Use an INI maintenance tool such as UniMaint to clean unused entries from your system INI files. This will reduce the time spent processing them at startup.
• Restore the Desktop from an archived copy.
• Remove noncritical entries from LIBPATH.
• Remove MMPM/2 support.
• Reinstall the display driver, or install an updated driver.
• Switch system video to VGA mode.
• Perform a nondestructive rebuild of the system INI files
• Reinstall Warp 4.
  

Note that none of the above are guaranteed to make the problem disappear permanently.

The good news is that this problem is reported as fixed in Warp 4 FixPack 1 (XR_M001).

Workaround: Use the Advanced install option and specify that even "newer" files should be overwritten. Alternatively, use SERVICE.EXE from a current set of CSF Boot Diskettes to back out changes so that your Warp 3 system is at a FixPack level prior to FixPack 22.

Related: IBM Service Tip OSINUP22: FixPack 22 and installation of OS/2 Warp 4.0

The new WarpSans font is contained in \OS2\DLL\DSPRES.DLL. If the installation of a display driver overwrites DSPRES.DLL, the WarpSans font will no longer be available.

Workaround: During display driver installation, make sure DSPRES.DLL does not get overwritten. In any case, you can restore DSPRES.DLL from the VGA bundle on your OS/2 boot partition using the following command:

UNPACK x:\OS2\INSTALL\VGA\VGA /N:DSPRES.DLL

Related: Section 6. of the Warp 4 DDPak CD README files.

Background: The Warp 4 installation code runs under CODEPAGE=850, then sets it back to the correct value for the OS/2 version being installed (CODEPAGE=437,850 for US systems). Installing under a different CODEPAGE, combined with the existence of files whose names contain certain odd characters (such as those created by Ultimail/2 v2.10.003 and later versions), triggers a bug in the OS/2 directory search support (DosFindNext) which causes it to repeatedly return the same file name. When MIGRATE.EXE scans a directory containing one of these file names, it goes into a CPU-intensive loop, effectively halting the installation process.

Workaround: Edit the CONFIG.SYS file on a copy of Warp 4 installation Diskette 1 using TEDIT or another ASCII text editor. Change the line reading CODEPAGE=850 to CODEPAGE=437,850 or another value suitable for your system, and restart your installation.

Note: A previous copy of Warp does not actually need to be present on the system for this problem to occur. All that is needed is a "strange" (but legal) filename on a drive which MIGRATE.EXE scans and a change of CODEPAGE which causes the file name to be processed differently. This problem can also be triggered by any other program (part of a CID install, for example) which scans directories and runs while CODEPAGE has been changed.

SYS0690: Lazy writes are disabled.
SYS0696: Read ahead is disabled.

Workaround: Reduce or eliminate the timing consideration. You can do this by

• Moving the /LAZY and /READAHEAD parameters from the RUN=x:\OS2\CACHE.EXE line to the IFS=HPFS.IFS line in CONFIG.SYS.
• Moving the RUN=x:\OS2\CACHE.EXE statement to the end of CONFIG.SYS.
• Removing the RUN=x:\OS2\CACHE.EXE statement from CONFIG.SYS entirely and putting it in x:\STARTUP.CMD.

In Warp 4 code was added to check for non-Plug&Play IDE adapters at the following I/O address and IRQ combinations:

• 0x1F0 and IRQ14 (primary IDE channel)
• 0x170 and IRQ15 (secondary IDE channel)
• 0x1E8 and IRQ11
• 0x1E8 and IRQ10
• 0x168 and IRQ11
• 0x168 and IRQ10

Workarounds:

• If the CD-ROM support is not set up for one of the above combinations, you will need to modify CONFIG.SYS on a copy of Warp 4 installation Diskette 1. Edit the IBM1S506 driver line to add the appropriate values, such as the following:
  
  BASEDEV=IBM1S506.ADD /V /A:1 /P:1E8 /IRQ:12
  
  
• If the CD-ROM drive is set up as master in the secondary IDE channel, you may need to explicitly enable ATAPI support:
  
  BASEDEV=IBM1S506.ADD /V /A:1 /U:0 /ATAPI
  
  Note that the parameter is /ATAPI, not /!ATAPI. The Warp 4 Command Reference has a minor typo here.
  
  
• Try disabling hardware detection by pressing Alt-F1 at the OS/2 "boot blob", then F6 at the RECOVERY CHOICES screen.
  

Due to changes made to the MVPRODD.SYS driver for VoiceType, the OS/2 mixers for the Media Vision ProAudio Studio 16 adapters will not work under Warp 4.

Workaround: If you are not currently using VoiceType, you can reinstall the Warp 3 version of the PAS 16 driver. The mixers will work with the older driver, but it will not support VoiceType.

Related: APAR JR09865

May exist with either the Warp 4 COM.SYS driver or the shareware SIO driver.

This is not a frequently-occurring problem. I have only seen two reports of it to date, and it may be hardware specific. My COM2 port has been running at 115 KB for three weeks with no problems.

Possible workaround: Drop the serial port speed back to 57KB or slower to see if this clears the problem..

Workaround: The correct geometry can be supplied to the driver through the /GEO parameter. For details, see the Warp 4 Command Reference entry for IBM1S506.ADD. A fix is in progress, but drives which have been created and written to with the wrong geometry may experience problems once the fix is applied.

If you wish to display the geometry currently seen by the driver, simply add a /V parameter to the IBM1S506 driver statement in CONFIG.SYS.

Related: OS/2 APARs JR09391, JR09401, PJ23302

The CONFIG.SYS keywords USER_INI and SYSTEM_INI allow relocation of the system INI files. Warp 4 installation does not check these settings, and if this feature is being used install will be unable to locate the current INI files. If out-of-date versions of these INI files exist in the \OS2 directory, installation will incorrectly assume that they are current.

Workaround: Move OS2.INI and OS2SYS.INI back into the \OS2 directory before beginning the Warp 4 install process.

Some versions of the ATI Mach64 chipset may not be properly detected during installation.

Workaround: Install Warp 4 in VGA mode, then use the ATI Mach 64 v2.x driver from the Warp 4 Device Driver CD. Also, an ATI v3.0 driver is available from the OS/2 DDPak Online site. Be sure to pay close attention to the README instructions.

The Create Utility Diskettes object in the System Setup folder fails to make the first diskette bootable if it is both formatted and blank.

Workaround: When creating Warp 4 Utility Diskettes, use unformatted diskettes or make sure there is at least one file on the first diskette.

Note: The Utility Diskette set for Warp 4 consists of four diskettes. This is an increase from the three diskettes created for Warp 3.

IBM APAR JR09427. Every time CHKDSK is run, the following error is reported:

CHKDSK found and corrected a minor file system error.

After upgrading an OS/2 Warp Connect system to OS/2 Warp 4, the following error occurs on startup:

SYS2070: A program in this session encountered a problem and cannot continue.
The system could not demand load the application's segment.
WPPRINT.DLL -> SOM.100

This error occurs if you choose to migrate the contents of your Warp 3 CONFIG.SYS. The most likely cause is the presence of multiple (and incompatible) versions of the SOM (System Object Model) DLL directories in the resulting Warp 4 LIBPATH.

Workaround: Save a copy of the Warp 3 CONFIG.SYS file before starting the installation. Reinstall OS/2 Warp 4, using Advanced Installation but do not migrate the Warp 3 CONFIG.SYS. After installation has completed, edit the resulting Warp 4 CONFIG.SYS file to add in the relevant portions of the Warp 3 CONFIG.SYS file.

Related: IBM Service Tip OSINSYS2: SYS2070 WPPRINT.DLL after upgrading from OS/2 Warp 3.

Workaround: Rename all existing TrueType fonts (*.TTF files) and reboot. If the problem disappears, rename them back in groups until the offending font(s) have been isolated.

Related: OS/2 APARs JR09349, JR09476.

How do I make changes to my Installation diskettes?

Make copies of the originals using DISKCOPY, or use CDINST to create new ones.

If you don't have a working OS/2 system at the time and you're installing to a FAT partition, boot from a DOS bootable diskette and use DOS commands to add or remove files, or use the DOS EDIT program to make changes to text files.

If you are installing to an HPFS partition, you'll need to boot from the install partition or use the installation diskettes as described below.

I'm stuck in the middle of installing and I can't find a DOS bootable diskette. How can I make changes to my installation diskettes?

If you're far enough into the installation process, you can boot to a full-screen OS/2 command prompt. Reboot the Warp 4 partition, and when the OS/2 "boot blob" appears in the upper left-hand corner, press Alt-F1. When the RECOVERY CHOICES screen appears, press F2.

If you need to edit a text file, you can use the TEDIT editor provided with Warp 4.

My Warp 4 install partition won't boot. Is there any other way to get a command prompt?

Boot from the OS/2 Warp 4 installation diskettes as if you were about to reinstall. When you get to the Welcome! screen (or the OS/2 Warp Setup and Installation screen if the Warp 4 CD is not in the drive), you will see the text F3=Command Prompt at the bottom of the screen. Press F3 and a full-screen command prompt will appear.

Once you have finished making your changes, if you type EXIT and press the Enter key, the Welcome or Setup screen will reappear.

I see the OS/2 logo screen, then my installation halts. This is not very informative. What can I do to learn more about the problem?

Reboot. When the OS/2 "boot blob" appears, press Alt-F2. When the OS/2 logo screen sppears, it will display the device driver (BASDEV) names as they are loaded and initialized. The name of the last driver loaded and started before the hang occurs should offere a clue to the cause of the hang.

I've used the Alt-F2 technique, and it looks like Warp 4 is hanging on a driver for hardware I don't have! What can I do?

When you re-boot, press Alt-F1 at the OS/2 "boot blob". When the RECOVERY CHOICES menu appears, press F6 to disable hardware detection.

I already tried that, and installation still hangs. What else can I try?

This kind of a hang can be the result of one device being misrecognized as another, or of a device responding to the installation "hardware snooping" by locking up the system. This will generally occur on Diskette 1. Selectively disabling this "snooping" for one or more specific adapters may get you past the problem.

First, make a copy of your Warp 4 Diskette 1. On the copy, edit the file SNOOP.LST to remove the entry corresponding to the driver or drivers you are having problems with. Then, on the same diskette, edit the CONFIG.SYS file and remove the entry for the driver file or files involved.

I have an ISA adapter that uses IRQ 11, DMA 3, and I/O ports 0x300-303 and 0x230-237. The driver for it was written for OS/2 v2.1, and is not Resource Manager-aware. What can I do to make sure any hardware conflicts are detected?

Since the Warp Resource Manager only knows what is reported to it by drivers, you need to add a driver statement which specifies your IRQ usage in a way that Resource Manager can see it.

BASEDEV=RESERVE.SYS /P:300,4 /P:230,8 /IRQ:11 /DMA:3

Note: for Warp 4 these values are in hexadecimal. For details, see the Warp 4 Command Reference entry for RESERVE.SYS.

How do I see what resources Resource Manager has already allocated?

Use the RMVIEW command. For details, see the Warp 4 Command Reference entry for RMVIEW or type

RMVIEW /?

I added /V parameters to some of the BASEDEV drivers, but the messages go by too fast for me to read them. How can I slow down the display?

Several 'web sites offer assistance and tips for installing Warp 4 on specific platforms.

I have had Warp 4 installed for five months now, and I am extremely pleased with it. I have experienced some of the problems I've described, but the vast majority of the problem descriptions and workarounds have been provided through the efforts of others via user postings in Usenet newsgroups, appends on TalkLink OS2BBS, and individual e-mail messages.

I would like to extend my thanks to all who have directly or indirectly contributed to this document through problem descriptions, corrections, and providing copies of this document for others.