IBM employee-written software (unsupported freeware) to create boot floppies or small boot partitions for OS/2 2.x. Version 5.00, supports OS/2 2.11 including CSD’s to that level. No more booting from install disks.

Contents of the BOOTOS2.DOC file

The BOOTOS2 program is a utility that allows you to build a BOOTable OS/2 V2.xsystem using an existing OS/2 V2.x system. The BOOT system can be installed oneither Floppy Disks or a Hard Disk Partition.

There are three types of BOOT systems you can install:

Minimal : This is a basic OS/2 V2.x system that supports one or more OS/2 Full Screen sessions. All 16 and 32-bit OS/2 Full Screen applications are supported. When installed on a hard disk drive, you can use the VDM option to add support for full screen VDM sessions. The ability to switch between different Screen Sessions is supported by the supplied Protect Shell program, BOS2SHL. You can switch between Screen Sessions, both OS/2 and VDM, using the Alt-Esc key sequence.

A Minimal BOOT system can installed on a single 3.5" 1.44M Floppy Disk or to a small (2-3M) hard disk partition. Installation to a single 2.88M floppy disk is also supported. Because of space constraints, it is highly recommended that unless you are installing to a 2.88M disk or to a hard disk partition, you use the 2DISK option to create a 2-Disk BOOT System. If your A: drive is 5.25" 1.2M, the 2DISK option will be assumed.

PM : This is an OS/2 V2.x system that supports one or more OS/2 Full Screen or PM sessions. If the VDM option is specified, support for both Windowed (i.e. Seemless) and Full Screen VDM sessions is added. The ability to switch between different Screen Sessions is supported by the supplied Protect Shell program, PMSHELL. You can switch between Screen Sessions, both OS/2 and VDM, using the Alt-Esc key sequence.

A PM BOOT System requires about 9M of hard disk space. This does not include the disk space needed for the SWAP file.

WPS : This is an OS/2 V2.x system that supports one or more OS/2 Full Screen or PM sessions. If the VDM option is specified, support for both Windowed (i.e. Seemless) and Full Screen VDM sessions is added. The ability to switch between different Screen Sessions is supported by the supplied Protect Shell program, PMSHELL. You can switch between Screen Sessions, both OS/2 and VDM, using the Alt-Esc key sequence. The difference between this and a PM BOOT System is the availability of the OS/2 WPS. Certain default System Program and Folder objects are included.

A WPS BOOT System requires about 9M of hard disk space. This does not include the disk space needed for the SWAP file.

Syntax: BOOTOS2 <2DISK[=drive]>

SOURCE= Depending on what type of install you ask BOOTOS2 to perform, certain files might be required from the install disks you used to create your active OS/2 system. One file that is always required is SYSINSTX which is used to create the OS/2 BOOT record, OS2BOOT. The file SYSINSTX.COM is (so far) always found on the first Install disk. If you are creating a BOOT Disk, then the files KEYBOARD.DCP, VTBL850.DCP, and the CONFIG.SYS file from the install disk are also required. These files (so far) are always found on the second install disk.

Normally BOOTOS2 will prompt you for the Install disks it needs. However, if you installed OS/2 over a LAN or equivalent redirected source, you can use the SOURCE option to point to these redirected sources. The value of SOURCE is usually a standard CID directory structure, as defined in "GG24-3780 : OS/2 V2.0 and V2.1 Remote Installation and Maintenance".

Alternatively, SOURCE can point to a single directory where all the required files are located. This is the usual format OS/2 CSD remote installs where all the install disks are copied to a single directory. You could alternatively create a single directory that contains only those files needed by BOOTOS2 and use the SOURCe option so users won't have to worry about install disks.

TARGET= By default, BOOTOS2 will install the BOOT system on a floppy disk in your A: drive. You can use the TARGET= argument to specify an alternate Drive to install the BOOT system on. This alternate drive can be another floppy or a Hard Disk Drive. Any medium capable of being booted from can be a target.

Values for target are a single drive letter: A .. Z

TYPE=PM BOOTOS2 will install a BOOT System that will support PM Applications. The BOOT System will be accessed as a single OS/2 Windowed Command Prompt.

TYPE=WPS BOOTOS2 will install a BOOT system that will support PM Applications. The BOOT System will be accessed using the OS/2 WorkPlace Shell (WPS).

NLS By Default, BOOTOS2 will get information regarding the NLS environment from the following CONFIG.SYS statements:

If your environment requires different values for the above statements, you specify them via the NLS argument. Please note that you must specify all three values.

NOTE: The statement is only valid for a TYPE=PM or TYPE=WPS install. For a minimal install (the default) the 'stripped' versions of the NLS modules, KEYBOARD.DCP and VTBL850.DCP, are used which do not support alternate values.

2DISK If creating a BOOT system where the target is a floppy disk drive, the 2DISK option allows you to spread the BOOT system across two disks, increasing the amount of space available for both required and optional files.

By default, if your system has a B: drive, BOOTOS2 will use that as the second drive. If you don't have a B: drive then BOOTOS2 will use A: for both disks (in which case you'll have to swap disks during OS/2 IPL).

Alternatively, you can specify an alternative target drive for the second drive. This is useful when you want to use a floppy drive other than B (for whatever reason).

Also, if you have a B: drive, but still want to create a 2-Disk BOOT system using only the A: drive, you can specify 2DISK=A to override the default of using B.

REXX If room allows, support for REXX will be installed.

HELP BOOTOS2 will try and add basic OS/2 Help support.

VDM Support for Virtual Dos Machines (VDMs) will added.

*NOTE* This option can not be used when the target drive is a floppy disk.

*NOTE* When VDM support is installed on a Minimal system (Text Only), to start a new VDM session press the Ctrl-D key combination. This will invoke a new VDM session.

SYSED Add support for the OS/2 System Editor (E.EXE)

SWAP= For a TYPE=PM or TYPE=WPS install, the default value for the SWAPPATH is the ROOT directory of the target BOOT system. You can use this option to place the Swap File in a different directory.

TRACE Use this option to create a Trace of the Install Process. A file called BOOTOS2.LOG will be created that will contain a complete record of the requested BOOT System Install process. By default the LOG file will be created on the same physical directory the BOOTOS2.EXE program resides on. You can optionally specify an alternate path for the LOG file; e.g. TRACE=drive:\path

FORMAT You can use this option to have BOOTOS2 force a certain type of Format (i.e. FAT, HPFS, or NONE) to the target drive. This is usefull for automated processes.

QUIET This will run BOOTOS2 such that no output is produced. This is also useful for automated processes. You can use the TRACE option to maintain a record of the install. Please note that because BOOTOS2 can't prompt the user to ask about formating the target drive, if you don't explicitly specify the FORMAT option, FOAMRT:FAT will be assumed.

The following 5 options can be used to force BOOTOS2 to assume that the specified OS/2 v2.x version is the 'active' level. Usually BOOTOS2 will determine this automatically by examining the SYSLEVEL.OS2 file, so you shouldn't need to use these options under normal circumstances. However, there are times when the SYSLEVEL.OS2 file can become corrupted, making it impossible for BOOTOS2 to determine the active system level. You can use these options to get around this problem.

You must run BOOTOS2 from an existing OS/2 V2 system. The BOOTOS2 programwill analyze your system and create a BOOT system that is specific for it. Forexample it will determine if your system supports features such as HPFS or SCSIand add the appropriate support for it. Because of this, a BOOT disk createdfor a specific workstation will not necessarily work correctly on a differentworkstation.

If you install the BOOT system on a Hard Disk Drive, you'll probably want toalso install the OS/2 BOOT Manager and add the BOOT system to it.

Please note that the BOOT system installed with this release of BOOTOS2 doesnot support Windows. A future release of the program might do soif enough users want it (and I figure out how).

- Fixed a problem where BOOTOS2 was not recognizing a Floppy Disk Drive as a Removable medium if no Disk was in it when the program first started. This would cause BOOTOS2 to install the wrong BOOT System, resulting in various errors.

- Fixed problem with FORMAT by making it run Synchronously so if it Fails, an error code will be returned.

- Added support for NLS Statement

- When COPYing file, added more meaningful error messages

- Fixed problem running BOOTOS2 from a ROOT Directory

- The temporary directory where files from the install disks are copied is changed from the directory where BOOTOS2.EXE is executed from to a new subdirectory based off of it named BOS2TEMP This will prevent BOOTOS2 from overwriting and deleting system files when it is located on the \OS2 directory of the BOOT Drive.

- The INI files can now be located on your DPATH

- If the Target Drive is already formatted and contains data, the option to run the Install without formating is given.

- Added special support for the Image Adapter/A

- All DLLs will be located via LIBPATH instead of looking automatically for it in \OS2\DLL

- Changed TARGET= to allow for X or X:

- For a minimal install, a check will be made to see if there is enough room left on the target drive to copy over extra files like CHKDSK, UHPFS and OSO001.MSG

- Fixed problem where HPFS support was not added if the Target drive was formatted for HPFS but the active system did not have HPFS support.

- Added support for 2-Disk BOOT System via 2DISK argument

- Added NLS support for FORMAT by querying system for the response character to use: US default is 'Y'

- Added support for a BOOT system when active system is OS/2 2.0 with Service Pack or OS/2 2.1

- Added support for REXX invocation argument

- Added support for ABIOS argument. This allows a user to explicitly specify that the workstation supports ABIOS. This will allow the user to circumvent the problem where "RAM Loadable" MicroChannel machines were being diagnosed as not supporting ABIOS; causing the wrong set of system files to be loaded.

- Changed external name to BOOTOS2

- Added support for the TRACE invocation option

- Added support for the SWAP= invocation argument

05/93 : (V3.00)

- Updated BOS2U21 and BOS2S21 files to 2.1 GA levels

- Fixed 2DISK option. It will no longer return RC=4 after trying to format B.

- Added support for SVGA; Copy over \OS2\SVGADATA.PMI

- Added code to copy over BASEDEV= invocation arguments

- Added code to copy over HELPMGR.DLL if room allows

- Added 2.1 support for 8514 by updating BOS2U21.INI with the proper values for PM_DISPLAYS. This updating of BOS2U21 will be done for all display types if necessary.

- Added support for HPFS386

- For a Disk Install, install sequence changed so the files SYSINST1 and HARDERR are only copied if there is room. This frees up room for BIO files required by certain MicroChannel machines that could not fit otherwise.

*NOTE* If SYSINST1/HARDERR are not installed, then CAD will not work

- Enhanced install of BASEDEV drivers. For a single 1.44M BOOT Disk, only those BASEDEV drivers that are needed for accessing DASD (.ADD) are copied. Otherwise, if room allows, all BASEDEV drivers will be copied.

- Removed copying of DTM.DLL for a TYPE=PM or TYPE=WPS install. It wasn't needed for anything as far as I could tell and at least one user complained it wasn't installed on his base OS/2 system

- Support for the IBM IA/A is not working in this release. I am trying to get help with this from the IA/A development team, but it might take a while. If you have IA/A support installed on your active system when you run BOOTOS2, you can try the following:

* On the \OS2\DLL directory of your active OS/2 2.x system, look for a file named DISPLAY.OLD; this is the DISPLAY.DLL that was active before you ran the IA/A INSTALL program. Copy this 'over' the DISPLAY.DLL that BOOTOS2 installed on the \OS2\DLL directory of your 'target' system.

* In the CONFIG.SYS of your target system, look for the following statements:

DEVICE=\OS2\XGARING0.SYS DEVICE=\OS2\IAOS2RFS.SYS SET VIDEO_DEVICES=VIO_yyy,VIO_IBMIAA SET VIO_IBMIAA=DEVICE(BVHVGA,BVHIAA) SET VIO_yyy=DEVICE(BVHVGA,BVHyyy)

- Enhanced the 2DISK option to work on a system with a single Disk Drive.

- Enhanced the TRACE option to accept an alternate PATH where BOOTOS2.LOG will be created.

- For XGA support, all files on the XGA$DMQS directory will now be copied to the Target Drive.

- Enhanced BASEDEV processing to search for target files via DPATH instead of just on the \OS2 directory.

- Fixed support HPFS386 support; files HPFS200.386 and HFS.MSG are copied as well as HPFS386.IFS. For a minimal install, the BOOTSH.EXE OS/2 Shell program will be copied and used as the PROTSHELL.

- For SVGA support, made copying of SVGADATA.PMI optional. This is in case the SVGA ON command was not yet run

- Mouse support will be added to a minimal BOOT System if room allows

- Added support for the OS/2 2.11 CSD SP and 2.11 Manfacturers Refresh

- Enhanced SOURCE= to allow for Service Pack (CSD) install by allowing it to point to a single directory instead of a CID directory structure.

- Added HELP option to optionally add support for OS/2 Help if room allows. The files HPMGRMRI.DLL and HMHELP.HLP are are copied, and a SET HELP= statement is added to the CONFIG.SYS

- For a minimal system, BOOTOS2 will now use it's own SHELL program, BOOTSHL, instead of SYSINST1. Unlike SYSINST1, BOOTSHL program supports multiple screen sessions (via Alt-Esc). It also supports STARTUP.CMD

- Added support for VDMs via VDM option

- Added some new invocation arguments to allow for unattended installs.