OS/2 2.0 CONSIDERATIONS
by Timothy F. Sipples
Internet: sip1@ellis.uchicago.edu
May 19, 1992

[These notes are not part of the original Slim 1.10a package.]

Slim 1.10a appears to work correctly in OS/2 2.0 emulated DOS sessions.
(And Slim 1.10a undoubtedly works correctly in "specific DOS versions"
running in OS/2 2.0 virtual machines.)  However, testing has been
cursory, and I offer no guarantees that Slim will perform perfectly
in all situations.  As always with DOS on-the-fly disk compression
schemes, use at your own risk.

Here are some considerations on getting the most out of Slim in your
OS/2 2.0 environment.  Slim should serve fairly well until native OS/2
on-the-fly disk compression software arrives (e.g. the forthcoming
Stacker for OS/2).

Slim does not appear to LOADHIGH in DOS sessions.  Thus, it will
require roughly 72K of conventional memory.  If needed, conventional
memory can be freed in several ways including turning DOS_UMB on and
switching VIDEO_MODE_RESTRICTION to CGA.  (Both are in the DOS Settings
section of any DOS program object's notebook settings.)  Loading DOS
TSRs before setting any environment variables can also help cut
conventional memory consumption slightly.  Loading TSRs and device
drivers HIGH can help.  DOS itself can be loaded HIGH.  For information
on these issues consult either DOS 5.0 references or OS/2 2.0 DOS-
related documentation.

SLIM ON may be placed in your AUTOEXEC.BAT file as the accompanying
documentation suggests.  However, if you want to turn SLIM ON only for
certain DOS programs, create a batch file to start your application with
SLIM ON preceeding the name of the application.  Modify your DOS
program object(s) to start the batch file instead of starting the
application directly.

One reason you may not want to put SLIM ON in your AUTOEXEC.BAT file
is because, while Win-OS/2 does work with Slim in limited testing,
repeated error messages about "share violations" will occur.  It is best
not to use SLIM ON with Win-OS/2.

Slim does not include on-the-fly compression of new or rewritten files.
Hence, periodically you may wish to run Slim to compress batches of
files.  OS/2 2.0 provides several ways to automate this procedure and
make it more convenient.  One obvious benefit is that Slim can run in
the background while you work on other tasks.  Also, REXX and/or the
FOR command (see the online Command Reference and the REXX Reference,
both in the Information folder) can be used to create scripts to auto-
matically compress those files which have their archive attribute set
a certain way (for example, to compress those files that haven't been
backed up), or to compress those files which were created or revised
after a certain date.  The Alarms applet (in OS/2 System -> Productivity)
can be used to automatically run daily Slim compression runs, for
example, with a bit of creative REXX and/or batch scripting.  A BBS
operator could automatically run Slim compression on a batch of messages
that has just come in from his network feed.  I leave the implementation
up to the reader -- the possibilities are endless.

Since Slim is a DOS TSR, OS/2 programs will not have access to Slim
compressed files.  Do not attempt to compress OS/2 executables, DLLs,
and other critical files.  Moreover, you will likely not want to
Slim compress data files you expect to use frequently with OS/2 programs.

Slim is more convenient than programs such as LZ-EXE, AXE, and PKLite,
which compress DOS executables only.  Slim works with data files and
other types of files just as well.

How Slim interacts with extended attributes has not been tested.

Finally, if you find Slim of value, please contribute the recommended
amount to the publisher as described in the accompanying documentation.