=======================
LOVR 1.14 DOCUMENTATION
=======================



LICENSE AND WARRANTY
--------------------

LOVR copyright 1988, 1989 by Michael E. Devore. All rights
reserved.

The copyright holder licenses you to use, copy, and distribute
LOVR for yourself and others subject to the following four
restrictions:

1. LOVR must be copied and distributed only in its original,
unmodified form. This includes the LOVR program object
module, the LOVR documentation, and all example files.

2. No fee or other compensation can be charged for copying or
distributing the program. The only exceptions are user
groups and incorporated public domain and shareware software
distributors who may charge a handling fee for its
distribution NOT TO EXCEED $8.00 PER COPY. ONLY ONE COPY
PER COMPUTER DISK IS ALLOWED FOR SUCH DISTRIBUTION.

3. LOVR may NOT be distributed in combination with any other
products, software or hardware, without the express written
permission of Michael E. Devore.

4. LOVR is for your personal use only and may NOT be used
for commercial applications. See the PLOVR program
description later in this documentation file if you need to
use a version of LOVR commercially or need a custom version
of LOVR.

There is no warranty of any kind with LOVR and the copyright
holder is not liable for any damages of any kind or nature that
may occur due to use of, or inability to use, this software. By
using or distributing LOVR you agree to these terms. If you do
not agree to these terms, you may not use or distribute LOVR.

Although it is the copyright holder's intention to fix any
errors in LOVR and to allow its noncommercial use free of
charge, the copyright holder is NOT LEGALLY OBLIGATED TO DO SO.

This document copyright 1988, 1989 by Michael E. Devore. All
rights reserved.







License and Warranty page 1 of 1





LOVR FILES
---------

Included in the LOVR package should be the following files:

LOVR.OBJ (LOVR linkable object module)
LOVR.DOC (LOVR documentation file, the file you are
reading now)

QBNEST.BAS (QuickBASIC 4.0 example files)
BNEST1.BAS .
BNEST2.BAS .
BNEST3.BAS .
BNEST4.BAS

COW.C (Turbo C example files)
FARM.C .
HORSE.C .
PIG.C .
PIGLET.C
SHEEP.C



































LOVR files page 1 of 1





OVERVIEW
--------

LOVR is an overlay manager for QuickBASIC versions 4.x and all
versions of Turbo C. LOVR has also been sucessfully tested with
assembly language code written using MASM 5.0 and previous
versions. LOVR should work with other languages as well IF the
languages compile to Microsoft Overlay LINKable object modules
and use direct calls to overlay procedures or functions.

In case this is your first exposure to overlays, the following
is a quick overview of what overlay's are, what an overlay
manager is, and why such a program is useful.

Overlays are portions of program code which are loaded from disk
into memory on an as-needed basis.

Use of overlays allows an extremely large program (potentially
several megabytes of code in size) to execute in a much smaller
amount of memory. Code from the program's .EXE file is brought
in from disk (overlaid) only when the program needs it. Since
all overlays share the same memory space, the memory
requirements can be much less than the total code size of the
program. Also, there is no longer a need for the clumsy
chaining or spawning to another file that large QuickBASIC or C
environments frequently require.

There is a tradeoff for these advantages. The tradeoff is the
time and code overhead necessary to read overlays in from disk.
If you make the decision to use overlays with your program, any
timing critical code should not be divided between overlays.
For most applications, though, the relatively small amount of
time it takes to read in an overlay from disk is not important
if transfers to overlays are not overdone or poorly timed.
Constant shuttling between overlays is an exercise guaranteed to
give disappointing results. A little bit of thought will go a
long way towards efficient overlay operation.

LINK.EXE, Microsoft's Overlay Linker included with MS-DOS and
Microsoft languages, versions 3.x and some 2.x versions, allow
creation of overlaid versions of programs. However, LINK only
inserts software interrupts and some overlay information in the
program for an overlay manager to use. LINK does not generate
the actual code that loads the proper overlay from disk and
passes control to it. That is a job for an overlay manager, and
that's where LOVR comes in.

LOVR "manages" the overlays. LOVR loads overlays from disk at
the appropriate time and jumps program execution to the overlay
code.






What is LOVR? page 1 of 1





LOVR SPECIFICATIONS AND REQUIREMENTS
------------------------------------

* LOVR requires an IBM PC or PS/2 microcomputer or close
compatible using MS-DOS or PC-DOS operating system version
2.1 or later. Microsoft's Overlay Linker, version 3.06 or
later, and some versions of Microsoft's Object Linker
versions 3.05 or earlier, must be used to link LOVR.OBJ with
the object modules of a program containing overlays.

* LOVR adds approximately 9K bytes to your program's size when
it is linked in. LOVR will also use a maximum of twenty
bytes of the overlaid program's stack during its operation.

* The object files created by versions of QuickBASIC earlier
than 4.0 abort with an error if a link is attempted with
overlays. Therefore, LOVR will NOT work with versions of
QuickBASIC earlier than 4.0. This is an unfortunate
limitation of the earlier versions of QuickBASIC and not an
error or shortcoming in LOVR.

* Calls to a function or procedure FROM the root code TO
overlay code, or from one overlay to another (INTERoverlay
calls) MUST be direct, that is, not indirectly through a
pointer. This restriction is necessary because Microsoft

LINK can only set up an interrupt invoking the overlay
manager for direct calls in program code. For assembly
language programs this means that interoverlay calls to
procedures must be coded as CALL ADDR, not CALL MEM/REG. For
'C', interoverlay function calls should be directly called,
not called through a pointer to a function. Calls within an
overlay (INTRAoverlay calls), within the root code, or FROM
an overlay TO the root can be made indirectly. QuickBASIC
programs should not be affected by this restriction unless
non-BASIC modules which use indirect calls to overlays are
also linked in.

* Microsoft's Overlay Linker requires the presence of at least
one overlay when linking LOVR.OBJ with a program's object
modules. An attempt to link LOVR.OBJ with a program that
does not have at least one overlay will cause LINK to abort
with several "Unresolved external" errors.

* LOVR has a limit of twelve overlays in a program. More than
twelve overlays will cause LOVR to abort with a "Too many
overlays." error upon startup. PLOVR, the enhanced version
of LOVR, has a limit of 63 overlays -- LINK's current
maximum.








LOVR specifications and requirements page 1 of 2





* LOVR supports calls from one overlay to another (nesting).
Overlays can be nested up to four levels. An attempt to nest
deeper than four overlays will cause LOVR to abort with an
"Overlays nested deeper than 4 levels." error. PLOVR
supports a nesting depth of 32 levels.

* LOVR requires use of the Microsoft LINK default overlay
interrupt 63 (3fh). Do not use the /OVERLAYINTERRUPT or /O
option of LINK to change the overlay manager interrupt.
PLOVR supports changing the default overlay manager interrupt
via the /O option of LINK.

* LOVR WILL work with the /EXEPACK or /E option of LINK, if the
program containing overlays is suitable for using the
/EXEPACK option. LOVR will work with the files packed using
the EXEPACK.EXE utility as well.

* LOVR uses the PATH environment variable when searching for
the overlaid program if it is not in the current directory.
If LOVR attempts to load an overlay and the program
containing that overlay is neither in the current directory
nor in a directory in the PATH environement variable, LOVR
will abort with a "File not found." error.

* After your program has been linked with LOVR.OBJ, do NOT
change the program's name. LOVR attempts to load overlays
from the executable file name assigned during the linking
process. If the file name has been changed, LOVR will abort
with a "File not found" error. To change the name of your
program, you must relink the program using the new name for
your executable file in the link syntax.

























LOVR specifications and requirements page 2 of 2





USING LOVR
----------

To demonstrate how to use LINK and LOVR.OBJ to set up overlays,
a sample QuickBASIC program and a sample Turbo C program are
included in the LOVR package. Although these files perform no
useful function, they do demonstrate both overlay nesting and
parameter passing to another overlay.


QuickBASIC 4.x use

Since QuickBASIC programs need a QuickBASIC library to link
correctly, you must own or have access to QuickBASIC 4.x to try
these example files. No .OBJ files are included due to the
different versions of QuickBASIC 4.x. Compile the source files
with your BC.EXE program. These QuickBASIC source files also
demonstrate how to use COMMON to share variables between more
than one module if one module is in an overlay. If you have
many variables in your COMMONs, you will probably want to
consider using $INCLUDE files to declare the variables.
This will eliminate the need to retype variables in all the
source modules if you make a change, and reduces the chance
of erroneous entry.

Link together the LOVR and QuickBASIC .OBJ files, enclosing in
parentheses the modules you want to be overlays. Make sure that
you use at least one overlay or LINK will return an unresolved
externals error. If you link the example object files together
like this:

link lovr+qbnest+(bnest1+bnest2+bnest3)+(bnest4),qbnest;

a main .EXE file called QBNEST.EXE will be created. This
QBNEST.EXE file will contain the root .EXE file QBNEST comprised
of the code of the LOVR and QBNEST object modules and will also
contain two overlay files appended to the root .EXE file. One
overlay file will contain the code of the BNEST1, BNEST2, and
BNEST3 modules, the other will contain the code of the BNEST4
module.

The .EXE file created is a standard .EXE file. Type QBNEST at
the DOS prompt, and the program will begin to run. As program
code is needed from an overlay, that overlay is loaded from disk
by the LOVR code if it is not already loaded, and program
execution continues. You may be able to see the program stop
running when an overlay is being loaded, depending upon the
speed of your disk and whether or not you are using disk caching
software.







Using LOVR page 1 of 5





The amount of memory required to load the QBNEST.EXE file you
created, or any file created by LINK using overlays, is equal to
the size of the root file (including LOVR.OBJ code) plus the
size of the largest overlay file plus any program overhead.
This brings up an important point. There is no advantage to
only using one overlay in a program since space must be
allocated for it in memory during program execution anyway.
There is only the disadvantage of the overlay overhead. In
other words, while the link commands:

link lovr+qbnest+(bnest1)+bnest2+bnest3+bnest4,qbnest;

link /e lovr+qbnest+(bnest1+bnest2+bnest3+bnest4),qbnest;

link lovr+qbnest+bnest1+(bnest2+bnest3)+bnest4,qbnest;

are all valid, there is no useful purpose served by linking
overlays in this fashion. Two or more overlay files in the link
command is the way to go.

A more appropriate example of linking using overlays would be:

link /exepack lovr+qbnest+(bnest1)+(bnest2)+(bnest4)+bnest3,
qbnest;

Here there will be three overlay files containing the code of,
respectively, BNEST1, BNEST2, and BNEST4, and a root file
containing the LOVR, QBNEST and BNEST3 code. Note that the link
syntax includes the LINK /EXEPACK option. The /EXEPACK or /E
option of Microsoft's Overlay Linker may successfully be used
with LOVR.OBJ for those programs suitable for the option.

The only overlay combination not allowed by LOVR is one where
the LOVR or root (in this case QBNEST) object modules are linked
as an overlay. LOVR and QBNEST contain the start up code which
must be in loaded in memory during the beginning of the
program's execution.

To really stretch LOVR to its limits, link each of the BNEST
modules in a separate overlay. This forces LOVR to nest
overlays to its four level maximum.

To use your own QuickBASIC 4.x programs with overlays you should
compile the files using BC.EXE. Overlays will not work with the
runtime file BRUNxx.EXE so the /O option must be used to compile
QuickBASIC 4.x programs.










Using LOVR page 2 of 5





Turbo C Use

To use the Turbo C example files, you need to have a C compiler
compatible with the Turbo C source files COW.C, FARM.C, HORSE.C,
PIG.C, PIGLET.C, and SHEEP.C. No .OBJ files are included due to
the many different versions of C compilers available; object
modules for C are usually compiler version specific. Compile
the source files with your own compiler.

Link together the LOVR and Turbo C .OBJ files, enclosing in
parentheses the modules you want to be overlays. Make sure that
you use at least one overlay or LINK will return an unresolved
externals error. If you link the example object files together
like this:

link lovr+c0m+farm+(horse+piglet)+(cow+pig+sheep),farm,nul,
emu+mathm+cm;

a main .EXE file called FARM.EXE will be created. This FARM.EXE
file will contain the root .EXE file FARM comprised of the code
of the LOVR, C0M, and FARM object modules and will also contain
two overlay files appended to the root .EXE file. One overlay
file will contain the code of the HORSE and PIGLET modules, the
other will contain the code of the COW, PIG, and SHEEP modules.
Although the medium memory model was used for this example, the
large and huge models (with the corresponding C0L, MATHL,
and CL or C0H, MATHH, and CH object files) should work
identically if the source code is recompiled.

Type FARM at the command line, and the program will begin
to run. You may also type FARM MACDONALD to see the command
line argument in use. As program code is needed from an
overlay, that overlay is loaded from disk if necessary, and
program execution continues. You may be able to see the program
stop running when an overlay is being loaded, depending upon the
speed of your disk and whether or not you are using disk caching
software. Remember, you must use Microsoft's LINK when linking
this or any other Turbo C program for use with LOVR. The copy
of TLINK included with Turbo C does not support overlays.

















Using LOVR page 3 of 5





The amount of memory required to load the FARM.EXE file you
created, or any file created by Microsoft's Overlay Linker using
overlays, is equal to the size of the root file (including LOVR)
plus the size of the largest overlay file plus any program
overhead. There is no advantage to only using one overlay in a
program since space must be allocated for it in memory during
program execution anyway. There is only the disadvantage of the
overlay overhead. In other words, while the link commands:


link lovr+c0m+farm+(horse)+piglet+cow+pig+sheep,farm,nul,
emu+mathm+cm;

link lovr+c0m+farm+(horse+piglet+cow+pig+sheep),farm,nul,
emu+mathm+cm;

link /e lovr+c0m+farm+horse+(piglet+cow)+pig+sheep,farm,
nul,emu+mathm+cm;

are all valid, there is no useful purpose served by linking
overlays in this fashion. Two or more overlay files in the link
command is the way to go.

A more appropriate example of linking using overlays would be:

link lovr+c0m+farm+(horse)+(piglet+cow)+(pig)+sheep,farm,
nul,emu+mathm+cm;

Here there will be three overlay files containing the code of,
respectively, HORSE; PIGLET and COW; and PIG, and a root file
containing the LOVR, C0M, FARM, and SHEEP code.

The only overlay combination not allowed by LOVR is one where
the LOVR or root (in this case C0M and FARM) object modules are
linked as an overlay. LOVR, C0M, and FARM contain the start up
code which must be in loaded in memory during the beginning of
the program's execution.


QuickBASIC 4.x and Turbo C Use

Feel free to try any permutation of overlays allowed by these
examples. LOVR should work with any of them as long as you stay
within the restrictions already outlined. It is especially
important to remember not to put the initial entry code or
LOVR.OBJ in an overlay. The start up code must be in memory
when the program is first loaded, i.e. in the root code.









Using LOVR page 4 of 5





You may have noticed that these example files are all small
enough to fit into memory without overlays. You may even be
asking yourself how you really know that LOVR is bringing the
overlays in as needed instead of sneaking everything in at once?
In fact, how do you know that LOVR is using the overlay manager
interrupt at all?

First, you can try running a file linked with overlays without
linking in LOVR.OBJ. If you do this your computer will probably
lock up and need to be turned off or reset before it can be used
again. This is because your program is using interrupt 63 which
LOVR has not initialized to point to code that manages the
overlays. Your program tries to transfer control to whatever
random address happens to be at the memory location that
corresponds to the address at interrupt 63, leading to
unpredictable results. This is also known as a "thin air"
transfer.

The second test you can do is transfer your overlaid program
.EXE file to a floppy disk and disable any disk caching. Now
run LOVR off of the floppy disk drive. You should see the
floppy disk drive light come on during execution of the example
program as overlays are loaded from disk. For maximum effect
you may want to link your program using as many overlays as
possible, up to the maximum of twelve.

It is important to understand how the use of overlays can affect
a program's performance. Time critical code should not be
divided between two overlays. Depending upon the speed of the
disk drive used and the size of the overlay file, the time to
load each overlay from disk can be several seconds. Extremely
time critical code should also not be divided the root code and
an overlay. The execution time overhead of the overlay manager
code can range from several microseconds up to a few
milliseconds depending upon the type of machine used to run the
overlaid program.

There is NO time penalty involved in calling routines FROM a
loaded overlay TO the root code or from one code module to
another WITHIN the same overlay file. There IS a time penalty
in calling routines FROM the root code TO an overlay file. This
time penalty will range from several microseconds with an
already loaded overlay file on a fast computer to several
seconds with an overlay file that needs to be loaded on a
computer with a slow disk drive.











Using LOVR page 5 of 5






PLOVR -- An Enhanced Commercial Version of LOVR
-----------------------------------------------

If you wish to sell a program that uses LOVR.OBJ to operate, or
if you just want a more powerful version of LOVR, an enhanced
version of LOVR called PLOVR can be purchased for $50. You may
reduce this amount by five dollars (to $45.00) if you send me
the name and location of the bulletin board, software
distributor, or place where you received your copy of LOVR. If
someone else gave you the copy of LOVR, ask him or her where
they got it from. The reason for the $5.00 discount is that
this information is valuable to me in determining distribution
strategies.

PLOVR adds the following three enhancements to LOVR:

1. PLOVR allows up to the Microsoft LINK maximum of 63
overlays.

2. The depth that overlays can nest to is increased to 32
levels with PLOVR.

3. PLOVR works with any overlay interrupt specified by the
/O or /OVERLAYINTERRUPT option of LINK.

In addition, the PLOVR package includes a smaller copy of
PLOVR.OBJ called SPLOVR.OBJ, which takes up 5K of program space
in the root code, instead of 9K. The trade-off for the decrease
in space is an occasional small increase in time to load an
overlay from disk in some circumstances, but SPLOVR can be
useful for those running close to the memory space limit even
with overlays.

PLOVR also dispenses with the runtime copyright notice. This
removal of the runtime copyright notice does not suggest, and
should not be taken to suggest, that PLOVR is not copyrighted.
A potentially distracting message is simply not displayed.

A small printed manual is provided with PLOVR for your
convenience.
















PLOVR page 1 of 2





For those with particular needs, there are customized or special
versions of PLOVR available. One version of PLOVR allows a user
to link in his or her own custom error-handler if a DOS error
occurs inside of the overlay manager. There is no extra charge
for a customized change to the standard version of PLOVR IF the
change is deemed to have potential use for other PLOVR users and
is not too major. Very specialized or large changes will cost
more than the standard PLOVR version. Please contact me if you
require a special version of PLOVR.

No royalties are charged for use of PLOVR. This means that you
need only purchase a single version of PLOVR for use with your
program no matter how many copies of your program you
distribute. Purchase of PLOVR entitles the purchaser to
telephone support. I reserve the right to require that all
calls be at the purchaser's expense.

Note that purchase of PLOVR is MANDATORY if you wish to use a
version of LOVR for distribution with a commercial or
potentially commercial application -- including programs
distributed as shareware. PLOVR is the only version of the
overlay manager permitted for use with such applications.

To purchase PLOVR send $50.00 in US dollars -- $45.00 if you
include a description of where you heard of PLOVR -- by check or
money order with your shipping address to:

Michael E. Devore
Devore Software & Consulting
403 West Charles
Champaign, IL 61820

Please state your preference for either 5 1/4 or 3 1/2 inch
diskettes.

All information contained herein, including the cost of PLOVR,
is subject to change without notice.

PLOVR copyright 1988,1989 by Michael E. Devore

















PLOVR page 2 of 2





TROUBLE-SHOOTING
----------------

Check to make sure that you have compiled your program properly.
QuickBASIC users should compile source files outside of the
QuickBASIC integrated environment with BC.EXE using the /O
option.

Turbo C and MASM users must compile their source files using a
large or far code memory model. For MASM versions prior to
5.0 this means that overlay procedures called from the root
or another overlay must be declared FAR.

Use a recent version of Microsoft's Overlay Linker when linking
overlays for LOVR. LOVR was tested with Microsoft LINK versions
3.05, 3.06, 3.60, 3.61, 3.64, and 3.69. 2.x versions of LINK
may not work properly. TLINK, PLINK or other proprietary
linkers will not work with LOVR. In addition, if you experience
problems with LOVR, try linking with a different version of
Microsoft's Overlay Linker -- at least one version of the linker
has an error that causes improper overlay operation.

Check your link syntax, making sure that neither LOVR nor the
initial entry or main program module is in an overlay, and that
you are not exceeding twelve overlay files or nesting overlays
deeper than four levels.

Carefully read the SPECIFICATIONS AND REQUIREMENTS sections to
make sure that you are using the LOVR programs in accordance
with their operating requirements. One possible mistake for
those using LOVR with 'C' or assembly language is to indirectly
call a function or procedure in one overlay from another or from
the root to an overlay. Microsoft LINK requires direct calls to
overlay procedures for it to correctly set up the overlay
manager interrupts.

If you are sure that you are compiling and linking properly and
operating LOVR within its specifications and requirements, make
sure that the error is not in your program. If memory size
allows, compile your program without overlays and test it. If
the size of your program is too large for all of it to fit in
memory, try to compile only the code that is giving you problems
and see if it works correctly without overlays.













Trouble-shooting page 1 of 2





If your program still fails after you have eliminated all
suspects except for LOVR, please contact me so I can fix the
problem as soon as possible. However, I will need to know the
circumstances. What error message, if any, does LOVR print?
What version and options of LINK were used? What hardware and
software configuration was your machine running under when the
error occurred? What language was the program written in?

If an error is in LOVR and you are the first person to find the
error, I will send you a free corrected version as soon as it is
available. The corrected version will either be sent by
electronic mail if possible, or regular USPS mail if not. If
you are not the first person to find the error and do not wish
to wait for the corrected version to reach general distribution
channels, you may send $6.00 to cover shipping and handling for
the latest version to the address below.

If you subscribe to either the CompuServe Information Service,
the GEnie Information Service, or the Byte Information Exchange,
you can send me electronic mail at the appropriate e-mail
address below. Barring vacation or unusual circumstances, I
check in to the CIS and GEnie services at least once a week --
usually more frequently -- and BIX at least twice a month. Your
e-mail will be acknowledged as soon as I receive it.

If you do not subscribe to either CompuServe, GEnie, or BIX you
should contact me through USPS mail at the address listed at the
end of this section.

The realities of life and need for income being what they are,
my billable work and support of my commercial software has
priority over fixes to and questions concerning LOVR. If I have
a full work schedule, a fix or question may take more time to
respond to than either you or I would prefer. This is
unfortunate, but unavoidable.

MAILING ADDRESS:
Michael E. Devore
Devore Software & Consulting
403 West Charles
Champaign, IL 61820

E-MAIL ADDRESSES:
CompuServe 71540,62
GEnie MDEVORE
BIX mdevore










Trouble-shooting page 2 of 2





COMMENTS (Mine and Yours)
-------------------------

LOVR is shareware. No, that does not mean I am going to ask you
for money if you use it regularly. What it means is that LOVR
is a zero dollar registration, copyrighted program with some use
restrictions, most notably that it is only for noncommercial
use. If you use, or plan to use, LOVR.OBJ in one or more
programs over a period of a month or more, then you should
register it. To register, all I ask is that you send me your
home address and the name and location of the bulletin board,
software distributor, or place where you received your copy of
LOVR. If someone else gave you the copy of LOVR, ask him or her
where they got it from. You may send this information to me via
US mail or electronic mail.

I will not put your address on some mailing list or deluge you
with advertisements. The reason I ask for this information is
that it is very valuable to me. Knowing where LOVR is being
distributed, what distribution sites are most successful, and
the address spread of those who frequent the distribution sites
is extremely helpful. Also, the simple presence of feedback
helps just by assuring me that LOVR is a useful tool.

If you feel that you must reward me monetarily or you do not
wish to divulge where you got your copy of LOVR for whatever
reason, then send me a letter with your return address and a
quarter (25 cents) inside as an alternate method to register
LOVR. This will help cover the postage cost of those who send
letters asking for help without sending a self-addressed stamped
envelope and the overhead cost of receiving and answering e-mail
queries.

LOVR should be powerful enough for most programmers needing a
solution to the problem of a personal program that has gotten
too large to fit in available memory. Those programmers or
developers who wish to use this type of overlay manager for a
commercial application should be able to afford the enhanced
PLOVR version. Please note that PLOVR is a retail product: it
is not the registered version of LOVR, nor is it distributed as
shareware.

If you have an idea for an improvement to LOVR, a comment or
question about LOVR, or even a complaint about LOVR, please send
it to either my USPS mailing address or one of the e-mail
addresses below. I am receptive to new ideas and constructive
criticism, regardless of whether or not you are a registered
user.








Comments page 1 of 2





LOVR began life as an offshoot of OVL, current version 3.01,
another linkable overlay manager I wrote that has several bells
and whistles. These extra features include multiple overlay
areas, support for separate overlay files, a utility to allow
use of MS LINK with overlays for Clipper and indirect calls to
overlays, and several other handy features. LOVR is less
powerful than OVL, but it is also less complicated, smaller,
works better with some debuggers, and the commercial version of
LOVR (PLOVR) costs less than the commercial version of OVL
(PROVL).

If you wish a copy of OVL and you have been unsuccessful in
obtaining a copy, you may send $6.00 to cover shipping and
handling for the latest version to the USPS address below.


Michael E. Devore
Devore Software & Consulting
403 West Charles
Champaign, IL 61820

CompuServe 71540,62
GEnie MDEVORE
BIX mdevore


_______
____|__ | (tm)
--| | |-------------------
| ____|__ | Association of
| | |_| Shareware
|__| o | Professionals
-----| | |---------------------
|___|___| MEMBER


This program is produced by a member of the Association of
Shareware Professionals (ASP). ASP wants to make sure that the
shareware principle works for you. If you are unable to resolve
a shareware-related problem with an ASP member by contacting the
member directly, ASP may be able to help. The ASP Ombudsman can
help you resolve a dispute or problem with an ASP member, but
does not provide technical support for members' products. Please
write to the ASP Ombudsman at P.O. Box 5786, Bellevue, WA 98006
or send a Compuserve message via easyplex to ASP Ombudsman
70007,3536.










Comments page 2 of 2