Hibernation toolkit for OS/2 Warp


1. Introduction

   One of certain features available in Windows 2000 is its "hibernation"
   (a.k.a. "fast boot") facility, which makes it possible to save the current
   system state, shutdown the system, and restore the system state at the next
   reboot. Surprisingly, this feature has been developed for OS/2 back in
   1995, when Windows NT 3.51 didn't even exist! However, it hasn't been paid
   with much attention since then, so it requires certain hacking in order to
   work now.

   To be exact, OS/2 has three coexistent technologies, each based on the
   preceding one:

   - Standard hibernation, with stopping or rebooting the system afterwards.
     Note: I didn't say "powering down". Perhaps, DOS programs launched via
     dedicated sessions, or the "fast boot" feature in conjuction with
     third-party APM utilities may help here.

   - "Trapdoor". This implies hibernation, but the system does not stop,
     instead, it switches to the real mode and runs a small BIOS-dependent
     program which you may pass on from OS/2. This may be a boot sector, an
     MBR or some other OS loader.

   - "Dedicated DOS mode". This is a wrapper for the trapdoor to start a
     user program via specialized IBM DOS. The respective CONFIG.SYS and
     AUTOEXEC.BAT are created for it. Unfortunately, "DOS" implies that C: must
     be a FAT16 primary drive. On the other hand, this is the straightforward
     WPS-integrated solution, i.e. you only tell the name of program to run,
     and then seamlessly return to OS/2. Only DOS and 386-Enhanced Windows 3.1
     are supported this way.

   This toolkit provides the following enhancements:

	- Installation of hibernation-capable environment to OS/2 v 4.50:
		- Installation of base modules (HYBERLDR, etc.)
		- Replacement of OS/2 loader
		- Fixes for file system and device driver shutdown

        - Fixes for hibernation on XR_M006 and later CSDs
		- Fixes for file system and device driver shutdown

        - Hibernation support for Warp 3 by means of an OS/2 v 4.0 kernel
		- Patching the kernel to report version 3.0
		- Fixes for file system and device driver shutdown,
	     OR - Workaround for the above mentioned fixes by supplying
                  XR_M005 kernel and patching PMVIOP.DLL (not recommended).

2. Requirements

	- OS/2 v 4.50: OS/2 v 4.0 with XR_M013+
                    OR Merlin Convenience Pack
                    OR eComStation
        - OS/2 v 4.00: XR_M006 and higher
        - OS/2 v 3.00: XR_M032 and higher

        - Uniprocessor kernel. The SMP kernels do not support hibernation.

        - FAT or HPFS OS/2 boot partition. The FAT-only limitation has been
          eliminated as of version 1.50 of this toolkit. However, Ext2FS is
          not yet supported.

        - LXLITE v 1.21 or higher. For now, version 1.31 is available at:
          ftp://hobbes.nmsu.edu/pub/os2/util/archiver/lxlt131.exe

        - 512K of disk space. More will be needed when you hibernate your
          system.

	- Overall knowledge of OS/2 system management tasks, i.e. unlocking
	  DLLs, handling bundles, dealing with packed executables, recovering
	  from boot problems, etc. There isn't much of tutorial here, and it's
	  quite dangerous job!

   Notes:

      1. In OS/2 v 4.0 with system levels prior to XR_M006 it's not necessary
         to install this toolkit at all. It's useless - there is nothing that
         can be fixed.

      2. For OS/2 v 3.0, a subset of Warp 4 has to be supplied (see below). 
         It's certainly not legal to copy files from a newer version of OS/2
         (unless you are a legal licensee of both versions), but it is up to
         you to decide. You have been warned.

      3. IBM1S506.ADD v 4.20+ can lead to reboot after restoring the system
         under OS/2 v 4.50. As for now, version 4.01 of IBM1S506.ADD is known
         to work. A third-party driver, DANIS506.ADD by Daniela Engert, is
         also known to function properly.

3. Installation

   Please read this section carefully and perform all the steps.

   3.1. Verification

	Please verify that the patch facility (HIBPATCH.EXE) works by invoking
        it - a help will be displayed. It relies on IBM LIBC and will fail if
        its DLLs are missing. Also, it uses a small DLL of its own
        (PATCHTKT.DLL), so be sure to move the DLL along with LIBPATH if the
        HIBPATCH.EXE is moved to some other location.

        Next, it is recommended to make sure that your boot partition is
        recognized by the hibernation driver. For this, we have provided a
        utility called MFSTEST. Run it as MFSTEST x:, where x: is your boot
        partition. If any files will be considered not eligible for the direct
        access, they will be shown out. Also check that the partition size is
        reported correctly.

        Tip: MFSTEST.EXE may be aborted at any point by pressing Ctrl+Break.
             Its full test cycle may be too long to wait for.

   3.2. Kernel update

	 3.2.1. OS/2 v 3.0 procedure

		We'll now install OS/2 v 4.0 kernel. Please find a copy of
		Warp 4, and a fixpak: XR_M005 or XR_M012 is recommended.
		Unless you want a "technically correct" hibernation, we advise
		XR_M012, for the following particular reasons:
			1. The latest kernels are more stable.
			2. Re-forwarding undocumented ordinals in PMVIOP.DLL
			   is a much more dangerous job than stubbing certain
                           notification routines in kernel.

		First of all, install the following files to \OS2\BOOT (backup
		of existing files may be wise):

		IBMKBD.SYS
		RESOURCE.SYS
		ISAPNP.SNP
		PNP.SYS

		Now, unfold the Fixpak, then manually unpack and install the
		following files (to unlock locked DLLs, run UNLOCK.EXE from
		LXLite, specifying their names on the command line):

		\OS2KRNL
		\OS2LDR
		\OS2LDR.MSG
		\OS2DUMP
		\OS2\DLL\DOSCALL1.DLL
		\OS2\MDOS\VW32S.SYS

		Most of files are in FIX\OS2.1 directory of the FixPak. Note
		that there may be two separate OS2LDR files, one for OS/2, and
		another one for WSoD. You'll need the OS/2 one (it's located
		in FIX\OS2.2 directory, not anywhere else!)

		Now you're about to patch the kernel. Unpack \OS2KRNL with
		LXLITE /X, and run HIBPATCH \OS2KRNL /WARP3. You should get a
		report about specific entry points being patched (there are 5
		or 6 such ones).

		One more patch:
	
		1. If you're using XR_M005 or earlier kernel: unpack
		   \OS2\DLL\PMVIOP.DLL and run
		   HIBPATCH \OS2\DLL\PMVIOP.DLL /PMVIOP.
	        2. If you're using XR_M012, run HIBPATCH \OS2KRNL /KRNLFIX.
		   This time it will report two entries.

		Now, if everything went fine, the kernel may be packed back.
		Run LXLITE \OS2KRNL and read on.

	 3.2.2. OS/2 v 4.0 (XR_M006...XR_M012) and 4.50 procedure

		For OS/2 v 4.x systems, only one kernel patch is necessary.
		Run LXLITE /X \OS2KRNL, then HIBPATCH \OS2KRNL /KRNLFIX. If
		it does not report errors, pack the kernel: LXLITE \OS2KRNL,
		and read on.

   3.3. Installation of hibernation environment

	There are two separate cases which have to be followed correctly unless
	you want to crash the OS/2 loader and MBR.

	 3.3.1. OS/2 v 3.0 and 4.0 (XR_M006...XR_M012)

		Use the TRUEMODE.400 file from this package. Unpack it onto
                your OS/2 startup drive. You may watch how \HYBERLDR goes to
                the root and certain files pass to \OS2\SYSTEM.

                Patch the loader by issuing HIBPATCH \OS2LDR /LDRFIX. This
                is IMPORTANT to prevent deletion of master boot record (MBR).
                Be sure to patch the loader for all subsequent Fixpaks and
                updates of your system.

                In OS/2 v 4.0, if you have installed "Dedicated session
                support" during first-time installation, then you may
                actually skip this step.

	 3.3.2. OS/2 v 4.50

		Even if you're just using OS/2 v 4.0 with a recent FixPak, and
		the installer has provided a hibernation environment for you,
		it's outdated anyway. The "contrib" directory in this package
		contains a TRUEMODE.450 bundle that will create or update the
		hibernation environment. Please note that your \OS2LDR will
		get overwritten with a special unofficial edition from IBM,
		and it will place certain restrictions:

			1. This OS2LDR has to be retained even if a newer one
			   from FixPak overrides it.
			2. If you have more than 64 megabytes of RAM installed
			   but OS/2 reports 64, look for a loader patch
			   (PATCHLDR.ZIP).
			3. Some day this loader may become outdated, failing
			   to load newer kernels, and then the hibernation
			   will be unusable once again.

   3.4. Modifications to CONFIG.SYS

	To enable the hibernation, add the following line to CONFIG.SYS
        (it doesn't matter where you insert it):

	RUN=C:\OS2\SYSTEM\HYBERSET.EXE

	To customize the hibernation environment, you can add a
        SET HIBEROPT=... option to the CONFIG.SYS. This will be described
        later.

        (Note: there is hYberset and hIberopt... but what is the correct
	spelling for "hibernation", anyway?)

   3.5. OS/2 v 3.0 only - modifying the startup banner files

	The hot keys of recovery choices displayed during ALT+F1 have been
	changed since you installed an OS/2 v 4.0 kernel:

	 C   ->   F2
	 V   ->   F3
	 M   ->   F4

	New keys will be added: F5 for enabling full hardware detection, F6
	for disabling the hardware detection. However, these are not functional
	since snooper files (*.SNP) are required for them.

        To review these keymaps, edit the \OS2\BOOT\ALTF1TOP.SCR file. Make
        sure to clear its read-only attribute.

   3.6. Rebooting

	Now, if you have considered a backdoor for the case of boot failure,
	reboot your system and get to the PM.

4. Usage

   For the beginning, there is nothing simpler than issuing

   HYBERNAT

   from the command line. If it ran fine, the rest is self-explaining.
   Now, for a more complicated usage:

   4.1. HYBERNAT.EXE parameters

        The parameters may be specified with "/" or "-" in front of them. If
        the parameter requires a value, it may be passed with or without a
        preceding space. To encapsulate spaces, surround the parameter with
        quotes (e.g. /t"c:\tools\arj.exe a test"). All parameters must be
        separated with spaces.

        The HIBEROPT environment variable may contain any of these parameters.
        The command line parameters override the ones supplied in HIBEROPT,
	but there is no way to disable a HIBEROPT parameter from the
	command line.

	General-purpose parameters:

	     /i = ignore check for patched OS2LDR on non-FAT partitions.
                  Also, bypasses the verification for absence of write-mode
                  files for /s option. This parameter is DANGEROUS, be sure
                  that you know what you are doing when using it.

	     /s = "fast boot" mode. If there is absolutely no write
                  activities at the moment, then a "permanent" hibernation file
                  will be created to boot from on each subsequent power-on.
                  Even if OS/2 traps, on the next reboot you will be brought
                  to the last point of hibernation. You can refresh the
                  hibernation file by re-running HYBERNAT /s, and disable it
                  by deleting \SWAPPER2.DAT.

                  The conditions for /s (i.e. no files open for writing and
                  empty swap file) can hardly be achieved, but I was able to
                  build a custom PM/WPS setup of OS/2 v 3.0 where it worked.
                  If you ran out of luck and need a list of files, *.RC or
                  CONFIG.SYS for such minimal setup, don't hesitate to
                  contact me.

	     /r = reboot when hibernation is done.

	     /p = "page-out" mode: place all swappable RAM to the system
		  swap file, then hibernate.

            /u1 = specify a pre-hibernation user hook. The hook can be used to
                  check the conditions for hibernation and/or perform some
                  custom cleanup.

                  The hook must not start any background processes for which
                  it is not aware of. The hook must not be a batch file (to
                  run a batch file, set /u1"cmd /c mybatch.cmd"). The hook may
                  be a DOS or OS/2 program, but not a Windows or PM program.

                  If the hook returns a non-zero errorlevel, then the
                  hibernation is aborted.

                  When it is launched, the hook may observe and/or modify the
                  startup files created for dedicated session (see the next
                  section for a discussion of it).

            /u2 = specify a post-restore user hook. This is to revert the
                  action of /u1 hook. The same rules as with /u1 apply here,
                  but there are some specific points:

		    - If /u1 never ran (or returned a non-zero errorlevel),
                      then the /u2 hook is not launched.
                    - The errorlevel for this hook is not verified.
                    - Background processes may be started if you're sure that
                      you won't attempt hibernation again until they finish.

        Trapdoor/dedicated session parameters:

      /t[<xxx>] = Indicate trapdoor mode. <xxx> is an optional value that
                  tells to create a DOS environment. If it is not specified,
                  then a generic trapdoor is started (this is only useful
                  in conjuction with /b).

        /b<xxx> = Specify the trapdoor invocation point:
                  - A drive specification (e.g. C:) tells to invoke the boot
                    sector of this drive, possibly launching the associated
                    OS.
                  - A filename specification (e.g. E:\MISC\DOSBOOT.DAT) means
                    that the boot sector (or an MBR snapshot) will be taken
                    from this file. Such files can be created with Norton
                    Utilities or similar tools, but it is out of scope of this
                    document. Only 512 bytes are read.
                  - A directory specification (e.g. C:\WARPDOS) is for
                    specifying an alternative location for the IBM DOS files
                    supplied in TRUEMODE bundle. The default is C:\OS2\SYSTEM
                    (note the C:, as the dedicated session still requires a
                    C: FAT16 primary partition).

             /c = Prevent from removing OS/2's \CONFIG.SYS and \AUTOEXEC.BAT
                  and replacing them with DOS ones. /c is particularly useful
                  together with /t<xxx> and is recommended if you run
                  multiple systems from the FAT partition.

	/w<xxx> = Work directory for the dedicated DOS session (/t<xxx>). Has
                  no effect if /t (without parameters) is given.

	/n<xxx> = display "Starting <xxx>..." when hibernating.

   4.2. Dedicated DOS sessions

	These ones are a specific feature, worth much more than a couple
	of help pages and paragraphs in documentation. To start one in
	OS/2 v 4.xx, you may just utilize the GUI since OS/2 v 4.xx WPS
	allows you to create "Dedicated session" objects for programs.
	
	Running a dedicated session manually is not much harder but will
	require typing certain additional parameters to HYBERNAT.EXE:
	
	HYBERNAT /t"c:\games\runme.bat" /n"Hot action game" /w"c:\games"
	
	In this example, a batch file is run, and the reboot is invoked
	automatically (/r is not required). When the batch file exits,
	you are brought to OS/2.

        You may see a snappy "Warp" screen while loading the application.
        It is there to mask the CONFIG.SYS startup, don't panic.

   4.3. Configuring the dedicated session

	The CONFIG.DOS and AUTOEXEC.DOS (found in \OS2\SYSTEM of your boot
        drive can be used to set up the DOS environment. For some reasons,
        they are renamed to \CONFIG.SYS and \AUTOEXEC.BAT by HYBERNAT.EXE,
        this makes some dual-boot programs mad (e.g. System Commander).
        The /c option is a workaround.

        If your OS/2 startup drive is not C: FAT16, then the things get
        a bit harder. If there is no C: FAT16 primary volume, it means that
        dedicated sessions are not usable for you. If there is one, you
        need to carry out the following steps:

        1. Create a directory for the DOS environment (e.g. C:\WARPDOS).
        2. Move the following files from \OS2\SYSTEM to it:

	   IBMBIO.COM
   	   IBMDOS.COM
	   COMMAND.COM
	   EMM386.EXE
	   SHARE.EXE
	   SHELL.COM
	   HIDE.SYS
	   CDAPP.COM

        3. (Optionally) create CONFIG.DOS and AUTOEXEC.DOS files in your
           \OS2\SYSTEM directory. Templates of CONFIG.SYS and AUTOEXEC.BAT,
           respectively, may be stored there.
        4. Add /bC:\WARPDOS to HIBEROPT.

   4.4. Running other operating systems by means of trapdoor

        To run any OS by means of trapdoor, run HYBERNAT /t /bX:, where X:
        is the target OS drive. You should see an IBM trapdoor logo, and then
        the OS splash screen.

        If the OS boot drive is not mapped to a letter under OS/2, then its
        boot sector has to be saved to a file (using some external tools), and
        it has to be run with HYBERNAT /t /b<filename>.

   4.5. Running Windows 95/98/Millennium Edition in dedicated sessions

	This may be a reasonable question to ask: can Windows 95 programs be
        accessed seamlessly through the dedicated session? While Windows 95 was
        designed to run from its own MS-DOS v 7.0, there were patches to run
        it from Caldera OpenDOS, et al. I haven't tested any of them, nor do
        I have Windows 95 anywhere. Of course, Windows 95 will run in the
        ordinary trapdoor (without the convenience of selecting a particular
        Win95 application right from WPS).

5. Troubleshooting

   5.1. TVFS

	Even if fix for file system shutdown is applied, there is [at least]
	one file system that can't be handled this way: TVFS. Unless you are
	using TVFS for mission-critical daemons, you can take it out
	efficiently with the following hook:

	SET HIBEROPT=/u1"c:\os2\tvfs\tvkill" /u2"cmd /c tvfsinit"

        TVFSINIT.CMD follows:

	@echo off
	c:
	cd\os2\tvfs
	set TVFS_RESTORE_CMD=C:\OS2\TVFS\TVFS_RST.CMD
	tvctl.exe -p -w -r
	tvrestor
	
	All applications accessing files on a TVFS volume will go into
	undetermined state for the time between TVKILL is issued and the
	system is finally suspended by HYBERNAT (we took the effort to reduce
        this time to a minimum by freezing the system as soon as possible
        after the /u1 hook finishes).

        The second critical point is when the system is released but the /u2
        hook is not yet launched. That's why daemon processes running with
        open files on TVFS may not survive.

   5.2. LVM

	This toolkit has been briefly tested with LVM from Warp Server for
	e-business. Just as HPFS.IFS, the JFS.IFS does not require any patches
        to FSD shutdown in kernel, but nothing breaks if the patch is applied.

   5.3. System Commander

        The "MultiFAT" setup of System Commander requires /c to be present in
        HIBEROPT. This will preserve OS/2's CONFIG.SYS and AUTOEXEC.BAT from
        overwriting with dedicated session ones in the SC MultiFAT repository.

   5.4. Possible reasons for HYBERNAT.EXE failing to run:

	- Disk space: the free space on disk C: has to be capable to keep
	  the hibernation file (\SWAPPER2.DAT), which is equal to the amount
	  of physical RAM.

        - Fragmentation of OS/2 boot partition.

	- Conflicting drivers: in very unlucky cases, hibernation may fail
	  consistently, until a reboot is performed. The reason is unknown,
	  since this situation is very unfrequent and has not been
          investigated yet.

	- Network connections. There is a plenty of ones, and I'm not able to
	  test all kinds of networks. LAN0 and PPP0 do not compromise the
	  hibernation (but well compromise the data being sent over them).

        - Large memory configurations. HYBERNAT.EXE reported low memory on a
          96M system, possibly because it failed to arrange the physical memory
          mapping in this particular case.

   5.5. Possible reasons for the system failing to restore:

        - OS/2 startup volume ends beyond the 8G barrier. The hibernation is
          questionable in this case.

	- EXT2FLT.FLT, if installed with the /A switch, results in a broken
	  hibernation file.

	- SCSI disk drives. Not tested with SCSI. OS/2 v 4.50 hibernates on
          IDE only.

        - Either of OS2LDR or HYBERLDR has been changed after the hibernation
          was done. Beware such unusual ways of system upgrade, since the
          hibernation file contains structures specific to the kernel version.

        - Ctrl+ESC was pressed when hibernating. The keyboard is not
          intercepted at that time, so be careful.

   5.6. Where it has been tested

	- 486DX2-50/8/770M: OS/2 v 3.0 with XR_M005 and XR_M012 kernels.
	- 5x86-133/32/20G: OS/2 v 3.0 with XR_M012 kernel, OS/2 v 4.0 with
          XR_M012...XR_M015, and kernel postfixes through 14.070b.

	The file systems involved in both cases are FAT16 and HPFS. Other
        FSDs in the systems were Ext2FS, JFS, TVFS and NETWKSTA.200.

6. Technical background

   6.1. OS2KRNL

	The hibernation process is accomplished by issuing the DosSysCtl()
	API, which is DOSCALL1.876. The DOSSYSCTL services #11...#19 are
        involved in hibernation process. Particularly, there is an entry (#14)
        to go into "single-task" mode, i.e. freeze all processes/threads
        except the current thread.

        For the main hibernation routine (DosSysCtl #12) the kernel receives a
        list of contiguous absolute disk locations which refer to extents of
        SWAPPER2.DAT. This way, it's possible to perform hibernation anywhere,
        just OS2LDR has to be modified.

        Some diagnostics checks are made. The kernel disallows hibernation if
        one is already in progress (indicated by a special persistent flag in
        kernel), or SET DOS_MODE=NO was found in the master environment (that
        is, specified in CONFIG.SYS).

        Then the physical memory is flushed block-by-block to SWAPPER2.DAT. In
        OS/2 v 4.0, it's done via INT 13h (thus permanently limited to 8G).
        OS/2 v 4.5 hibernates via direct IDE disk access (so it is not limited
        here, but that's why it conflicts with IBM1S506.ADD).

        When this process finishes, a shutdown or reboot occurs, or a dedicated
        session is started by copying its startup stub to 0050:0040 and running
        it in real mode. The 80386 control registers are reinitialized as if
        the machine went through POST.

   6.2. HYBERNAT.EXE

	This program is a wrapper around DosSysCtl, however quite a thick
	wrapper, since dedicated DOS mode is much of its job. Besides checking
	certain conditions, it also performs the dedicated session setup:

		1. It backs up \CONFIG.SYS and \AUTOEXEC.BAT.
		2. It creates the \CONFIG.SYS and \AUTOEXEC.BAT	from
		   \OS2\SYSTEM\*.DOS (if not started with /c).
		3. It inserts shell invocation in these files, yielding 
		   \DOS.CFG and \HYBER.CFG. That are the files used by
		   IBM PC DOS loader in \OS2\SYSTEM.
		4. After return, the files are switched once again. The DOS
		   configuration files in \OS2\SYSTEM are updated with the
		   files from root, that's why they are copied there at step 2.

   6.3. The loaders

	OS2LDR works in cooperation with HYBERLDR. The function of OS2LDR is
        quite simple: to locate the \SWAPPER2.DAT, and if one exists, check
	for its first character being 'H'. If it is, then it's replaced with
	'X' (to prevent looping), a blurb is displayed and the kernel proceeds
	with HYBERLDR. That's correct for OS/2 v 4.0.

	It's somehow different in OS/2 v 4.50, so we need a special OS2LDR
	with code which, for some reason (TCO profits?), does not make it into
	official fixes. OS2LDR now reads up HYBERLDR, performs memory arena
	setup and only then runs HYBERLDR. This difference results in
	necessity to perform cold boot when \OS2\SYSTEM\SHELL.COM is about to
        exit; the OS/2 loader now does some sort of disk access prematurely,
	relying on the environment left from dedicated session, whose
	interrupt handlers are already overwritten.

	An effort to supply additional code to regular OS2LDR has been made
	(see the "experimental" OS2LDR section in the source) but there is
	some sort of communication area in RAM which is hard to track down, so
	it is not operable for now. If you run an open-source development
	facility and wish to continue this project, you're welcome. Just drop
	a note.

	The HYBERLDR file performs disk reads and then jumps right into
        kernel. You can use the kernel debugger to find out where does it go:
        it's _hyberRestart().

   6.4. HYBERSET.EXE

	Looks like a helper used for cleanup of dedicated session environment.
        Nothing worth to tell about.

	It should be noted that this program is not a daemon. It runs for a
	while once invoked from CONFIG.SYS, then finishes.

   6.5. Workplace Shell (PMWP.DLL)

        WPS checks for existence of \OS2\SYSTEM\HYBERNAT.EXE each time you
        are about to set up the parameters of a WPProgram object. If one
	exists, it brings up a "Dedicated DOS/Windows mode" and a "Warning
	message" option.

	"Dedicated mode" objects have PROGTYPE=DOSMODE. When an object of
	this kind is launched, its parameters are passed to HYBERNAT.EXE as
	the dedicated session parameters (/t, /n and /w). Afterwards, PMWP.DLL
	does not care about this process any longer.

	The above facts apply only to OS/2 v 4.xx PMWP.DLL.

   6.6. Dedicated DOS session environment

        IBMBIO.COM is launched directly by the kernel (no boot sectors). There
        is 1.5K startup code in IBMBIO.COM which is read and passed to the
        kernel by HYBERNAT.EXE. References to IBMBIO.COM directory entry are
        passed as well, so when the startup code burns out, it re-reads
        IBMBIO.COM entirely.

        To show up the "Warp" animation screen, HIDE.SYS is launched. The
        animation is stopped by SHELL.COM, which is also a wrapper for
        COMMAND.COM, responsible for rebooting after COMMAND.COM exits.

        There is also CDAPP.COM, a helper application to change the current
        path right from CONFIG.SYS (at least meant to do it in late 1995
        trapdoor shipments, but it is not employed by HYBERNAT.EXE now).

7. Legal notice

   No warranties of any kind are made. In no event shall the author be liable
   for any damage resulting from use or misuse of this product, either direct
   or consequental.

   By using this package, you confirm that you own a valid license for OS/2
   Warp 4, Warp 4 Convenience Package or Workspace on-Demand. Use of this
   package indicates your acceptance of these terms and conditions.

   OS/2 and Workspace on-Demand are trademarks of IBM Corp.
   Windows and Windows NT are trademarks of Microsoft Corp.
   Other trademarks belong to their respective owners.

8. Contacting the author

   Mail any suggestions to: Andrew Belov <andrew_belov@newmail.ru>.

   Any improvements to this toolkit, most importantly, a decent installation
   script (REXX/WarpIN/etc.), are welcome.

   $Id: README.TXT,v 1.11 2001/08/22 11:33:37 root Exp $
