Creating a Bootable CD-ROM for OS/2

By Allen Dermody This package is the result of what started as a simple search to find a way to create an emergency bootable CD for OS/2, and ended up taking a tremendous amount of time before I was able to contact some key people and obtain help in accomplishing my goal. The following discussion outlines the procedures to follow and the files required to create a CD that can be booted to IBM's OS/2 Warp operating system.
 * Date: 11/29/1998
 * File: cdboot.zip

The ability to create a bootable CD-ROM was established in a specification developed by:



and known as the "El Torito" Specification. For the first time, there was a uniform way to create a bootable CD. However, this format was best suited to real mode MS-DOS, because it was based upon the use of built-in access in the BIOS of a motherboard, or on a hard drive controller. The BIOS's of these devices operate solely in real mode.

The specification outlined by Phoenix Technologies and IBM allows the creation of a single entry boot image, or multiple boot images, with the option of which image to utilize made available to the user. This discussion will only deal with user available options.

BOOTABLE OS/2 CD-ROM
When creating a bootable CD for OS/2 Warp 3 Server, IBM was faced with the protected mode boot process of OS/2. In that process, the operating system first loads the kernel using standard BIOS calls, then loads the protected mode floppy driver, the protected mode hard drive controller driver, and all the other specific device drivers. Finally OS2DASD.DMD is loaded, which then takes control of the drives through the protected mode drivers. The process is roughly as follows: BIOS -> reads Master Boot Record (MBR) of each HD + Boot Volume Descriptor (BVD) of CD ->

if BVD exists, boot from CD by loading BVD and obtain address of bootable image -> else boot from HD ->

load MBR of bootable image -> MBR bootstrap program loads OS2BOOT -> loads OS2LDR ->

loads OS2KRNL -> reads config.sys -> loads all BASEDEV= drivers for floppy, HD/CD devices (ibm1flpy; ibm1s506, ibmidecd.flt for IDE devices; aic7870.add for SCSI devices) ->

loads OS2DASD -> OS2DASD stops using BIOS to load files, and starts using protected mode floppy and HD drivers->

loads country.sys and *.DCP files ->

In the order they appear, loads DEVICE= drivers (OS2CDROM.DMD) and Installable File Systems (IFS) (HPFS, CDFS) ->

load rest of necessary files. Here is where the problem starts: because the installable CD file system has not yet been loaded, the DASD manager cannot recognize the CD. The El Torito Specification is specifically set up to fool the system to "think" that it is booting from a floppy, but DASD doesn't check for this, instead, DASD goes directly to the protected mode floppy driver and requests the continued load of the system, normally starting with country.sys and the *.DCP files. The installable CD file system is not loaded until after DASD takes control, so there is no way the system can know how to read from the CD, or even that is should read from the CD. Imagine the system's surprise when the floppy driver says there is no diskette in the drive, and the system doesn't have anywhere to obtain the rest of the files to be loaded. Sudden death, and the system stops.

To solve this, IBM could have modified either OS2DASD.DMD, or the floppy driver, to use the BIOS interrupts for just a little longer. There is a documented interrupt 13 function that would tell the system that it is running from a CD, and that would allow the system to use the BIOS a little longer. Instead, IBM developed a filter driver, loaded before OS2DASD.DMD, that checks the CD-ROM drive detected by the protected mode drivers to see if there is a telltale "El Torito Specification" (BVD) signature, and if there is, emulates the BIOS load from the CD long enough for the system to initialize the CD driver and file system, and thus be able to complete the loading from the CD. This may seem like overkill, but the record of manufacturers and BIOS developers is probably uneven enough that IBM simply could not be certain that all of the El Torito Specification modifications had been properly made to the motherboard or drive controller BIOS's. In that way, IBM could have a system that depended on the BIOS only enough to get the boot started, and if it wasn't capable of telling OS/2 that a CD was the boot device, it didn't matter. The process becomes: BIOS -> reads Master Boot Record (MBR) of each HD + Boot Volume Descriptor (BVD) of CD ->

if BVD exists, boot from CD, else boot from HD -> load BVD and find address of bootable image ->

load MBR of bootable image -> MBR bootstrap program loads OS2BOOT -> loads OS2LDR ->

loads OS2KRNL -> reads config.sys -> loads all BASEDEV= drivers for floppy, HD/CD devices (ibm1flpy; ibm1s506, ibmidecd.flt, for IDE devices; aic7870 for SCSI devices) -> [loads cd_boot.flt for CD boot with other BASEDEV= drivers] ->

loads OS2DASD -> OS2DASD stops using BIOS to load files, [and allows cd_boot.flt to continue the load of the floppy boot image from the CD until the following two steps are completed,]  -> cd_boot.flt loads: country.sys and *.DCP files ->

In the order they appear, loads DEVICE= drivers (OS2CDROM.DMD) and Installable File Systems (IFS) (CDFS, HPFS) ->

OS2DASD then starts using protected mode floppy and HD drivers, -> load rest of necessary files.

The [ ] bracketed clause describes what has been added to allow booting from the CD.

There are some apparent side effects of this decision. The developer of the CD boot filter was never able to get a system operational with a multiple boot image CD, or at least he only got it to work with the default boot image. Additionally, it never worked with multiple session CD's, those that were basically written using the XA specification, allowing more than one data session to be burned. CD sectors are numbered on a absolute basis, starting with sector 0, the first one, and incrementing by one for each sector. When a multiple sessions are written, there are some unused areas of the CD between sessions that are unreadable, and there is also some space used for the next session Table of Contents (a misnomer, because it only tells the CD where the next session starts, and what the first useable sector number is.) Thus, the last session does not restart numbering sectors at 0, it simply starts after the last session and the large sector gap after the last session. On the Unite CD Maker software package, this unused space is equal to 11,400 CD sectors between the first and second sessions (23.3 Megs, since a CD sector is 2048 bytes) and 6,900 sectors between each additional session (14.1 Megs). Each software package probably creates a slightly different size gap, so there is not a way for OS/2 to do any absolute sector reads without a lot of code to accommodate these requirements.

The El Torito Specification states that the sector used for setting up a CD boot must be on the LAST track of the CD, but at the time the CD filter software was written, it was apparently only designed to enable IBM to create a bootable CD for Warp Server. Since this was a production system, there was probably no need to spend the time to enable the driver to account for multiple sessions.

Keeping these limitations in mind, it is possible to create a bootable OS/2 CD, if the right drivers can be obtained. The CD boot driver is used by IBM and Compaq to boot new servers when first installed, after choose which operating system is to be installed. The driver has not been released, but Sam Detweiler, Senior Technical Staff Member involved in the hard disk drivers, indicated he is trying to get the driver released, or even incorporated in some way into Adaptec's Easy CD Deluxe CD mastering software. To date, with little success.

I was able to obtain a copy of Warp Server, which has a bootable OS/2 system on it. The bootable image is Warp 3, but the necessary files will work just as well in Warp 4. Amazingly, once the proper steps have been taken to create the bootable image and the total CD image, the only things that need to be changed are the config.sys file on the bootable floppy image, the addition of one of two specific versions of IBM's IDE CD filter driver and, finally, the CD boot filter driver, all in the proper locations in the boot sequence. With the proper files available, let's see what it takes to create a bootable OS/2 CD, trying, if possible, to use nothing but OS/2 programs. First, however, I'll describe the configuration that must take place prior to actually burning the CD.

STEPS FOR CREATING BOOTABLE OS/2 CD'S
A. Create a 2.88 Meg floppy with the necessary files to boot to OS/2. This floppy will have the files that tell your system whether you want to boot to a command line session, a PM session, or a WPS session. It will determine your video resolution, the locations of your Desktop, if one is enabled, your Swapfile, and your system and user ini files. As in any normal bootable floppy, it will also have the basic OS2KRNL and all of the required floppy, hard drive and CDROM drivers.

B. Make an image of the floppy for use on the CD. (If multiple boot option desired, create A and B for each separate image)

C. Create a "boot catalog" for the CD. *

D. Create an ISO image of the CD; the boot floppy image and the boot catalog will be files that you include as part of this image.

E. Modify, if necessary, the ISO image to have the BVD and boot catalog properly point to the correct files. *

F. Burn the modified ISO image onto the CD.

( * ) optional step, depending upon software utilized.

A. Creating the Floppy Image (Required)
The El Torito Specification allows the CD to boot from one of the following types of images:


 * Floppy
 * 1.2 Meg
 * 1.44 Meg
 * 2.88 Meg


 * Hard Drive: any size less than the CD capacity


 * No Emulation: direct load of bootstrap code. Microsoft's NT loads this way: NTLDR is loaded into memory and determines if it was loaded from a CD or from a hard drive (apparently), and controls the boot process from there. This is not implemented in OS/2 by IBM.

For OS/2, only the 2.88 Meg floppy image and the hard drive images work with the drivers available. As noted above, the key to an OS/2 CD boot is the cd_boot.flt driver, which continues the load from the CD until the CD file system stack is initialized and os2cdrom can load the image using the protected mode drivers. This filter driver only works with a 2.88 Meg floppy image, it was not designed to utilize 1.2 or 1.44 Meg floppy images for booting. At this point, you are probably wondering how to boot from a hard drive, because cd_boot.flt only handles 2.88 Meg floppies. You simply remove all device specific drivers for hard drives (any *.add file), and insure that ibmint13.i13 is loaded instead. (This driver can only control a device through a controller that has a BIOS, either on the motherboard or on the controller itself.) Ibmint13.i13 runs in a small VDM session that uses the BIOS to control the drive controller(s) that are unclaimed by any prior drivers. With this in control, the boot process is supposed to proceed. (I haven't tested it, but that was what I was told by the author of cd_boot.flt.) The hard drive image becomes drive C:, and all your normal hard drives are moved back one drive letter. I.e., normal C: becomes D:, D: becomes E:, etc..

The easiest way to get a bootable OS/2 floppy image is to use BootOS2, IBM employee written software designed to create bootable floppies or bootable hard drive images. This will create a command line based floppy for booting your specific system, but the actual differences between that and either a PM or WPS session are minimal for our purposes. Once you have a bootable floppy created, you are ready to modify it with the proper config.sys, and add the cd_boot.flt to it. If you don't have a 2.88 Meg floppy, you are not totally out of luck. You should search the Hobbes repository for the file svd117.zip. This is the Super Virtual Disk driver for OS/2. With it, you can create any size drive in memory, but for this we are talking about a 2.88 Meg floppy. With this running, you should be able to create your bootable floppy, modify it, and then create the floppy image. The instructions for this program are in that zip file, but basically, you set up a virtual disk in memory, and tell bootos2 to use that "virtual disk" for your floppy disk, and it should then create the bootable floppy image you want, which you can then transfer to the boot floppy image, as discussed in B. below.

Config.sys and the Required Files
I have included a copy of the original config.sys file from the Warp 3 Server bootable CD, as config.w3. Peruse it at your leisure. In addition, there is a copy of my config.sys file, config.w4, and it is reproduced below, with comments to show the essential elements of the file.

Warp 4 Config.sys for a Bootable CD
BUFFERS=99                     [I am simply copying the Warp 3 Server CD on these commands] IOPL=YES DISKCACHE=D2,LW PROTECTONLY=NO PAUSEONERROR=NO                [If I screwed up, don't bother to wait for me to tell you to keep going.] RESERVEDRIVELETTER=W: [This command tells the system to assume all drive letters up to and including W are taken. This has the effect of moving the first CD drive to drive number X: NOTE, this command was added to Warp 3 via some fixpak, but appears to have been in Warp 4 from the beginning.]

LIBPATH=.;\;Y:\OS2;Y:\OS2\dll;Y:\OS2\mdos;X:\W4OS2\DLL;X:\W4OS2\MDOS;A:\; SET PATH=Y:\os2;Y:\os2\mdos;X:\W4OS2;X:\W4OS2\MDOS; SET DPATH=Y:\os2;Y:\os2\mdos;X:\W4OS2;X:\W4OS2\MDOS; [X: is the bootable CD, Y is the virtual disk that I set up later. For two CD's, you would change Y: to Z:.]

[Standard set up to create a swap file on the virtual disk, and use the standard keyboard drivers, with the default codepage, and video set up for VGA.] MEMMAN=SWAP,PROTECT                               [Why allow swapping on a virtual disk? See comments below.] SWAPPATH=Y:\ 512 COUNTRY=001,\COUNTRY.SYS CODEPAGE=437,850 DEVINFO=KBD,US,A:\KEYBOARD.DCP                    [Load these from the floppy.] DEVINFO=SCR,BGA,A:\VIOTBL.DCP SET VIDEO_DEVICES=VIO_VGA SET VIO_VGA=DEVICE(BVHVGA)

[Standard Warp 4 drivers.] BASEDEV=PRINT01.SYS /IRQ BASEDEV=IBMKBD.SYS BASEDEV=IBM1FLPY.ADD /FORCE:1 /U:0 /F:2880        [See discussion below for rationale for these command line options.] BASEDEV=IBM1S506.ADD                              [standard IDE driver - add any command line options you use] BASEDEV=AIC7870.ADD                               [Adaptec 2940 PCI SCSI driver] BASEDEV=IBMINT13.I13                              [failsafe BIOS driver] BASEDEV=OS2DASD.DMD                               [Controls all spinning magnetic media - floppies and hard drives] BASEDEV=OS2SCSI.DMD                               [for SCSI systems] BASEDEV=OS2ASPI.DMD /SHARE                        [You don't need this, I use it for other programs I load on my CD.] BASEDEV=XDFLOPPY.FLT                              [Well, you might need to access these floppies, if not, delete this.] BASEDEV=IBMIDECD.FLT                              [Critical File - See discussion below for the correct file to use.] BASEDEV=CD_BOOT.FLT /D:2                          [THE Critical File - See discussion of command line options.] [Extra drivers for those specific hard drive controller adapters that are capable of booting from a CD. Delete the ones you don't need. There may be others, these are the only ones I am aware of.] basedev=aha154x.add                               [Only later 1542C versions will boot CD's.] basedev=asc.add                                   [Advansys] basedev=flashpt.add                               [Buslogic] basedev=ini910u.add                                                                                  [Initio board - SIDE?] basedev=ql510.add                                                                                     [QLogic] basedev=sym8xx.add                                                                                [Symbios Logic 53C8xx boards] basedev=tmscsim.add                                                                                 [Tekram SCSI] basedev=tmscsiw.add                                                                                 [Tekram UW SCSI]

[Standard IBM filters for SCSI CD's that only use SCSI I commands. Delete the ones you don't need.] basedev=chincds1.flt basedev=hitcds1.flt basedev=neccds1.flt basedev=sonycds1.flt basedev=toshcds1.flt

[CD ROM control and file system. Please note, I use the very latest CDFS that is supposed to be Joliet file system capable.] DEVICE=\OS2CDROM.DMD /Q                                                        [/Q - Don't bother me with feedback on my screen.] IFS=\CDFS.IFS /Q /W                                                                            [/W enables Joliet file system]

[At this point, we are now loading files from the CD using native mode drivers, and we don't need CD_BOOT.FLT anymore!] DEVICE=X:\W4OS2\DOS.SYS DEVICE=X:\W4OS2\MOUSE.SYS DEVICE=X:\W4OS2\POINTDD.SYS DEVICE=X:\W4OS2\PMDD.SYS IFS=X:\W4OS2\HPFS.IFS /CACHE:64 /CRECL:4 /AUTOCHECK:C    [Note: you can load this from the CD. Putting it there saves space on the boot floppy image. ]

[These DOS drivers are optional - I put them here only because IBM did on their CD; delete if you don't need DOS programs.] DEVICE=X:\W4OS2\MDOS\VEMM.SYS DEVICE=X:\W4OS2\MDOS\VXMS.SYS /UMB DEVICE=X:\W4OS2\MDOS\VDPMI.SYS DEVICE=X:\W4OS2\MDOS\VDPX.SYS DEVICE=X:\W4OS2\MDOS\VCDROM.SYS DEVICE=X:\W4OS2\MDOS\VMOUSE.SYS DEVICE=X:\W4OS2\MDOS\VVGA.SYS [More DOS related settings] FCBS=16,8 RMSIZE=640 DOS=LOW,NOUMB SHELL=Y:\OS2\MDOS\COMMAND.COM Y:\OS2\MDOS

DEVICE=X:\W4OS2\VDISK.SYS 3584,512,512                                            [The virtual disk driver - See IBM Warp documentation for options]

[The next program allows you to pause the system during the boot, and run a command line session] CALL=X:\W4OS2\CMD.EXE /C "X:\W4OS2\IPLPAUSE.EXE 15" & EXIT

[Here is where you determine whether you are invoking a command line session, a PM session, or a WPS session. I identify the directory with booting files as being under the W4OS2 directory.]

PROTSHELL=X:\W4OS2\PMSHELL.EXE          [ For PM or WPS; for command line, use PROTSHELL=...\BOS2SHL.EXE] SET OS2_SHELL=X:\W4OS2\CMD.EXE          [Same for command line, PM or WPS] SET RUNWORKPLACE=X:\W4OS2\MSHELL.EXE    [not needed for command line; use PMSHELL.EXE for WPS, here I use EWS program mshell.exe to have a small footprint PM shell but don't have all the bells and whistles of the Desktop.]

[Ini files are set up according to where the system boots. Using makeini.exe and the sample *.rc files supplied with OS/2, I created the following ini files: For user.ini files - X - the drive number of the boot device; Q (or "?") means that the system looks for the drive with the Desktop on it, and updates that Desktop. For sys.ini files, the first letter is the boot drive, and the second letter is where the swap file is, here the virtual disk.] SET USER_INI=Z:\OS2\XQ_USER.INI SET SYSTEM_INI=Z:\OS2\XY_SYS.INI

SET AUTOSTART=TASKLIST,FOLDERS                       [For WPS only] SET KEYS=ON SET COMSPEC=X:\W4OS2\CMD.EXE                         [For command line, PM, WPS] SET HELP=Y:\os2;X:\W4OS2; SET PROMPT=[$p] SET KEYS=ON SET GS_LIB=X:\GSCRIPT\GS5.10:X:\GSCRIPT\GS5.10\FONTS        [I include a copy of Ghostscript, a postscript and pdf file reader]

[Helps load various drivers, supposedly] DEVICE=X:\W4OS2\TESTCFG.SYS

[Here is where I set up my virtual disk and copy some essential files to it.] CALL=X:\W4OS2\CMD.EXE /C MD Y:\OS2 & COPY X:\W4OS2\CMD.EXE Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XCOPY.EXE Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XQ_USR.INI Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\XY_SYS.INI Y:\OS2 >NUL CALL=X:\W4OS2\CMD.EXE /C MD Y:\OS2\MDOS & COPY X:\W4OS2\MDOS\COMMAND.COM Y:\OS2\MDOS >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\MDOS\DOSKRNL Y:\OS2\MDOS >NUL CALL=X:\W4OS2\CMD.EXE /C MD Z:\OS2\DLL & COPY X:\W4OS2\DLL\SESMGR.DLL Y:\OS2\DLL >NUL CALL=X:\W4OS2\CMD.EXE /C COPY X:\W4OS2\DLL\BVSCALLS.DLL Y:\OS2\DLL >NUL RUN=X:\W4OS2\BOS2REXX.EXE                          [BootOS2 file to allow use of REXX]

Config.sys and Command Line Options
Memman=swap and Swappath= statements. It may seem strange to have swapping enabled in my example because I am booting to an emergency virtual disk, and shouldn't be using the system that much. I don't know how much memory most users have, and this seems the easiest way to insure that they won't run into a situation where all memory is committed and swapping is not enabled.

CD_BOOT.FLT - Only one known command line parameter

/D:2 - means the equivalent of two 1.44 floppies, or 1 X 2.88 Meg floppy for the boot image.

The other options available are:

/D:3 - which allows you to emulate the effect of having three 1.44 Meg boot floppies.

/D:4 - which allows you to emulate the effect of having 2 x 2.88 Meg boot floppies.

Warp 4 comes with three installations disks, and when you load everything off of one, the system asks you to insert the next floppy. Here, the system is normally able to load everything from one 2.88 Meg image (I use 2.4 Megs on my image), but if necessary, you can place additional files onto a 1.44 or 2.88 Meg floppy and create an image for it. The hardest part is to get it onto the CD so that it is immediately after the 2.88 Meg boot floppy image. If you can append the image of a 1.44 Meg floppy onto the end of the 2.88 Meg image, then you have 4.3 Megs of storage to work with. (5.82 Meg for 2 x 2.88 Meg floppies) Ought to be able to figure a way to boot from that. The easiest is to simply use the copy command:

copy 288boot.img + 144xtra.img /B osboot.img copy 288boot.img + 288xtra.img /B osboot.img

This will copy two images into one file, so that they are properly ordered. You would use osboot.img as the name of your boot image, and the /D:3 (/D:4) switch to load files contained in the 144xtra.img (288xtra.img) file. (I haven't tried this particular option, so there may be some pitfalls to my suggestion that I am unaware of. I also don't know what you would get if you tried to do a directory of the boot disk image, would you get the contents of both disk images, or only the first disk image?)

IBM1FLPY.ADD - The addition of /FORCE:1 /U:0 /F:2880 may not be necessary. It was added because a very recent Award BIOS would not properly boot a machine without this forced load of the driver. Without it, the machine's BIOS would erroneously indicate that 4 floppy drives were available, but when cd_boot.flt loaded, the floppy driver *.add would not load because it couldn't detect any floppy drives! The system then would fail to boot. Forcing the driver to load made it available when it was needed later. The meaning of these command line switches is documented in the on-line help for Warp.

IBMIDECD.FLT - This is a critical file and there are only two versions of it that are known to work correctly. According to the author of cd_boot.flt, there was a small bug in ibmidecd.flt that prevented cd_boot.flt from attaching to the CD (IDE drives only?) and he had to write a fixed version. This didn't prevent the boot from happening, but it did prevent the concurrent access of OS2CDROM to the CD drive holding the boot image. The result was that there was no drive letter for that CD and you couldn't access anything on it except the boot image! This first &quot;fixed&quot; version is in the zip file, and is 23,300 bytes in size, dated 5-7-96, and is called OLDIDECD.FLT. The latest IDEDASD update file that was released in October, 1998 appears to have a newer fixed version of ibmidecd.flt. It is dated 9/24/98, and is 24,156 bytes in size, and is called newidecd.flt in this package. Whichever version you use, and either works, should be renamed to ibmidecd.flt. The only advantage to using the later version is when you combine it with the other files in IDEDASD you should then have the capability of recognizing and being able to partition hard drives larger than 8 Gig.

USING IDE and SCSI DRIVERS SIMULTANEOUSLY
In my example config.sys, I have included drivers for both IDE drives and SCSIi drives. This is by way of example only, because you should include only the drivers you need. I choose to include both because I am anticipating replacing one of my machines, and do not know what types of drives it will have on it. By using a boot image capable of handling both types of drives, I don't have to reburn the CD at some later date to accommodate my new system. When you burn your CD, consider carefully what drivers your need, or are likely to need. I don't know if you could have two separate config.sys files prepared, one for SCSI, the other for IDE, and then use the Alt-F1 option, which allows alternate config.sys files for booting, and actually give the user a selection of the drivers to be loaded. Even if it would work, that seems like a lot of extra work anyway to accomplish something that having both types of drivers already loaded will already solve. This process is already complex, so IBM simplified it by simultaneously loading all applicable drivers. Since drivers that fail to load will not cause any subsequent problems, and are removed from memory, this is the easiest way to implement the boot process without giving unnecessary options to the end user.

DECIDING WHAT TYPE OF OS/2 SESSION TO BOOT
Before leaving this outline of the creation of the boot floppy, I need to discuss what decisions need to be made on booting to a command line, the PM or to a WPS Desktop. I haven't tried it, but it should be possible to have your system boot to OS/2 from a CD and run that way all the time. However, certain constraints probably render that inappropriate. First, you need to have your Desktop, swap, changeable configuration files and *.ini files on a drive where they can be modified by the operating system. Second, if you only have one CD, you need to keep the boot CD in it for any accesses of critical system files by the OS. Third, you cannot update your system without creating a new CD. Since the cost of CDR's is now down to less than $2, that is not a serious problem, but it may be time consuming. Of course, Extended Attributes (EA's) cannot be stored on CD's at the current time because there is no provision for them in the CD file system, and that may create problems. (But what if you created a hard drive image on a FAT drive, and used that image for your boot image on the CD? You'd probably be able to use those EA's stored in EA DATA.SF. Naturally, you'd still have to have another hard drive to store your Desktop, configuration, ini and swap files.)

That said, why create a bootable CD in the first place? I plan to use it as an emergency CD, so that if either of my hard drives, particularly my boot drive, fails, I have the ability to boot quickly to OS/2, partition a new drive, format it, and then restore my latest backup. With that in mind, when I created my bootable system, I set it up so that I can (hopefully) boot without having a functional hard drive. I get to the Presentation Manager and use MShell, a freeware package that allows you to run multiple command line sessions, and PM programs. My virtual disk is set up so that I don't need a hard drive to store any of my ini files, and I don't have a WPS Desktop. (Please note, I'd love to figure out a way to have a WPS Desktop that resided on a virtual disk. I tried it and could never get it to work.) Aside from booting to a command line session, this is probably the safest way to set up a bootable OS/2 CD.

As an aside, I also included iplpause in my config.sys, because that program allows me to interrupt the boot process and go directly to a command line session. This happens after all the device drivers are loaded, and just before the final parsing of config.sys takes place, typically just before the running of the CALL= and RUN= statements. So in a sense, I have two ways to get to OS/2, but one limits me to one command line session only, while the full boot allows me to run PM mode programs.

The El Torito Specification also allow the use of multiple boot images, so that means that you could have this emergency boot image I just described, and others. These others could allow you to boot to the full WPS Desktop if you desired. To do that, you use PMSHELL as your protoshell and for your runworkplace setting. I suggest that you create two or more sets of ini files for this. The first could let you boot with your C: drive as the default (assuming you boot there now), and it would simply update your Desktop, and you would have virtually full functionality. You can also set it up to boot with the Desktop on another drive, say the D: drive. The advantage to this, and it is a big one, is that when you boot to your C: desktop this way, unless you continue to use your original ini files, the revised ini file will reset your Desktop back to VGA resolution. If, like me, you have a 1024 x 768 screen display, you'll be shocked the first time you involuntarily go back to 640 x 480. Putting your CD Desktop on another drive will prevent this change from happening. All it takes is some careful editing of the *.rc files that you will use to create your new ini files.

OK, you've created the boot floppy, added cd_boot.flt onto it, modified config.sys, and added your favorite hard drive controller driver to the floppy and config.sys. Next, you to save the floppy image file.

B. Making the Floppy Image File (Required)
Making the image is simple, use savedskf.exe to create a file that is simply stripped from the floppy, sector by sector. There is only one caution in using this program, you must use two command line switches to insure that you do no compress the image, or skip empty sectors. So when you have created your floppy, you will create the image by the following command:

savedskf a: x:\images\boot.img /D /A

Where: /D /A switches to copy the entire image, without compression

\images\boot.img is the directory where you are storing this file

X: whatever drive you store your data on

a: The floppy drive that contains the bootable floppy

C. Creating the Boot Catalog (Optional)
This is an optional step that you can avoid if you use mkisofs.exe to create your CD tracks, or if you create an ISO image and use mkbootcd to enable CD booting. I have included a blank copy of bootcat.bin that you can use for your system if you need one to create a bootable CD. Up until recently, you needed to manually edit the ISO image with a hex editor to either create the boot catalog, or modify it to properly point to the bootable floppy image. There are now programs to do this work for you, so I no longer need to discuss the specific byte values that you need to create this file.

D. Create the ISO Image of the CD, Including the Boot Image and Boot Catalog (Required)
You need to create an ISO image of the CD because few programs are capable of creating a CD on the fly with the proper BVD and boot catalog. In 1998, there were only two commercial OS/2 specific CD mastering software packages that I know of: Cirrus Technology's Unite CD Maker, and RSJ's CD-Writer for OS/2. In September, 1998, I learned that Unite CD Maker (of which I am a licensed user) is no longer produced or supported. In any case, neither program has the ability to directly create bootable CD's. During 1998, OS/2 ports of the Unix programs mkisofs and cdrecord were released. This allowed you to use freeware programs to create and burn bootable CD's, but until now, you could only create bootable DOS or *nix CD's. I'll try to briefly describe the process with each of the programs.

Unite CD-Maker

You have two choices on how to proceed: create a virtual CD image with CD-Maker, and then use other software to modify it to make it bootable, or create a bootable image with other software, and then simply write the track with CD-Maker.

Using CD-Maker to Create a Virtual CD Image
With CD-Maker, you can set up the virtual disk image by simply dragging and dropping shadows of the necessary directories and files to the CD ROM stage you created to burn this CD with. After dropping all the files you want, including the floppy boot images, and a file that you will use as the boot catalog (I'll call it bootcat.bin throughout this discussion), you right click on your CD ROM stage object, and choose the option to make a virtual image. The program then proceeds to create a virtual CD image and store it in the directory you previously chose. You can modify it later with other programs to make the image boot capable. One advantage of this package is that it allows you to burn ISO level 2 CD's, which can have file names up to 31 characters in length, or even to create a CD with HPFS compatible file names, i.e., up to 255 characters in length. This last option means that it is virtually only useable in OS/2, but isn't that why you are reading this?

Other Software to Create a Virtual CD Image, and CD-Maker to Burn the Image
I was never able to get CD-Maker to accept the virtual image created by other software, which would then be utilize to burn a CD.

RSJ CD-Writer

I have been unable to find any documentation in the RSJ package that indicates it can create virtual images, but I am told that it is in the readme file, and you simply tell the system to attach a virtual disk to your hard drive, and then you can copy the necessary file to it. This is accomplished by the following command: cdattach d:\CD\boot.trk At this point, you start copying the required files (boot image of the floppy, boot catalog, possibly, and any other files you want) to this image. Once you have all the files copied, you probably need to close the image. At that point, you can then go to step E. below to modify the virtual image. (I haven't had a chance to test this, so READ THE MANUAL.)

You also have the ability to use mkisofs to create the ISO image and use RSJ to burn it, which works nicely. This package is also far less system intensive when the actual CD burn is being undertaken. With Unite CD-Maker, I saw CPU utilization of 99 percent, while burning a CD. RSJ CD-Writer resulted in about a 16 - 20 percent CPU utilization, a dramatic difference. RSJ also allows the use of the Joliet file system on CD's, discussed below.

Recently the producers of the RSJ software announced that they are investigating a way to add bootable CD creation capability to their product. Now that would really be nice.

MKISOFS

MKISOFS is a Unix package that was ported to OS/2, allowing you to create a virtual image of your CD, also known as an ISO image. With this program, you only create the image, and then use either RSJ CD-Writer or the UNIX port of cdrecord to actually burn the CD. Find it on Hobbes as mkisofs.zip, or mkisofs_111_112.zip (both courtesy of Robert Lalla). An alternate version of mkisofs that was ported to OS/2, and contains code to write Apple HFS readable CD's is mkhybrid.zip, which appears to be the same mkisofs code, with the Apple code added. Mkisofs needs the emx dll's to run.

Create a Virtual CD Image
A command line program, it allows you to create a bootable CD by giving the name and location of the bootable image, telling it what to name the boot catalog that it will then create. It also allows you to create a CD that uses the Joliet CD file system created by Microsoft, which has the advantage of allowing file names up to 32 characters in length. You then need to use the OS/2 CDFS.IFS file that is capable of reading Joliet CD's, but there are several on the 'net.

With mkisofs, you can organize your files on a hard drive in the manner that you them to appear on the final CD, or you can simply have a loooooong command line that tells it where to find all the directories and files. I find it easiest to create a directory that will be used for the new CD and tell it to use that for the image. Once started, it takes some time to actually organize the file system for the CD and write the image, but when it is done, you can immediately write the image to the CD, assuming, of course, that you only want one boot image. If you want multiple boot options, you include all of the bootable images in the directory to be copied, and modify the virtual image later.

Unite CD-Maker and Multiple Boot Images Under RSJ CD-Writer
Aside from doing hex editing on a virtual CD image, the best way to set up a virtual image with the correct byte values in the BVD and boot catalog is to use the program, mkbootcd, originally written in DOS, but now ported to OS/2. This program will take an image, created by mkisofs or Unite CD-Maker, which already has the necessary files included in the image, create the BVD, and place the proper byte values in the boot catalog. The program even allows you to use a command file to set this up, and the command file can be used to enable multiple boot images. I have included a copy of mkbtcd102.zip, the DOS version of the program, and also a copy of mkbtcd2.exe, the ported OS/2 version. The port also needs the emx dll's to run. The instructions for use are sparse, to say the least. The only ones I found are from the program's help screen:

Usage:

verify: mkbootcd isoimage

make: mkbootcd isoimage bootentryfile bootimage

mkbootcd isoimage bootentryfile - &lt; indirect

options:

- Use stdin

-Cnn Set bootSectorCount                                    [ 1 for any bootable floppy image]

-Fx Set bootMediaTypeFlags                                  [ 1=1.2 Meg, 2=1.44 Meg, 3=2.88 Meg, 4=HD]

-Ixx Set bootIndicator                                      [ 00 means this is NOT a bootable image, 88 = bootable image]

-Lxxxx Set bootLoadSegment                                  [ 07C0h - no reason to change this - It defaults to this anyway]

-Mx Set bootMediaType, F means Auto                         [In sample command file, this is used to tell the program to create a multiple boot CD]

-Bnnnnnn Set offset for multisession ISO                    [Only for multiple session CD's - not discussed here]

-Pnn Set entryPlatformID                                    [ 0 = x86 CPU -Only type under discussion here]

-Sstring Make Section entry with string                     [for use in creating multiple boot images]

example:

mkbootcd mycd.iso bootcat.bin osboot.ima -i00 noboot.ima -i88 osboot2.ima

[Make the image a multiple boot one, with bootcat.bin as the boot catalog, osboot.ima as the default boot image, noboot.ima as available, but not a CD bootable image ( -i00), and osboot2.ima a bootable image. If you do no place these images in the root directory of the CD, you have to provide the fully qualified name of the file, minus the drive letter.]

RSJ CD-Writer and Single Boot Image CD's
If you used mkisofs and RSJ CD-Writer to create a single boot image CD, you do not need to modify the image, and can burn it immediately. For multiple boot image CD's, follow the steps above.

F. Burn the CD (Required)
Your work is completed now, all you have to do is get the image on the CD. Throughout this discussion, I have assumed that you are burning the FIRST and ONLY session on a CD. Because the El Torito Specification requires the boot catalog to be on sector 17 of the last session of a multiple session CD, the system described above only really seems to work on single session CD's. So plan ahead for what you want on this CD.

Unite CD-Maker

At this point, all you have to do is drag the shadow of the CD-ROM stage that you have created onto the CD Burner icon, and you start your burn process. You will probably want to burn it as a mode 1 session, or pure data track, and not enable it for any further sessions, with the CD closed after this session is written.

RSJ CD-Writer

Open the CD View window, then open the CD Recorder window. Open a drive object, going to a window of the directory where your virtual image is stored (remember, it has a .trk extension), and drag the icon of the image to the CD Recorder window. You then click the record button, and the finish session button when recording is complete.

CDRecord/2

I haven't had time to test this program, but it seems straightforward. You simply enter the correct command line options to tell where the image is to be located, what SCSI device to use, and away it goes. Find it at :

http://www.geocities.com/SiliconValley/Sector/5785/cdrecord/cdrecordmain.htm

Additional Comments on Multiple Boot Image Options
As noted in the beginning, this process only works if you have a motherboard BIOS or a SCSI hard drive controller BIOS that allow you to boot from a CD. Not all BIOS's were created equal, however, and if you are going to create multiple boot image CD's, you have to take that into consideration. The El Torito Specification allows you to have the following options on your CD:

1. one default boot image - virtually every BIOS gets this right

2. multiple boot images can be shown one of two basic ways:

a. each additional image is shown as a separate bootable entry, shown in &quot;section&quot;s

default image

Section 1 image 1

Section 2 image 2

Section 3 image 3

b. each section can contain a group of bootable (or non bootable) images

default image

Section 1

image 1

image 2

image 3

Section 2

image 4

image 5

image 6

The problem in implementation comes in CD's that implement choice b. As shown in the attached table, generated by Tung Chen Tsai, the implementation by some vendors resulted in the user only knowing that the boot image was 1.44 Megs in size, but no name of the file, or other identifying data provided by the author of the CD is displayed. Other controllers, particularly the Adaptec ones, give you this identifying information, and make it easier for the user to choose the desired boot image. As a result, I recommend that anyone creating a multiple boot image CD use one section header for each bootable image. This seems to be the least common denominator that allows the user to obtain at least some information about the image being used to boot from. [NOTE: I have an Adaptec 2940UW, and a 2940. The difference between the two controllers is that the 2940, with BIOS V 1.23, will only boot the default image. Adaptec has told me that the 2940 was only designed to boot that one image. However, the 2940UW, with BIOS V 1.34.3, will boot multiple images. Frankly, I haven't had time to get that to work, yet.]

In addition to the above, if you want to create multiple bootable images for an OS/2 CD, you may need to use a hex editor on CD_BOOT.FLT to allow it to load boot images from anything other than the default boot image location. I think I have found the correct locations to modify, and it may also be possible to get this process to work without modifying the filter file, since the only real difference between different boot scenarios is the config.sys file. In either case, a discussion of that is beyond the intent of this document.

The El Torito implementation of each BIOS - by Tung Chen Tsai
The report everyone's been waiting for:

Table version 009. 29-Aug-97

(*1) To make multi sessioned bootable CD-R with mkbootcd required Adaptec EZ CD Pro. (Well, at the time he wrote this, it was true, for DOS. It can be done, with a lot of sweat, with RSJ CD-Writer.)

Reported :

SCSI: Adaptec 1542CF

IDE: CMC C55Pi+, GIGA ByteGA-586S, A-Trend ATC-6000

Complete Machine: Fujitsu FM-V5120T2 ,IBM PC-340

CD-R Writing soft: Applix CD-R Writer 3.0, Adaptec EZ CD Pro 1.11D/2.01/2.1, etc..

CD boot screen of Gateway P5/90 BIOS AMI 1.00.13.AX1T
bootable CD-ROM has been detected. ..

The boot sections of the bootable CD-ROM are:

Default Boot Image1. Section1

2. HDD

3. NT4S

4. Warp4J

Please select on option (0-4): 1

0. osboot.img (1.44M FLOPPY FORMAT)

1. WIN95RPR.IMG

2. 144test.img

3. AHA2940.IMG

4. FLOPPY.IMG

Please select one option:

---

Evaluation:

&quot;Default Boot Image1. Section1&quot; is not a typo error.

There is no problem in the boot function.

The implement isn't improper.

CD boot screen of Adaptec AHA2940 SCSI v1.23
Test condition:

mkbootcd 008d, sample session1.cmd in mkbtcd008d.zip

---

Adaptec AHA2940 BIOS v1.23 (c) 1996 Adaptec, Inc. All Rights Reserved.

Press for SCSISelect(TM) Utility!

SCSI ID:LUN NUMBER #:# 5:0 - IOMEGA  ZIP 100 SCSI ID:LUN NUMBER #:# 6:0 - PLEXTOR CD-ROM PX-4XCS

A BOOTABLE CD-ROM IS DETECTED IN YOUR CD-ROM DRIVE...

The boot sections on your bootable CD-ROM are: 0. DEFAULT ENTRY 1. Section 1 2. HDD 3. NT4S&gt; 4. Warp4J The boot entries in the section Section 1 are: 0. osboot.img (1.44M FLOPPY FORMAT) 1. WIN95RPR.IMG (1.44M FLOPPY FORMAT) 2. 144test.img (1.44M FLOPPY FORMAT) 3. AHA2940.IMG (1.44M FLOPPY FORMAT) 4. FLOPPY.IMG (1.44M FLOPPY FORMAT) Please select one option (0-4), ESC to bypass Bootable CD: 0 ---

Evaluation:

There are sections.

The BIOS displays Section, Entry, file name of boot image. Media type.

And we can choose all entries of selected section.

I think this is the best implementation.

(Non bootable entry is not shown except when that is DEFAULT ENTRY.)

CD boot screen of TEKRAM DC-390U PCI-SCSI
Test condition:

mkbootcd 008d, sample session1.cmd in mkbtcd008d.zip

---

TEKRAM DC-390U PCI-SCSI Controller

BIOS V2.00 Date : 1997-3-12

Installed at IOPORT = FC00h, IRQ = 10 - Level triggered

BIOS ROM mapped at C800h

Press F2 or F6 to Enter Configuration Menu

ID-LUN:6-0 SONY CD-ROM CDU-561 1.9i CD-ROM

Xfer Rate=4.0MB/Sec, Sync offset=15Bytes

&lt;&lt;&lt;&lt; bootable cd-rom found &gt;&gt;&gt;&gt;

(0) --&gt; Default Boot Section

(1) --&gt; Section 1

(2) --&gt; HDD

(3) --&gt; NT4S

(4) --&gt; Warp4J

==&gt; Select the section to boot, to abort :

---

Evaluation:

There are sections. But boots only with the entry at the beginning of the section when a section selected. We can't choose any other entry in that section. To be able to select any entry, only one entry can be written to each section. Non bootable entry is hidden also.

CD boot screen of Iwill SIDE2930U SCSI
Test condition:

mkbootcd 008d, sample session1.cmd in mkbtcd008d.zip

---

A Bootable CD rom Detected

0. Default Entry

1. Section 1

2. Section 1

3. Section 1

4. Section 1

5. Section 1

6. HDD

7. HDD

8. HDD

9. HDD

---

Evaluation:

All sections are ignored, but section name is displayed.

It is difficult to choose the image you want here, as well.

But, if only one entry is written to one section, it is better than Award..

Allows up to only ten bootable entries to be displayed.

Non bootable entries do not appear.

D boot screen of Award BIOS 4.51PG
(ASUS T2P4 2.03)

Test condition:

mkbootcd 008d, sample session1.cmd in mkbtcd008d.zip

---

Boot from ATAPI CD-ROM :

1. FD 1.44MB System Type-(00)

2. FD 1.44MB System Type-(00)

3. FD 1.44MB System Type-(00)

4. FD 1.44MB System Type-(00)

5. FD 1.44MB System Type-(00)

6. FD 1.44MB System Type-(00)

7. HD System Type-(01)

8. HD System Type-(01)

9. HD System Type-(04)


 * . HD System Type-(04)


 * . FD 2.88MB System Type-(00)

&lt;. fd 1.44mb system Type-(00)

It is difficult to choose the image this way. All bootable entries are displayed. (Non bootable entries are not displayed.)
 * Evaluation:All section are ignored, Media & System type only.

It can't count beyond 9, for higher numbers, you go with n+'0' for the number. (10+'0' is ':',11+'0' is ';',12+'0' is '&lt;', ....)

End of section created by Tung Chen Tsai.

Files in This Package
The following files are included in this package, called cdboot.zip: 3655d363.jpg        image file used in Bootable OS2 CD.htm Bootable OS2 CD.htm this document - modified from first version released bootcat.bin         sample boot catalog - single boot CD_BOOT.FLT         file to enable CD booting in OS/2 config.w3           config.sys file from original Warp 3 Server bootable CD config.w4            sample Warp 4 bootable CD config.sys FILE_ID.DIZ         file describing contents of this zip package OLDIDECD.FLT        original Warp 3 ide cd filter required to boot from ide CD's newidecd.flt         Warp4 ide cd filter required to boot from ide CD's (whichever used must be renamed to ibmidecd.flt) mkbtcd102.zip       DOS program to making CD images bootable mkbtcd2.exe         OS/2 port of mkbtcd102.zip's DOS executable* w3dir.txt           directory listing of Warp 3 files needed w4dir.txt           directory listing of Warp 4 files needed
 * need emx dll's for this package

I have not included a disk image for the boot floppy because it needs to be 2.88 Megs in size, and even zipped that is 1.4 Megs. If enough people request it, I will consider doing that at a later date, particularly if IBM releases its new server for e commerce, code named Aurora, on a bootable CD and I am able to get a copy of that bootable floppy image. If there are any significant differences between Aurora and my bootable image, I'd consider updating mine and releasing it. I'd also consider releasing my boot floppy image if people cannot get the virtual floppy disk to work. But if that doesn't work, and I release my boot floppy image, it would have to be used as is. Might be time then for me to start selling the service of creating the bootable floppy image or a bootable CD.

Acknowledgments
Adaptec, Advansys, AMD, AMI, Apple, Applix, Asus, A-Trend, Award, Diamond, Cirrus Technology, Fujitsu, Gateway, GIGA Byte, IBM, Microsoft, MS-DOS, NT OS/2, Phoenix, RSJ CD-Writer and Unite CD-Maker are the registered trademarks of their respective companies. Other programs mentioned here that are not commercially available are either freeware or shareware. Please register the shareware packages.

The creation of a bootable CD under OS/2 would not be possible without the work of several developers at IBM, who created the boot filter, and have apparently modified the production ibmidecd.flt driver to allow the continued use of bootable OS/2 CD images. Beyond those individuals, Sam Detweiler of IBM Austin provided some basic background information about the bootable CD process, and gave me enough information to start the search that led to this point. Robert Lalla of Germany ported mkisofs and mkbootcd from Unix or DOS to OS/2, and also did a tremendous amount of work in actually getting a system to work. He discovered the Award BIOS problem, and confirmed that the latest ibmidecd.flt file has the necessary fixes to allow it to be used (thereby allowing you to recognize IDE drives that are larger than 8 Gig).

Assistance
This driver has not been officially released, and there is no public documentation on it. As I finalized this documentation, I found out that IBM may be considering using the bootable CD process on the new Aurora (Warp server 5 for e commerce) server package, and even supporting the boot filter. I don't know if that implies they will publicly support and document it, but at least they don't appear to be abandoning it. I'm hoping to get copies of the new drivers if and when they are released. Until IBM makes a commitment, I have muddled through the process, and can provide some limited assistance. If you need to create multiple bootable images, I may be able to provide some direction on how to accomplish the task. I can be reached at dermodya@nwlink.com. Robert Lalla (rlalla@stepnet.de) probably knows more about the process than I do, and can certainly provide assistance with mkisofs.