home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
MISC
/
DORMAN27.ZIP
/
OSTSR.ZIP
/
OSTSR.DOC
< prev
Wrap
Text File
|
1995-09-26
|
14KB
|
276 lines
OSTSR version 1.2 Copyright 1994 by Jay Clegg
OSTSR requires OS/2 version 2.1 or higher (Warp) to run properly. Please
read the legal disclaimer at the end of this document before using this
program. DO NOT run OSTSR unless you are running OS/2 2.1 or higher, as
running it from straight DOS will cause the machine to lock up. It has
not been tested with 2.0, and I do not know at this time whether it would
work with that version.
OSTSR is an acronym for OS/2 Time Slice Releaser. It was designed to
allow programs that are Desqview-aware run smoothly and consume less of
the system's time when running under OS/2.
If you are currently using OS2SPEED -or- OS2SPEED combined with TAME21,
this program offers a speed/size enhancement over the capabilities of
these two programs. If you are using either of these programs, remove
them before using this one. You do not need both.
OSTSR is, quite simply, a DOS TSR that, when it is run in an OS/2 2.x DOS
session, will convert Desqview time-slices to OS/2 timeslices
(technically, DV-PAUSEs are intercepted and converted to DOSSLEEP calls).
Desqview-aware programs will typically consume FAR less CPU time when
this program is running. Instead of having a high (up to 100%) CPU
utilization all the time, OSTSR will cut CPU utilization for most
DV-aware programs to below 50%, and as low as 0% in some situations. The
exact amount depends on OSTSR's settings, the speed of the machine, and
how much work the DV-aware program is doing at any particular time.
OSTSR works by fooling DV-aware programs into thinking that they are
running under Desqview. When such a program makes a request to return
the rest of its timeslice to Desqview, the call is intercepted by OSTSR
and is turned into a similar request to OS/2.
OSTSR has been tested and is known to work very well with the latest
versions of the following programs:
Wildcat! TXZM
COMMO DSZ
Qedit SHEZ
List SLMR/OLX
Various BBS programs/utilities
...and should work with any DV-aware program. It will be ignored and
have NO effect on non-DV-aware programs. OSTSR will work in full-screen,
windowed, and minimized sessions. OSTSR 1.2 takes only 336 bytes from a
DOS session, and may be loaded into high memory.
OSTSR allows the user to specify the amount of time to give back to OS/2
when a DV-aware program relenquishes it's time slice. The command line
option allows settings from 0 to 65535 milliseconds. The actual amount of
time taken from the application may vary, and is ultimately determined by
OS/2's scheduler. While this limits the actual amount of tweeking a
person can do using this program, it generally insures that things run
smoothly no matter what option you select. Experimentation is the key to
determining what setting is best for your system. On tests that I and
others have conducted, a setting of 2 or 3 seems to work best for almost
any DV-aware program, although you may find a lower or higher setting
works better for you. Note that a setting of 0 milliseconds does little
for overall system performance, but should (I haven't been able to
confirm this) give up the rest of a timeslice *if* another thread is
running which has a higher priority. (Under OS/2 Warp, a setting of 1
seems to be equivalent to a setting of 0 under OS/2 2.1 and vice-versa.
Apperently, IBM swapped these values in this version of OS/2)
For starters, try a setting of 3, then go up or down to find what works
best for you. If you are running Wildcat! or other DV-aware
communications programs, try a setting of 2 first, if that causes
problems, try a setting of 1 (or 0 if running Warp).
OSTSR has a "monitor" mode that displays two indicators when a DV-aware
program is running. They are very useful for determining which programs
are DV-aware, and for gaugeing the impact of OSTSR. When in "monitor"
mode, the indicators are displayed in the upper left-hand corner of the
screen or window that it is running in. The first one is a smiley face,
which appears when OS/2 has taken over from the application via OSTSR.
(i.e. when the program gives up it's time-slice, OSTSR displays the
smiley, and when OS/2 returns to the program, the smiley is erased.) The
character to the right of the is a "twirly-bar" which moves one "notch"
every time OSTSR returns part of a timeslice to OS/2.
Generally, the more the smiley is displayed, the better for total system
performance.
It should be noted that these indicators will only be displayed if you
are running a program that releases time-slices.
Once you have "tweeked" your system, disable the monitor mode. The
monitor mode does impact on performance itself (particularly for dos apps
that a run in a window), and should only be used for testing purposes.
New in this version is a "fix" for the problems many have experienced
running Borland Pascal Dos-Extended programs in conjunction with OSTSR,
including the Wildcat-related programs WCPACKX and WCC386 and countless
others. These programs would lock up when OSTSR 1.1 was loaded with
DesqView-emulation enabled. This was traced to some "funky" memory
allocation that RTM.EXE (the Pascal run-time module) does when it detects
DesqView. Specifically, I found that if DV was detected it would allocate
one less paragraph than it actually needed for it's DPMI private data
area. This tended to work with real DesqView, but it didn't when used
with OSTSR, and would crash the DOS box after it had overwritten MSB
chain. At least that's what the problem was with the version I played
with.
Anyway, this version of OSTSR has a work-around that attempts to detect
when RTM.EXE is running and correct the allocation amount (by increasing
it by 1 paragraph) before the allocation reaches DOS. It seems to work.
If you think this new feature is giving you trouble with another
program, you can disable it by running (or re-running) OSTSR with the
/F switch.
-------
QuickStart:
Open a Dos session, either windowed or full-screen (full-screen
is recomended for testing in monitor mode). Run OSTSR with these
options:
OSTSR 3 /m
This loads OSTSR resident in your DOS session with a 2 millisecond
release setting, with monitor mode ON.
Now run your Desqview-aware application(s) from this session. If
they are indeed Desqview-aware, you should see the smiley and
twirly-bar in the upper left-hand corner of the screen or window,
indicating that OSTSR is doing it's job.
(NOTE: if IDLE_SENSITIVITY in the settings folder for your DOS
session is set to 100%, OSTSR will not have a positive impact on
performance. If it is set to 100%, change it to 99% or lower)
Try running your DV-aware applications in a window, both with and
without OSTSR loaded, while watching PULSE or another CPU
utilization monitor. This will gauge the impact that OSTSR has on
increasing overall system performance.
REMEMBER: the monitor mode increases CPU activity when in use, so
disable it (run without /m switch) once you're done testing.
-------
Usage:
OSTSR # [/M] [/D] [/F]
where # is a number between 0 and 65535. if # is not specified, a
value of 1 is assumed. /M and /D are optional.
/M enables monitor mode. This should be used for testing only,
as it increases CPU utilization when in use.
/D temporarily disables Desqview emulation. This usually has the
effect that OSTSR will not seem to be present. This switch was
added to allow users to temporarily turn OSTSR 'off'. OSTSR can be
turned back 'on' by re-running it without the /D switch. Note that
if the program requests a time-slice release, it will still be sent
to OS/2, this simply disables the function that 'fools' other
programs into thinking they are running under DesqView.
/F Disables memory allocation fix. See above. Use this switch only
if you think that this fix interfering with another program. This
switch will probably never be needed, but if you find a program or
situation that does require this switch to work, please report it
to me.
Examples:
OSTSR (running OSTSR with no parameters
specifies a default 2 ms DOSSLEEP,
with no indicators.)
OSTSR 3 ( 3 millisecond DOSSLEEP, no
indicators)
OSTSR 2 /m ( 2 millisecond DOSSLEEP, with
"monitor" indicators turned on)
Running OSTSR when it is already installed in memory will change the
values of the already running copy. This allows you to change its
settings "on-the-fly". If you do not specify otherwise, it will
default to: Monitor Mode OFF, 2 ms release, DV-faking ON.
You may wish to put OSTSR somewhere in your path so that you can use it
from any directory. However, most users will find it easiest to load
OSTSR via their AUTOEXEC.BAT, so that it will be automatically loaded for
each DOS session on startup.
-------
OSTSR is copyrighted free-ware, which means you can use it as you see
fit (free of charge) as long as you do not modify the program in any
way. Please do not distribute it without this documentation file.
I have tested OSTSR to the best of my ability. However, if you find
any bugs, or programs that cause incompatibilities, I'd appreciate
hearing about them. I can be contacted at the address below, and also
through via the Madmen & Maniacs BBS (USA 706-860-5781, FIDO Netmail
at 1:360/12 , be sure to put return fido address in body of message),
or (preferably) via internet email (jclegg@augusta.net).
Jay Clegg
P.O. Box 204201
Martinez, GA 30907
If OSTSR is useful to you, SEND ME A POSTCARD! It'll encourage me to
continue developing this program. (If you want, send money, that works
even better. <grin>) If you wish to remain anonymous, you can leave
off the return address, but send the card anyway...If possible, send
one that has a picture of the city that you live in.
-------
Warranty: There is no warranty, period.
Full Legalese follows:
DISCLAIMER
Jay Clegg makes no warranty, either express or implied, including but not
limited to implied warranties of merchantability and fitness for a parti-
cular purpose with respect to this software.
IN NO EVENT SHALL JAY CLEGG OR ANY OF HIS ASSOCIATES BE LIABLE FOR ANY
DAMAGES, INCLUDING DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS
INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS
ARISING OUT OF THE USE OF OR INABILITY TO USE THIS PROGRAM, EVEN IF
JAY CLEGG HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES.
Program history: OSTSR
0.1 This version was written in C and was much larger
than the final product. Just a test program to see if it
would work.
0.8 ASM version with time slice indicator. Seperated resident
code from startup code to squeeze resident size to a
minimum. Allowed for specifying DOSSLEEP parameter.
0.9 Beta test. Added TS indicator switch, and allowed for
changing parameters of resident program by reruning the program.
Fixed a few esoteric buglets.
1.0 First public release.
1.1 'Maintenance release'. Added support for converting MS-Windows
time slice releases to OS/2 releases. Some programs (SHEZ)
were calling this instead of the DV call. Added switch to
temporarily disable DesqView emulation (/d), when used,
program will not emulate DV until OSTSR is re-run without
the switch. Some programs (Usurper - game door?) were
trying to use additional DV functions which OSTSR simply
cannot provide, hence, this allows users to temporarily
disable OSTSR and re-enable it when a certain program has
completed. Refined code so that resident size is still 336
bytes, despite additions.
1.2 'Another maintenance release'. Added a workaround that
corrects a problem caused by RTM.EXE when it detects that
DesqView is running. This "feature" in RTM doesn't affect 'Real
DesqView', but caused havoc when using a 'DV-faker' such as the
previous version of OSTSR, or OS2SPEED, or TAME. The exact
reason is rather tenuous, and involves the MCB chain when
allocating from high (conventional) memory. But the workaround
code appears to work, and I've taken steps to assure that it
doesn't interfere with other programs. I did some optimizations
to the code to keep the resident code size down to 336 bytes
(The actual running ISR's are only about 256 bytes!). Also,the
program modifies it's own MCB to reflect the name 'OSTSR'.
1.2i Identical executables to 1.2, but changed the docs to
reflect my new email address.