Dec 242017
Extended/Expanded memory management software.
File XMEM130.ZIP from The Programmer’s Corner in
Category Utilities for DOS and Windows Machines
Extended/Expanded memory management software.
File Name File Size Zip Size Zip Type
XMEM.COM 4482 4034 deflated
XMEM.DOC 39175 11827 deflated
XMEM.NEW 983 482 deflated
XMEM.REG 3952 1270 deflated
XMEM.SYS 5807 4341 deflated

Download File XMEM130.ZIP Here

Contents of the XMEM.DOC file

Designations claimed as trademark appear in initial capital or all capitals

(c) Copyright 1990 F.M. de Monasterio
Licensed Material - All rights reserved

xMEM version 1.30


The xMEM system consists of two programs: (1) XMEM.SYS, an extended-memory
based emulator of expanded memory complying with the LIM specification 3.2
or 4.0, and (2) XMEM.COM, a program to communicate with the device driver.



Several types of addressable memory are found in micro-computers based on
iAPX 80x86 CPUs. In the IBM PC and compatibles, the initial one megabyte
(1 Mb = 1,024 kb) of memory comprises the initial 640 kb of address space
normally used by DOS and by application utilities (space which used to be
called the user arena), and the remaining 384 kb of address space for the
hardware subsystems, and routines of the ROM-BIOS and its extensions. The
addressable RAM of 1,024 kb is known as conventional memory, and its 384-
kb subspace as upper memory blocks (UMBs) or high-DOS memory.

0 kb 640 kb 1024 kb

base top
Conventional UMBs


In the IBM AT and compatibles, which can support a physical address space
larger than than 1,024 kb, additional memory is located above the initial
1 Mb of space, up to a physical address space of 16 Mb in i286 and i386SX
CPUs, and of 4 Gb in i386 CPUs. The additional addressable RAM is called
extended memory (abbreviated as XM throughout this documentation), and is
subdivided into a high memory area (HMA), which is the initial 64 kb area
immediately above the 1-Mb limit, i.e. from 1,024 kb to 1,088 kb, and the
extended memory blocks (EMBs), located from above the physical address at
1,088 kb.

1Mb 16Mb-4Gb

base top
Extended memory
0 kb

Irrespective of the CPU, DOS runs in an 086-compatible mode known as real
mode. In real mode, addressable RAM is seen as consisting of a series of
64-kb chunks called segments, and a memory address consisting of 2 parts:
a 16-bit segment and an associated 16-bit offset (i.e. the byte from 0 to
65,536 where the address is located in the segment). These two parts are
combined to form a 20-bit physical address by shifting the segment bits 4
bits to the left and adding it to the offset. The highest possible 20-bit
number is 1,024 kb which is why this is the maximum space of conventional

In XM, however, the physical addresses have at least 21 significant bits,
so that XM cannot be addressed by the CPU in real mode. To be able to do
so, the CPU has to switch to protected mode. An i286 CPU in such a mode,
for instance, can generate a 24-bit base address that, when combined with
a 16-bit offset, allows the CPU to address 16 Mb of physical memory.


Unlike the above types of RAM, paged or bank-switched memory has no fixed
address, but it can be mapped into the RAM address space in smaller parts
known as pages. A DOS compatible software interface for paged memory was
developed by Lotus, Intel, and Microsoft (LIM), which was termed Expanded
Memory Specification (EMS). This interface is implemented via a software
module, the Expanded Memory Manager (EMM), which controls the allocations
of the EMS pages; four of such 16-kb pages could be accessed at any given
time out of 512 possible EMS pages, resulting in a 64-kb page frame size.
Afterward, Ashton-Tate, Quadram, and AST (AQA) developed another software
interface, the Expanded Memory Specification (EEMS), whose main advantage
was the access up to sixty-four 16-kb pages at a time, i.e., a 1-Mb frame

The original LIM EMS 3.0 specification has been updated twice so far (3.2
and 4.0), while the AQA EEMS standard has enjoyed limited market success.
LIM EMS 4.0 incorporated most of the EEMS enhancements and has become the
primary EM standard. Many current EMS-based applications, however, still
rely on EMS 3.2 functions.

EMS drivers were incorporated in DOS version 4.0; the initial 4.0 drivers
had problems and not all EMS functions were supported (i.e., function 19h
'Get/Set Handle Attribute'). DOS 4.01 uses EMS 4.0 to buffer sectors from
open files (the BUFFERS command in CONFIG.SYS) and directory entries (the
FASTOPEN command); at least early releases of DOS 4.00 do not seem to use
EMS features.


Whereas the original EMS was developed to provide a software interface to
bank-switched memory boards, the EMS implementation is basically hardware
independent. In fact, EM can be obtained via EM-emulating utilities that
swap data between conventional memory and disk storage or extended memory
without the need of EM hardware in i086 or i286 CPU systems. (In i386 CPU
systems, advanced memory management features can be used to emulate EM in
a more powerful fashion.)

The advantage of EM emulation is that it is inexpensive. The disadvantage
is that it is comparatively slow. In terms of compatibility, i086/i286 EM
emulation provides a limited range of EMS support. A bank-switched memory
board, or an i386 EM emulator, for instance, can map one logical EMS page
into more than one physical page at a time (data aliasing). Because disk-
storage or extended-memory emulation only copies memory pages, as opposed
to 'mapping' them into the address space, it cannot support aliasing. EM
emulation of these types cannot provide support for functions designed to
implement rapid task switching by multitasking operating environments via
context mapping or DMA register sets, as well as (at least in the case of
XM-based emulation) preservation of EM across warm boots.



xMEM is an extended memory-based, EM emulator implementing either the EMS
3.2 or (except for the DMA subfunctions 5-8 of function 5Bh, the warmboot
preparation function 5Ch, and the fixed 16-kb size of the pages) EMS 4.0
services in i286-compatible CPU systems with extended memory.

Current versions of xMEM are written to run in real mode rather than 286-
protected mode. The driver uses a BIOS function to move blocks of data to
and from XM. Because such data moves involve switching the CPU from real
to protected mode, and then from protected to real mode, this rudimentary
XM service is somewhat slow. Hence, although the code has been optimized
for speed of execution, the driver is not fast enough to support EM-based
disk caches without a nontrivial speed penalty. Other uses, however, are
well supported by xMEM, including EM-RAM disks such as the xDISK utility.

XMEM.SYS installs the EMM driver in conventional RAM, and then allocates
in extended memory a number of 16-kb EMS pages, a number that depends on
the EM amount requested by the user. Two methods of XM allocation, Top-
Down and Bottom-Up, can be used when installing xMEM; they are described
below (see sections 3.1 and 3.2). EMS pages are logically mapped onto 4
contiguous 16-kb pages of conventional RAM, which occupy 64 kb. The EMM
driver can be disabled or reenabled via the utility XMEM.COM, which also
provides information on the allocation and availability of XM.

A 32-bit CRC is calculated when either xMEM program is executed. If this
check fails, the program execution aborts to DOS. CRC failure indicates
corruption(s) of the code and the program therefore should not be used.


When only EM size is specified (switch /M), memory is allocated starting
from the top physical address of XM to a lower address:

1Mb 16Mb 1Mb 16Mb

base top
free XM free XM

The Top-Down allocation method has been adopted by many relatively recent
XM-based programs and consists of intercepting a BIOS function (interrupt
15h, function 88h) that returns the amount of available XM, so that a new
amount, reflecting the XM usage by the program, is returned.


When both EM size (switch /M) and base address (switch /B) are specified,
memory is allocated from the specified base address to a higher address:

1Mb 16Mb 1Mb 16Mb

base top
free XM free XM

A most notable user of the Bottom-Up allocation method has been VDISK.SYS
(the virtual disk utility bundled with DOS), the method being implemented
in a somewhat circuitous way: After allocating XM starting from the 1-Mb
boundary VDISK saves the base address of the first free XM ("" in figure
above) at a specific location of its resident in conventional memory, and
then points the vector for interrupt 19h (BIOS boot) to a "dummy" routine
in the same resident. Thus, by obtaining the memory segment of interrupt
19h it is possible to obtain the memory segment of the VDISK resident and
to inspect the location containing the address of the first free extended
memory. Subsequent programs using this method have to update the address
to its new value in the actual VDISK header or, if they also revector int
19h, in a fake VDISK header providing XM base data.



Function 88h of interrupt 15h yields the amount of XM that is installed or
available in ATs and PS/2s (except models 25 and 30). xMEM intercepts the
interrupt and returns a value that depends on the method of XM allocation:

[1] In the "Top-Down" method, the amount returned is that between the base
address of the driver and the base address of extended memory (see example
No. 2 below).

[2] In the "Bottom-Up" method, the amount returned is that between the top
address of the driver and the top address of XM (see example No. 3 below).
In this case, any noncontiguous, free XM located below xMEM (due to switch
/B specification) is not reflected in this amount.


Normally this interrupt points to the address of the service to reboot the
system. Upon its installation, VDISK.SYS revectors this interrupt to point
within itself, so that another program can fetch the memory segment of the
VDISK.SYS resident and, from a specific location in the resident, read the
physical address of the first free byte (i.e., bottom) of extended memory.
Such an address is shown underlined in the following DEBUG dump of a 64-kb
VDISK (11000h [stored in a least significant/most significant format]):

X:0000 00 00 1D 0B 00 08 76 00-81 00 01 00 00 00 00 00 ......v.........
X:0010 00 00 56 44 49 53 4B 20-20 56 33 2E 33 28 00 00 ..VDISK V3.3(..
X:0020 00 00 00 00 00 00 00 00-00 60 86 09 00 00 11 7C .........`.....|
~~ ~~ ~~

If the Bottom-Up allocation method was selected (see switch /B below), int
19h is revectored to a fake VDISK header within XMEM.SYS where the updated
physical address of the bottom of extended memory can be found by programs
using the Bottom-Up method of allocation (see examples No.1-3 below). The
following DEBUG dump of the xMEM header shows the fake VDISK header, which
indicates the first free XM at the (hex) physical address of 277000h:

X:0000 00 00 CB 0B 00 80 4C 00-58 00 45 4D 4D 58 58 58 ......L.X.EMMXXX
X:0010 58 30 56 44 49 53 4B 20-20 56 33 2E 33 28 14 04 X0VDISK V3.3(..
X:0020 CB 0B 00 0A 8C 15 95 0C-38 0C 1F 00 00 70 27 10 ........8....p'.
~~ ~~ ~~

Actually, VDISK also saves the base address of XM in a location within the
VDISK code in XM just above the 1-Mb limit. Utilities using the Bottom-Up
method of allocation are supposed to check the two locations (conventional
and extended memory), and use the highest of the two addresses as the base
of XM. Although the pseudo-VDISK header of xMEM does force many utilities
using the Bottom-Up method to start installing at the address given there,
it does not force VDISK.SYS to use this address when being installed after
XMEM.SYS (i.e., VDISK does not use the worst-case value when comparing the
header addresses).


This interrupt points to the EMM device driver. An application program or
driver can then communicate with the EMM directly without DOS intervention
to request an specific EMS function. The EMS 4.0 specification results in
a code nearly twice as large as that of the EMS 3.2 specification for this
interrupt service.

Note that interrupt 67h is not necessarily reserved for LIM EMS. Actually,
other programs also make use of it, including those for some communication
boards, creating conflicts that can be solved only if the non-EMS programs
can be modified to use another interrupt. The xMEM EMM service for int 67h
requires register AH (the high byte of the accumulator) to contain a value
between 64 (40h) and 78 (4Eh; EMS 3.2) or 93 (5Dh; EMS 4.0), corresponding
to the range of valid EMS function numbers; values outside of such a range
abort the interrupt call, placing the error code 132 (84h) in register AH.



XMEM.SYS must be installed via the CONFIG.SYS file on the boot disk:

DEVICE=[d:][\path\]XMEM.SYS [/Mn] [/Bn] [/In] [/Vn] [;comments]

After XMEM.SYS has been installed, XMEM.COM can be executed to review the
XM/EM parameters of the installed driver as well as to disable/(re)enable
the driver's operation. The syntax from the DOS command line is:


where [d:] and [\path\] are optional drive and directory descriptors for
the xMEM files. Executing XMEM.COM results in a data display (described
below). The EMM status (enabled or disabled) can be changed by pressing
the <+> or <-> keys followed by ; press to quit the display
cancelling any status change you may have made. NOTE: Disabling the EMM
does not result in the release of the XM allocated for EM emulation, nor
in the release of intercepted interrupts. (*) Modification of EMM status
is not available in the unregistered copy.



The switches of XMEM.SYS are not case sensitive, and can be given in any
order; each switch, however, must be preceded by a slash [/]:

[/Mn] - Specifies the size of the EMS memory in kbytes; is a decimal
number between 1 and 5 digits. If switch /M is not specified, all of the
available extended memory is converted into EMS. (*) In the unregistered
copy, a maximum of 512 kb, if available, can be converted into EMS.

[/Bn] - Specifies the extended-memory starting address in kb for the
EMS memory. Switch /B is disregarded if switch /M has not been specified
as well. Notice that is not an absolute physical address but rather
an offset added to the base of extended memory (absolute 1,024 kb). For
example, /B1000 specifies the absolute physical address located at 2,024
kb (1,024 + 1,000), i.e., 1,000 kb from the base of the extended memory.
(*) This switch is not available in the unregistered copy.

[/In] - Specifies the hex number of the XM-associated interrupt that
is *not* to be intercepted by the xMEM driver (see above). /I15 denotes
int 15h, and /I19 denotes intt 19h; other numbers are ignored. Only one
of these two interrupts can be excepted from vector interception; switch
/I is provided in case of conflicts with programs using the interrupt in
an unusual manner. (*) This switch is not available in the unregistered

[/Vn] - Specifies the LIM version number of the EMS manager; /V4 denotes
the EMS 4.0, and /V3 denotes the EMS 3.2 specification. If switch /Vn is
not specified, xMEM defaults to EMS 4.0.


Comments, which may be useful in clarifying the xMEM line if CONFIG.SYS,
must be preceded by a semicolon. They are ignored by xMEM.



xMEM must be installed via CONFIG.SYS before any other resident or driver
requiring EMS support. Any drivers using extended memory may be installed
first, if they implement VDISK or int-15h based management allocation, or
after xMEM, provided sufficient extended memory is left available.

During the installation a graphical description of extended memory usage,
and a numerical description of memory configuration are displayed (unless
an error is detected; see below).

Pressing the key before such a display is completed, interrupts the
installation until the abort query is answered by pressing for 'YES',
or or for 'NO':

'XMEM.SYS: key pressed Abort installation? [yN] '

This permits not only a way to abort the installation of xMEM, but also a
way to stop CONFIG.SYS before any subsequent driver scrolls the screen up
before the configuration message can be read.



The following memory allocation errors fail installation of the driver:

Error No.5 - EMS size /M, starting from /B, is greater than XM size
Error No.4 - EMS base /B is beyond upper limit of XM size
Error No.3 - EMS base /B but not size /M was specified
Error No.2 - EMS size /M plus VDISK size are greater than XM size
Error No.1 - EMS size /M is greater than XM size
Error No.0 - XM is not installed or not available

Other conditions failing the installation are described in the messages:

'XMEM.SYS: Needs DOS version 2.0 or later Installation aborted'
'XMEM.SYS: CRC failure (driver corrupted) Installation aborted'
'XMEM.SYS: Needs CPU type 80286 or higher Installation aborted'

If a LIM EMM is found to be already installed, the message is displayed:

'XMEM.SYS: EMM already loaded Abort installation? [yN] '

Under DOS version 3.30 or higher, the aborted driver does not take up any
memory. Other versions do not allow this procedure, however, and a small
segment of xMEM code must be left installed (160 bytes). To preclude any
subsequent DOS use of this code, the device's name that remains installed
is changed from "EMMXXXX0" (the EMS-3.0+ guaranteed driver's name for the
Expanded Memory Manager) to "NUL" (making the driver to be ignored by DOS
since DOS installs its own non-replaceable NUL driver), and the remaining
code is also changed so that an access call returns the "unknown command"
error code.


The following are examples of xMEM installation, all in a system having
2,560 kb of extended memory, and all with a previously installed 64-kb
extended memory VDISK disk. These examples show respective installation
message and memory usage graph as well as the explanations for the data
that are displayed. Notice the limitations of the results listed under
"Memory management" that might help to solve potential memory conflicts
with other extended memory utilities:



Installation display:

Expanded memory requested: 0 kb = default (no /Mn)
Adjusted amount installed: 2496 k = 2560 - 64
Starting physical address: 1088 k = 64 + 1024

LIM EMS 4.0 Manager installed = default (no /Vn)
Extended memory now available: 0 kb = 2560 - (2496 + 64)


base top


Memory management:

A. Interrupt 15h/88h indicates that 64 kb of extended memory are still
available. This is not correct (the 64 kb are being used by VDISK),
reflecting the fact that the int-15h management method consistently
ignores memory allocated using the VDISK method.

B. VDISK header (addresses 2Ch-2Eh) indicates first free memory at the
physical address 380000h (3,584 kb); the value represents the upper
limit of xMEM and that of the memory actually installed, i.e. there
is no available extended memory.

VDISK XXXX:0000 00 00 1D 0B 00 08 76 00-81 00 01 00 00 00 00 00
DUMP: XXXX:0010 00 00 56 44 49 53 4B 20-20 56 33 2E 33 28 00 00
XXXX:0020 00 00 00 00 00 00 00 00-00 60 86 09 00 00 38 7C
~~ ~~ ~~
The int-15h information will result in conflicts if a subsequent utility
attempts to use the supposedly available 64 kb being used by VDISK. The
VDISK information will result in program failure if a subsequent utility
attempts to use the nonexisting memory above the upper limit of xMEM.



Syntax: DEVICE=XMEM.SYS /M1000 /V4

Installation display:

Expanded memory requested: 1000 kb
Adjusted amount installed: 992 kb = (1000 / 16) x 16
Starting physical address: 2592 kb = (2560 - 992) + 1024

LIM EMS 4.0 Manager installed = /V4
Extended memory now available: 1504 kb = 2560 - (992 + 64)
Physical top: 2592 kb, bottom: 1088 kb top: bottom of xMEM
bottom: top of VDISK


base top

available xMEM
vdisk extended memory

Memory management:

A. Interrupt 15h/88h indicates 1,568 kb of 'available' extended memory

B. VDISK header (addresses 2Ch-2Eh) indicates first free memory at the
physical address 110000h (1,088 kb); the value represents the 64 kb
that VDISK is using starting at 1 Mb.

VDISK XXXX:0000 00 00 1D 0B 00 08 76 00-81 00 01 00 00 00 00 00
DUMP: XXXX:0010 00 00 56 44 49 53 4B 20-20 56 33 2E 33 28 00 00
XXXX:0020 00 00 00 00 00 00 00 00-00 60 86 09 00 00 11 7C
~~ ~~ ~~
The available extended memory can be accessed with either method.



Syntax: DEVICE=XMEM.SYS /M500 /B1000 /V3

Installation display:

Expanded memory requested: 500 kb
Adjusted amount installed: 496 kb = (500 / 16) x 16
Starting physical address: 2024 kb* = 1000 + 1024

LIM EMS 3.2 Manager installed = /V3
Extended memory now available: 1060 kb = 2560 - (1000 + 500)
Physical top: 3584 kb, bottom: 2524 kb top: installed memory
bottom: top of xMEM


base top

"hole" xMEM available
vdisk extended memory

Memory management:

A. Interrupt 15h/88h indicates 2,560 kb of available XM (i.e., the top
memory remains the same). This is not correct, as only 1,060 kb are
actually available.

B. VDISK header (addresses 2Ch-2Eh) indicates first free memory at the
physical address 277000h (2,524 kb); this value represents the base
of the accessible extended memory. Notice that the unused extended
memory physically located between 1,088 kb and 2,024 kb ("hole") is
not recognized by either method.

pseudo XXXX:0000 00 00 CB 0B 00 80 4C 00-58 00 45 4D 4D 58 58 58
VDISK XXXX:0010 58 30 56 44 49 53 4B 20-20 56 33 2E 33 28 14 04
DUMP: XXXX:0020 CB 0B 00 0A 8C 15 95 0C-38 0C 1F 00 00 70 27 10
~~ ~~ ~~

The int-15h information will result in conflicts if a subsequent utility
attempts to use the supposedly existing 2,560 kb (of which only 1,060 kb
are actually available). The VDISK information is correct. The hole in
extended memory may be filled in if the base address of installation can
be specified in a subsequent extended memory utility.



Two data panels of the display provided by the utility XMEM.COM deserve
description and explanation.

The top right panel contains several data fields shown below by numbers
in parentheses:

(1) -> LIM EM manager (3.2) ENABLED [????]

(2) -> Expanded memory requested: ???? kb
(3) -> Adjusted amount installed: ???? kb
(4) -> Starting physical address: ???? kb
(5) -> Extended memory available: ???? kb

(6) -> Int 15h ?, 19h ?; VDISK not loaded
Extended memory:
top base

(7) -> xMEM loading ???? kb ???? kb

(8) -> Current data ???? kb ???? kb

(1) This field identifies the EMS versions (3.2 or 4.0), whether the EMM
is ENABLED or DISABLED (any EMM status changes become effective only
after pressing ), and the memory segment where the driver has
been installed.

(2) This field identifies the amount of EMS requested to XMEM.SYS in kb.

(3) This field identifies the amount (16-kb multiples) of EMS in kb that
was actually installed.

(4) This field identifies the physical address of the base of EMS in kb.

(5) This field identifies the amount of available extended memory in kb.

(6) This field identifies whether interrupt 15h and 19h have been hooked
by another utility ('' same vector or '' different vector [as when
XMEM.SYS was installed], or '?' if the interrupt was not intercepted
by xMEM due to the /I switch), and the status of VDISK installation.
If VDISK was installed, also shown is one of the following one-digit

[0] The VDISK driver header was not detected by either xMEM

[1] The VDISK driver header was detected during XMEM.SYS but
not during the XMEM.COM execution (i.e., another utility
has revectored int 19h without setting up a VDISK header
to provide XM installation data).

[2] The VDISK driver header was detected during XMEM.COM but
not during the XMEM.SYS installation (i.e. VDISK.SYS was
installed after XMEM.SYS).

[3] The VDISK driver header was detected during execution of
both xMEM utilities.

(7) This field identifies the physical address in kb of the base and top
of extended memory at the time of XMEM.SYS installation.

(8) This field identifies the current physical address in kb of the base
and top of extended memory.

The bottom panel displays in a graphical manner the allocation of XM for
xMEM ( blocks) and VDISK and other utilities ( blocks). XM allocation
for utilities is based on current information from int 19h and int 15h.

0 Percentage of Extended Memory 100 xMEM

base top Other

1024 kb Absolute Physical Address ???? kb Free




These programs and the documentations (the "software") are the copyrighted
property of FM de Monasterio (the "author"), who provides the software and
licenses its use. Neither the title to nor ownership of this software are
transferred to you by such a license, and both are retained by the author.
All rights are reserved.

The software is user-supported; the enclosed release, although lacking the
options marked by asterisks, is a fully usable program. You may test this
release for (in)compatibilities with your system, but after the testing is
completed you are requested to order a registered release of this software
from the address below.

Alternatively, to continue use of this unregistered copy, send to the same
address a US$5.00 check marked "For Deposit Only," and payable to "Patient
Care Fund, Children's Hospital" of Washington, DC. Unregistered users that
donate to the fund will be allowed to register at half fee, if so desired.

A form to be used to register or upgrade the software is found in the file
XMEM.REG. Refer all inquiries about the software to:

FM de Monasterio
P.O. Box 219
Cabin John, MD 20818-0219

Upon registration you receive a non-exclusive, non-transferable license to
use the software. Two types of license are available:

Single User License:
Upon registration/upgrade you are granted a nontransferable license to use
the software in a single computer at a time. You may transfer the software
physically to another computer provided that the software is then not used
on more than one computer at any time.

Site/10-Computer License:
Upon registration/upgrade you are granted a nontransferable license to use
the software in a single site or a set of sites provided that the software
is not used in more than ten computers at any time and that such computers
are located exclusively within the registered site(s).


Within the same major version: Registered software users can upgrade free
of charge within the same major version (e.g., 2.00 through 2.99).

Outside the same major version: Registered users can upgrade for half the
the license fee for a different version of the software.

To upgrade send a self-addressed stamped diskette mailer with the original
360 kb diskette to the address above, along with the upgrade form.


Limited technical support is provided to registered users. If you discover
a problem, please try to replicate it under the same conditions and, then,
in the absence of other resident programs. (Changes in the order residents
are installed sometimes solve conflicts.) If the problem can be replicated
please write at the address above providing:

- Your name and address.
- Program version number (see the Syntax/Help panel).
- Computer model and configuration, and hardware used.
- A sufficiently detailed description of the problem.
- A list of resident and nonresident programs in use,
and their sequence of loading into memory.

Messages may also be left at: The DC Information Exchange BBS (PCBoard)
---------------------------- (202) 433-6639 (Sysop: Bill Walsh), 2400+


You may distribute this software via magnetic and/or electronic means, but
you are specifically prohibited from:

- Charging fees or asking donations in exchange of or payment
for copies of the software.
- Distributing this software with commercial products without
the written permission from the author.
- Distributing this software via a for-profit organization or
group, either alone or with other software.

The unauthorized copying, decompiling or disassembling of this software is
prohibited; any other use of this software is prohibited without a written
permission in advance from the author.


The author-copyright owner warrants for a period of thirty (30) days from
the date of delivery that, under normal use and without any modification,
the programs substantially conform to the accompanying specifications and
that the documentation is substantially complete and contains information
the author deems necessary to use the programs. If, during the thirty-day
period, a demonstrable defect in the programs, magnetic medium upon which
they are distributed, or documentation should appear, you may return this
software for repair or replacement, at the author's option. If the defect
cannot be repaired, or the software replaced with functionally equivalent
software, within sixty (60) days of the author's receipt of the defective
software, then you shall be entitled to a full refund of the license fee,
but not of the mailing/handling costs described in the registration form.

All other warranties of any kind, either express or implied,including but
not limited to the implied warranties of merchantability and fitness for
for as a particular purpose, are expressly excluded.

The author cannot and does not warrant that any function contained in the
programs will meet your requirements, or that the operation will be error
free. The entire risk as to the software performance or quality, or both,
is solely with the user, and not with the author.


You assume responsibility for the selection of the program to achieve your
intended results, and for the installation, use, and results obtained from
the software.

The author makes no warranty, either implied or expressed, including with-
out limitation any warranty with respect to this software documented here,
its quality, performance, or fitness for a particular purpose. In no event
shall the author be liable to you for damages, whether direct or indirect,
incidental, special, or consequential arising out the use of or any defect
in the software, even if the author has been advised of the possibility of
such damages, or for any claim by any other party.

The author's entire liability, and your exclusive remedy shall be: (1) the
replacement of an original software diskette not meeting the above Limited
Warranty and which is returned to the author along with proof of purchase,
or (2), if the author is unable to deliver a replacement diskette which is
free of defects, you may terminate the License Agreement by returning this
software and the corresponding license fee will be returned.


By using the software, you acknowledge (1) to have read and understood all
parts of this document and (2) to have agreed with and accepted all of its
provisions without any reservation.


 December 24, 2017  Add comments

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>