This article has three purposes:

1. To summarize the procedures for applying the ALT+F2 boot default patch described in The OS/2 Warp Survival Guide by Doug Azzarito and David W. Green.

2. To review my personal experiences with this procedure.

3. To ask others to share their experiences with it.

The OS/2 Warp Survival Guide was published by John Wiley and Sons, Inc. (ISBN 0471-06083-6 copyright 1995). On pages 498-499 it describes a procedure to patch the OS/2 kernel so that the ALT+F2 boot-up behavior is the default option.

If you are not familiar with this, when OS/2 boots and 'OS/2' shows up in the upper left hand corner of the console screen, you can enter ALT+F2 at the keyboard and while the splash graphic displays on the screen the base device driver names will be displayed below the graphic as they are installed. By-the-way, another option at this point in the boot process is to hit ALT+F1, to bring up the 'Recovery Choices' menu, useful for restoring your system to archived states when things go wrong.

The base driver names are displayed using the characters associated with the graphics mode used for the splash graphic display, making them slightly smaller than those with the normal 80x25 full screen text mode. My personal interest in the ALT+F2 patch was that it enabled more information to be displayed during bootup even if the display monitor was limited to only graphic operation modes until SVGA drivers become active. (See my previous OS/2 For You article on scan convertors for more on this.)

The first thing to be mentioned about this patch is that you must make sure you have alternative boot procedures available to bring up and re-enable your primary OS/2 installation before you try it. This includes being able to run SYSINSTX, the tool for making a partition or disk bootable by OS/2. It doesn't matter whether this capability is provided by a maintenance partition or removable media, as long as you have SYSINSTX available. Test that the media does boot without problems. If you are unfamiliar with setting these things up, study the 'BOOTOS2' IBM employee written software (EWS), that is freely available for use.

The first step Azzarito and Green give is to create a file, typically called ALTF2.PAT, with the following contents:

Even with the above mentioned boot safeguards, Azzarito and Green begin the procedure by making a backup of the OS/2 kernel by:

to backup the virgin kernel. You then run:

and if you don't get the 'The verification failed for OS2KRNL' message, you should get the base device drivers automatically displayed as they are installed when you next boot up. If the boot goes awry, boot via emergency media, and first try:

before resorting to SYSINSTX.

This patch will still be overridden if you use ALT+F1, but does change the default behavior for a normal boot up to what happens when you press ALT+F2.

As Azzarito and Green point out, the location where the patch must be applied has been known to differ from what they initially describe. In this case, you have to locate the byte string to be changed and adjust the patch script appropriately. The string can be located with any DOS 'DEBUG' like tool, hex dump utilities like the UNIX worlds 'od' or the hex dump program in Bill Schindler's Down To Earth REXX, or a hex editor, as long as the tool is capable of handling a file the size of OS2KRNL. If you are unable to locate software to find the string with, contact the author or Mr. Know-It-All and we'll point you to some resources.

This was the case for me, I needed to locate the byte string in the kernel, and my notes seem to indicate I used the old DR-DOS 5.0 SID debugger for purposes of locating the byte string to be changed.

A brief note on the patch command. Don't confuse the OS/2 patch with the UNIX world's patch written by Larry Wall, of Perl fame. Larry's tool is for applying minor updates to source code or scripts from a '.diff' file that is derived by comparing the original to an updated version, producing a compact way to communicate changes. The OS/2 patch command, similarly can make minor updates to files, but is more oriented toward binary files, providing capability similar to some aspects of the DOS 'debug' program, or a hex editor.

Some other things you might want to consider result from my searching Google for information on OS/2 and ALT+F2:

• Stiphane's OS/2 Web Site provides a program (http://cyniska.ubishops.ca/os2/fun/warpb103.zip) that supposedly will perform the patch for you. I have no personal experience with this, and welcome anyone relating any they may have.

• The ConfigTool 0.95 database - BASEDEVICES (which is part of the documentation for a program called 'ConfigTool' by Goran Ivankovic) suggests putting a '/v' switch on basedev statements in CONFIG.SYS for more information from the base drivers during bootup. However, my personal experience is that my system can only cope with this being on one basedev statement at a time. Any more than one basedev with this switch produces a 'SYS 2068' error message. This switch on the IBMATAPI.FLT basedev statement produces a message that the driver has failed to load. The messages this switch produces display after all the base drivers have loaded, the boot splash graphic has finished displaying, and the system is back to conventional 80x25 text mode. For this reason, it has little to do with my original reason for applying the Alt-F2 patch, but may be useful if you have a special need to monitor a particular driver.

Finally, I should point out that I'm looking for feedback from others who've tried it. All the work I did was for my Warp 3, FixPak 35 system. I do not know how any of it works on Warp 4. If you have any experiences to share, feel free to contact either the editor of OS/2 For You or me.

Addendum

Having patched the OS/2 kernel successfully I went on a patch rampage. A couple of DOS kernels, a web browser, shells, any software that had unsatisfactory default environmental variable names or configuration file names - all subject to my whim without so much as a re-compile. One tool extremely useful for this is the EMX 'strings' port from the UNIX world, available from Hobbes. I first got a copy of it off of a 'Hobbes Ready-to-Run' CD-ROM, you might be able to build it from source if you have EMX installed and download the code. It simply prints out the strings of text in an otherwise binary file, giving the location in the file of the printable characters. Depending on what language the program was written in, these strings may be 'counted', (preceeded with a byte or two with the string length encoded) or 'delimited', (followed by a character that marks the end of the string). If you desire, this may enable you to shorten the string, when you edit it to the value you want with the hex values of the desired final string with patch.

Another use for the 'strings' command is suggested in The Multi-Boot Configuration Handbook by Roderick Smith (Que Corp., ISBN 0-7897-2283-6), page 562. Frequently, you may have some new PC device, with no driver provided for your OS of choice, and the chipset identification deliberately removed, masked, etc. What you can do is run the drivers that are provided through 'strings,' and hunt for clues as to what actual chipset the device uses. It may literally be spelled out as a text string in the driver you have to examine. Given this information, you may be able to track down drivers for the desired OS, provided for that chipset from alternate sources such as the chipset manufacturor, by another manufactorer that uses the same chipset for a similar device, or the OS publisher.

I first became aware of this tool reading the real life cracker break-in book @ Large, which described the FBI's 'Phantom Dialer/Info Master' case. A system administrator used 'strings' to analyze suspected bogus software for included text that might present threats, political manifestos (but I repeat myself), psychotic/paranoid ravings etc. that would be expected from an anti-social character. It even works for cliche environmental variable or configuration file names.