Power CD-ROM!! 8

home *** CD-ROM | disk | FTP | other *** search

/ Power CD-ROM!! 8 / Power CD-ROM 8.iso / dos / load222 / load.doc < prev next >

Wrap

Text File | 1994-05-31 | 36.4 KB | 763 lines

╒══════════════════════════════════════════╕ │ LOAD │ │ Version 2.22.0 │ │ │ │ Copyright (c) 1991-1994 FM de Monasterio │ │ Licensed Material. All rights reserved │ ╘══════════════════════════════════════════╛ CONTENTS: 1. SUMMARY 2. REGISTRATION 3. GENERAL INFORMATION 4. PROGRAM INFORMATION 5. PROGRAM USAGE 6. HEXADECIMAL SEGMENTED NOTATION 7. LOADING IN UPPER MEMORY 8. BASIC TECHNICAL INFORMATION 9. OPERATION REQUIREMENTS & CONFLICTS 10. COPYRIGHT & LICENSE INFORMATION 11. DISTRIBUTION 1. SUMMARY LOAD permits loading MS-DOS device drivers directly from the command line without having to edit the CONFIG.SYS file and rebooting the system. LOAD also permits unloading from memory a command-line loaded driver, as if it were a typical memory-resident utility. Load/unload parameters are stored in a memory-resident (1-KB) driver gateway. For character (but not block) device drivers, LOAD provides the option of loading a driver in the upper memory blocks (UMBs), i.e., between 640 KB, the PC hardware barrier, and 1024 KB, the extended memory boundary. Upper memory loading conserves the conventional memory, except for the resident driver gateway; this loading requires the presence of MS-DOS 3.0 or later version and of a UMB-providing, extended memory manager. Hence, LOAD allows for treating device drivers simply as typical resident software that can be installed and uninstalled on the fly. 2. REGISTRATION This Software is user-supported; the present release, although lacking the switches indicated by asterisks below, is a working program. You may test this unlicensed release to evaluate the purchase of a licensed copy of the complete Software, as it is explained at the end of this documentation. If you would rather keep using the unlicensed copy, please make a donation to the Children's Hospital of Washington DC, for indigent children in need of medical care. Every year in the USA, infant mortality claims the lives of tens of thousands of children before their first year of life, and most of them come from families below poverty level... Please send to the same address a check payable to the "PATIENT CARE FUND, CHILDREN'S HOSPITAL" on the obverse, and marked "For Deposit Only" on the reverse. Donations will be sent to Children's Hospital. Please identify the program for which you are making the donation; your name will not be included in the users list. (Donations should be in US dollars.) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The enclosed .REG file contains a form needed to license the Software +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ See the final part of this documentation for information on the Licensing, Distribution, and Limited Warranty of this Software. 3. GENERAL INFORMATION The computer operating system communicates with the outside world through peripheral devices. Device drivers are programs that provide an interface between DOS and a physical, e.g., disk hardware, or virtual device, e.g., RAM disk software. DOS distinguishes two main types of installable device drivers: BLOCK (or disk-type) and CHARACTER (or nondisk-type) devices. A block device driver must be able to support one or more 'logical' (viz., physical or virtual) disks, and thus be able to transfer data in groups of characters. Whereas character device drivers typically transfer data one character at a time, the primary feature of this class of driver is that the peripheral device is not a 'logical' disk, as character devices can also support group-mode data transference. Typical examples of such types are 2 programs provided with DOS: ANSI.SYS is a character device driver for the replacement of the console (keyboard and display) driver that DOS loads when it is first started; RAMDRIVE.SYS is a block device driver that implements a RAM-disk in memory. Légère esquisse du chagrin que cause une séparation et des progrès irréguliers de l'oubli... Marcel Proust 4. PROGRAM DESCRIPTION Since their introduction in version 2 of DOS, installable device drivers are usually loaded during the initialization of MS-DOS after the machine boots up. The file CONFIG.SYS specifies the names of the devices drivers via the DEVICE or DEVICEHIGH command. MS-DOS provides no means of removing installed drivers; once a driver is loaded, the machine needs to be rebooted after the editing of CONFIG.SYS to remove such a driver. There are a few command-line device loaders available. Except for LOAD, however, none of them permits the direct loading in the upper memory nor the unloading of a driver. LOAD actually allows you to deal with device drivers as if they were a terminate-and-stay resident programs which can be loaded (in conventional or upper memory) from the DOS prompt whenever you need them, and can later be unloaded--also from the DOS prompt--when not needed anymore. Thus, as many things in modern life, device drivers have also become disposable. This program is written in assembly language for maximum efficiency. LOAD is a processor-aware utility which modifies its internal code to maximize operation under the various types of the 80x86 family of microprocessors. LOAD has a number of 'sanity-checks' and error-trapping routines to allow a more or less graceful exit when a driver crashes, but in some cases you may need to reboot the system. Read the error messages listed in the file LOAD.MSG to get an idea of the checks performed by LOAD. LOADING DRIVERS LOAD normally attempts to load the specified driver at the memory address at which LOAD itself was loaded by DOS. To do so, the utility first moves its own code as high as possible in memory; thus, LOAD requires a minimum of free memory of about twice its executable size. Drivers distributed with DOS as well as many other commercial drivers can be LOADed successfully. Due to the complexity of the operations, however, you will have to find by trial and error which installable device drivers can be LOADed from the DOS command line. (Be aware that due to the nature of the environment on which drivers are expected to be started, i.e. when DOS itself is not completely initialized, and only a few DOS services are available, the initialization of some drivers uses methods which are ill- behaved once the system is fully operational.) For character (but not block) device drivers, LOAD provides the option of installing such a device driver in the upper memory blocks, i.e., between 640 KB, which is the lower limit of the device-mapped memory and ROM BIOS (sometimes referred to as the 'IBM PC hardware barrier') and 1024 KB, the 1MB upper limit of 086-addressable memory (where extended memory starts). Such a range is known as the upper memory area (UMA), and its allocatable blocks are known as UMBs. Loading drivers into UMBs conserves the amount of conventional memory which is available to DOS, except for the resident wedge described below. Erratic behavior has been detected in (some) block device drivers if they are loaded in the upper memory area. To avoid the problem, only character device drivers can currently be loaded via LOAD in the upper memory. This safety limitation can be defeated by block device drivers masquerading as a character device driver, such as CD-ROM drivers. (CD-ROM manufacturers supply a device driver that makes them appear like a character driver and require another resident utility such as MSCDEX [Microsoft CD Extensions] to make the CD-ROM appear like a DOS disk.) UNLOADING LOADED DRIVERS Drivers loaded from the DOS command line, either in conventional or upper memory, can also be uninstalled by LOAD. If more than one driver has been loaded, the reverse loading order should be used for their unloading. To do otherwise may produce conflicts in the operation of DOS or at least of some drivers. To be able to unload the drivers, LOAD also installs a small memory wedge in conventional memory, a wedge which is used both as a memory marker and a data storage record. This wedge, which uses about 1 KB, is referred to as the device driver 'gateway' throughout this documentation. The name of the gateway assigned to a driver is provided at the time of installation; this name is required to unload the driver (see below). The gateway name can also be determined at any time with a memory mapping utility (such as MAPMEM.COM of TurboPower Software). The name consists of 8 characters. For a block device, the string has the format 'DRIVE_d:' in which 'd' is the letter designator of the block device drive, whereas for a character device, the string is the actual device name having all blank padding spaces (if any) changed to the underline character ASCII code 95. For example, the driver ANSI.SYS (which has the reserved name 'CON ') yields the gateway name 'CON_____' upon installation. When unloading drivers, LOAD restores the contents of the interrupt table maintained by the BIOS to the contents saved prior to the installation of the device driver. It then releases all (lower) memory allocated between the resident driver (or, for a UMB-loaded driver, the driver gateway) and LOAD; it then releases the resident driver itself from memory. This means those memory-resident programs that were installed in conventional memory after the driver gateway will be uninstalled as well since their resident memory blocks will be deallocated too. ┌──────┐ Any expanded or extended memory allocated by such residents │ NOTE │ is not released by the unloading process, however, and does └──────┘ not become available to the EMS or XMS pool. Therefore, you should uninstall all subsequent memory residents before the unloading of a preceding command-line-loaded device driver. In contrast, resident programs installed in the upper conventional memory after the device driver was loaded will *not* be released but will remain orphaned in the UMA since any interrupt service they may have been hooked to is now disconnected from them. LOAD does not release those UMBs where the programs reside since, given the vagaries of UMB allocation strategy, it would be too costly (in terms of size of the resident memory wedge) to determine which UMB residents were installed before and after the driver. UNDOCUMENTED DOS FEATURES LOAD uses a few undocumented services that are supported in versions 2.00 through 6.21 of MS-DOS and other MS-compatible versions. The careful use of undocumented services is not a negative feature; in fact, undocumented DOS functions are crucially necessary to a number of commercial programs, including DOS itself. The manner in which undocumented DOS data are obtained by LOAD depends on the version of DOS in use and the support it provides; whenever possible, LOAD performs 'sanity-checks' and provides error-trapping procedures when using undocumented DOS features. For instance, the so-called DOS List of Lists is obtained through a memory search in some buggy versions of DOS 4 but via an undocumented DOS service in other versions (except when such a a service is found to be not supported, in which case the [slower] search method is used). REQUIREMENTS LOAD requires MS-DOS or PC-DOS version 2.00 to 6.21 or a fully compatible operating system; LOAD is incompatible with DR-DOS and OS/2-DOS. For UMA loading/unloading, the presence of an extended memory manager (XMM) which supports version 2+ of the extended memory specification (XMS) is needed. The XMM must be already installed and capable of supporting UMB services. XMMs require DOS version 3 or later. The memory requirements depend on the size of the device driver to loaded and whether the installation will be in conventional or upper memory. In any case a minimum of 10 KB is required. SAFETY MEASURES Each time it is executed, the program verifies its code integrity through a number of cyclic redundancy checks (CRCs). Program execution is aborted if any check were to fail as such a failure indicates code corruption and the program should not be used for your own protection. To decrease the possibility of code tampering, the program is distributed as an encrypted and compressed EXE-type file that expands and decrypts on the fly when executed. This expansion is by a factor of 2 or less. ┌──────┐ Because encryption and compression change the code sequences │ NOTE │ to different values, one cannot exclude that such processess └──────┘ might, just by chance, yield an encrypted data sequence that triggers a false warning from those antiviral utilities that only compare stored files against a list of 'signatures' or instructions. Although all encrypted program files are scanned with one such utility to minimize the possibility of a false warning, the changing nature of these signature lists makes this exclusion difficult. Check the registered distribution diskette before installing the programs in your hard disk and please contact the vendor (see below) if a spurious warning were triggered. 5. PROGRAM USAGE In the descriptions below, {} indicate context variables, e.g. the number {n} or the character string {path}, while <> indicate specific characters or keys, e.g., the letter <n> or the key <F1>. Program usage is quite simple: {path}LOAD [/Dn.nn] [/H[n]] {DriverFile} [driver command switches] or {path}LOAD /U {Gateway} in which {DriverFile} is the complete drive\path\file specification of the device driver to be loaded, while {Gateway} is the 8-character name of the gateway of the loaded device to be unloaded, name which is always provided to the user by LOAD when the driver is installed. If given, {path} is the complete path specification for the file LOAD.EXE. Optionally, the {DriverFile} specification can be followed by any required driver command switches, which are passed to the driver at the time of its initialization. COMMAND SWITCHES The program command switches are not case sensitive. They must be preceded by a slash </>, and they must precede the specification of the driver file to be loaded or the driver gateway to be annulled. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Asterisks mark switches unavailable in the unregistered copy ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Switch /? --------- Displays a brief summary of the program operation and usage. Switch /Dn.nn ------------- Instructs LOAD to return a false DOS version via function 30h of interrupt 21h, where n.nn is the major.minor version to be returned. Switch /D must be used with drivers that refuse to install if the DOS version were higher than an (obsolete) upper limit, and that are part of the SETVER clientele. This version number deception is maintained only during the initialization phase of the driver. You must use this switch in lieu of the SETVER program of MS-DOS 5+, which is *not* accessed by LOAD. Example: LOAD /D3.40 IBMCACHE.SYS ~~~~~~~~ Deceives the driver IBMCACHE.SYS into believing that it is installing under version 3.40 of DOS. * Switch /H[n] ------------ Instructs LOAD to install the driver in the upper memory area, between 640 KB (hexadecimal segment A000) and 1024 KB (hexadecimal segment FFFF), when a free block (UMB) of suitable size is available. The loading requires the presence of an extended memory manager (XMM) implementing the UMB services of the XMS 2 or later (see below 'Loading in Upper Memory' section). A minimum high-memory limit for the UMB can optionally be specified by the number {n} which must consist of 4 hexadecimal digits in the range between A000 and FFFF (see below 'Hexadecimal Segmented Notation'). This limit may be selected, for example, to avoid specific a area of memory having a slow access time. Note that if {n} consists of less than 4 hexadecimal digits, contains an invalid character (neither 0-9 nor A-F), or is less than A000, the default value of n=A000 is used. The UMB size is the memory requested by the driver after an initialization check in conventional memory. Due to such a check, any driver installation banner will be displayed twice if switch /H[n] were specified. Example: LOAD /HCC00 ANSI.SYS ~~~~~~~~ Loads the driver ANSI.SYS, located in the current drive and directory (no path was specified), in a UMB at or above the hexadecimal segment CC00h (816 KB). * Switch /U[!] ------------ Unloads a previously LOADed driver, identified by the associated {Gateway} resident name that must be specified after this switch. If the exclamation mark <!> is part of the switch, the unloading is attempted immediately; if such mark is not present, LOAD asks for user confimation before attempting to unload the driver. This procedure unlinks the driver from the DOS driver chain and, for block device drivers, the corresponding drive from a DOS drive table. Before it attempts to release the memory allocated to a device driver, LOAD modifies both the name and attributes of the device to those of the NUL device (the input/output bit bucket for DOS), as a protection in case the unlinking of the driver--or the release of its memory--were to fail: Since the true NUL device is always the last device in the driver chain, any other NUL device will be ignored. In addition, the gateway of an annulled device is renamed 'unLOADed' to facilitate its detection in memory maps. If driver gateways with the same name were present in conventional memory, i.e., when the same driver has been LOADed more than once, the first found occurrence of the name is used and its associated driver annulled. The unloading of a device driver also uninstalls memory-resident utilities that may have been installed after the driver was loaded, and the contents of the table of interrupt addresses maintained at the first memory segment are changed to those values present immediately before loading the driver. Example: LOAD /U! CON_____ ~~~~~~~~ Unloads the previously installed driver ANSI.SYS (see example above), whose assigned {Gateway} name is always 'CON_____', without requesting the confirmation of the unloaidng. 6. HEXADECIMAL SEGMENTED NOTATION The UMA extends from 640 KB to 1024 KB of memory, which corresponds to the hexadecimal segments A000 to FFFF of real-mode address. Almost invariably, UMA addresses (e.g., hardware-mapped memory, ROM BIOS, resident locations) expected by most applications are expressed as hexadecimal segments, as in the case of the INCLUDE or EXCLUDE memory switches of V86 memory managers. LOAD also expects such a notation for switch Hn when a minimum UMB segment is specified: 700 800 900 1000 UMA memory in KB │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒ ca. 8 KB │ │ │ │ │ │ A000 B000 C000 D000 E000 F000 hexadecimal segments 640 704 768 832 896 960 kilobyte equivalence The relation between UMA hexadecimal segments and kilobytes is illustrated graphically in the above scale and the equivalences can be calculated from the following tables: 1st Digit 2nd Digit 3rd Digit 4th Digit ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ Hex Dec Hex Dec Hex Dec Hex Dec ...0 0 ..0. 0 .0.. 0 0... 0 ...1 1 ..1. 16 .1.. 256 1... 4096 ...2 2 ..2. 32 .2.. 512 2... 8192 ...3 3 ..3. 48 .3.. 768 3... 12288 ...4 4 ..4. 64 .4.. 1024 4... 16384 ...5 5 ..5. 80 .5.. 1280 5... 20480 ...6 6 ..6. 96 .6.. 1536 6... 24576 ...7 7 ..7. 112 .7.. 1792 7... 28672 ...8 8 ..8. 128 .8.. 2048 8... 32768 ...9 9 ..9. 144 .9.. 2304 9... 36864 ...A 10 ..A. 160 .A.. 2560 A... 40960 ...B 11 ..B. 176 .B.. 2816 B... 45056 ...C 12 ..C. 192 .C.. 3072 C... 49152 ...D 13 ..D. 208 .D.. 3328 D... 53248 ...E 14 ..E. 224 .E.. 3584 E... 57344 ...F 15 ..F. 240 .F.. 3840 F... 61440 Thus the hexadecimal segment A800h converts to 42 KB, since ...0 = 0 ..0. = 0 .8.. = 2,048 A... = 40,960 and 43,008 bytes divided by 1024 are 42 KB. (There are several calculating utilities available which convert hexadecimal to decimal numbers, and vice versa.) 7. LOADING IN UPPER MEMORY This section describes in more detail aspects of the installation of the driver in the upper memory region. The allocation of UMA blocks (UMBs) is arbitrated by an XMS manager (XMM) version 2.0 or higher; the XMM must be installed prior to the UMB-loading of the resident. Allocation also requires the remapping of UMA addresses by a UMB provider, when such a task is not implemented by the XMM itself. The XMM HIMEM.SYS and the UMB-provider EMM386.EXE are distributed with MS DOS 5+. The allocation of UMBs is controlled by DOS when these 2 drivers are installed, and the command <dos=umb> is added to the CONFIG.SYS file. With DR-DOS 6+, UMB remapping and XMS support are provided by EMM386.SYS. Other 386-specific memory managers, of course, also provide UMB remapping and XMS support. All XMMs require MS-DOS version 3 or later. Switch Hn, in which A000 ≤ {n} ≤ FFFF (hexadecimal), allows the selection of a minimum upper-memory limit for the UMB to avoid UMA regions having a very slow access time (or to preserve regions with a fast access time for other utilities that require faster times, such as a disk cache or screen accelerator), or to avoid fragmentation of the UMA when UMB allocation is not controlled by MS-DOS 5+, but by the XMM itself. The fragmentation may occur when the XMM allocates blocks on a first-fit basis, i.e., the first available UMB having the lowest UMA address is allocated, irrespective of whether or not a (smaller) block matching the requested size is available at a higher UMA address. Unless the size of the available UMBs increases with increasing memory address, first-fit allocation of a small UMB leads to the breaking of large UMA blocks into smaller ones, thus hampering the UMB installation of larger residents. If MS-DOS 5+ controls UMB allocation, the program enforces the allocation of the resident block on a best-fit basis when {n} is not specified, that is, all available blocks are searched (by DOS), and the one matching most closely the size requested is allocated. When DOS controls UMB allocation and {n} is specified, UMBs are allocated on a first-fit basis. While this may contribute to UMA fragmentation, it allows for the checking of a minimum memory limit in those cases in which the selection or avoidance of a specific UMA region is more important. ┌──────┐ The address and size of the UMBs can be obtained via MEM.EXE │ NOTE │ when DOS controls UMB allocation, or via the XMM itself when └──────┘ UMB allocation is controlled by V86-mode memory managers. In either case, such data can also be obtained with UMAX.EXE, a UMB mapping utility available from the author. If memory access time were a critical element in UMB selection, a detailed access-time map is can be obtained with TIMEM.EXE, a utility which also available from the author. 8. TECHNICAL INFORMATION INTERRUPTS Whenever certain conditions occur, either within a program or the system, it becomes necessary for the processor to interrupt its current operation and execute one of a group of special routines. The action that triggers the execution of such a routine is referred to as an interrupt; there are internal interrupts, in response to a state of the CPU or an instruction, and external interrupts, caused by signals sent to the CPU from elsewhere in the system. When loading a driver, LOAD intercepts the following interrupts to verify the status of the loading process: INT 00h - Divide Exception INT 08h - Hardware System Timer INT 24h - DOS Critical Error INT 2Fh - XMS Interface INT 67h - EMS Interface Because of undocumented behaviors of some device drivers (e.g., Microsoft RAMDRIVE.SYS), this interception is done in a less traditional, but fully transparent manner to the loaded drivers, especially with the application program interface for XMS (INT 2Fh). LOAD releases these interrupts once the driver is successfully loaded. A brief description of the interrupts is given below. Interrupt 00h is triggered by conditions causing a divide overflow, as in the case of a zero divisor, or a dividend too large for the divisor. LOAD monitors this interrupt, assuming that its occurrence indicates a loading incompatibility (at least for debugged drivers). Interrupt 08h is triggered 18.2 times per second by channel 0 of the 8253 /8254 timer chip, and is used by the system time-of-day count. LOAD uses this interrupt to provide a time-out safety exit in case the driver hangs during loading. Interrupt 24h is triggered by a critical error during read and write file or device operations. LOAD monitors this interrupt to determine if driver path specification provided by the user is a correct one. Interrupt 2Fh is used to provide a motley of services for MS-DOS, WINDOWS and third-party applications, including the address of the XMM interface. LOAD monitors this interrupt to determine if the driver allocates any XMS blocks during initialization. Interrupt 67h provides the EMS interface. LOAD monitors this interrupt to determine if the driver allocates any EMS blocks during initialization. DOS ERRORLEVELS Upon completion, the program passes an errorlevel value which can be used to check (via ERRORLEVEL commands in a batch file) the outcome of program execution. The following errorlevels may be passed: Value Nature of Error ----- ------------------------------------ 255 32-bit CRC failed 255 Insuficient memory available 224 DOS does not support fxn 21/52h 192 DOS does not support fxn 21/32h 160 Failed to found NUL driver 128 Invalid DOS version 112 Critical error 96 Removal error 80 XMS error or XMM missing 64 All drives assigned (maximum) 32 All drives assigned (inc no.) 16 Driver initialization error 8 0-unit on block device driver 4 0-byte driver break length 2 Overlay driver load failed 1 Driver name not given 0 Successful execution 9. OPERATION REQUIREMENTS AND CONFLICTS LOADING LIMITATIONS Some device drivers cannot be loaded from the DOS command line with LOAD. In some cases, this is because the driver needs to be installed within 64 KB from the BIOS data area (e.g., some drivers that increase the keyboard buffer); in other cases, this is because the driver is in conflict with a previously loaded resident; and in some other cases, this is because of a conflict between the behavior the driver and that expected by LOAD. Notice that even when the driver has been successfully loaded, it may not satisfy all requirements. For example, the arena header is not changed by LOAD, so instancing of the driver by the DOSMGR device will fail. UNLOADING LIMITATIONS During the initialization of a driver being installed, LOAD checks if the device driver requests expanded (EMS 3.0+) or extended memory (XMS 2.0+); the latter includes the allocation of extended memory blocks (EMB), upper memory blocks (UMB), and the High Memory Area (HMA). When unloading, LOAD attempts the release of allocated EMS or XMS memory, or both. LOAD cannot determine whether the driver has released any allocated EMS or XMS memory prior to the unloading; were the release to occur, the system might crash if the same EMS or XMS handle was assigned to a different process *after* its release by the driver. EMS- or XMS-based devices having resizable capabilities, such as some RAM disks, create the distinct possibility of the above problem when resizing involves first deallocation and then reallocation of memory that yields a 'handle' value different to the original one. 10. COPYRIGHT & LICENSE INFORMATION The program(s) and documentation distributed in this software package (the SOFTWARE) are the copyrighted property of F.M. de Monasterio (the AUTHOR), who provides the SOFTWARE and licenses its use. All rights are reserved. This is an unlicensed copy of the SOFTWARE, made available for purposes of short-term evaluation only, which does not contain all features present in licensed copies of the SOFTWARE. The SOFTWARE is not sold. A license must be purchased to use the SOFTWARE. This license does not transfer to you either the ownership of or the title to the SOFTWARE, which remain the property of the AUTHOR. A form required to license the SOFTWARE is provided in the enclosed .REG file. User Licenses ------------- The purchase of a User License is required to use the SOFTWARE either only by ONE person or only on ONE computer. This License permits copying of the SOFTWARE only for backup purposes. Distributing, repackaging, or reselling of the SOFTWARE to third parties is not allowed. Network server computers are excluded from this License, requiring a Site License for the number of users being served. Site Licenses ------------- A Site License is required to use the SOFTWARE for corporate, educational, commercial, or governmental purposes on MORE than one computer. It permits using the SOFTWARE on up to the number of computers licensed; license fees are based on the total number of computers. Distributing, repackaging, or reselling of the SOFTWARE to third parties is not permitted. A single copy of the SOFTWARE is provided with each license; the License permits copying the SOFTWARE for the number of computers licensed. Distribution Licenses --------------------- The purchase of a Distribution License is required to use the SOFTWARE for corporate, commercial, educational, or governmental purposes involving its distribution with software packages or data, or computer hardware to third parties. The license is non-exclusive and non-transferable. To receive a quotation on a Distribution License, without obligation on your part, send a letter to the AUTHOR on your business stationery providing the following information: 1. Name of SOFTWARE you are interested in distributing. 2. Number of SOFTWARE copies expected to be distributed per year or on a one-time basis. 3. Intended use of the SOFTWARE. 4. Description of the software you intend to distribute with the SOFTWARE, proving the name(s) and price range(s). 5. State or country where your organization is incorporated. Refunds Policy -------------- If a problem notified within 90 days of shipping the licensed copy can not be solved in 90 days after the notification, the SOFTWARE license fee (but not the shipping & handling fee) will be refunded upon receiving a written request with the original diskette(s) enclosed. Upgrade Policy -------------- Latest program releases may be found at the Information Exchange BBS (703) 836-0748, as a compressed archive file. Program upgrades are limited to licensed users. An upgrade within the same major version (e.g. release 4.00 through 4.99) is free of charge if a self addressed, stamped floppy mailer containing the original SOFTWARE diskette is also enclosed with the request. All other upgrades are charged half the current license fee and the full shipping fee. See the enclosed .UPG file. U.S. GOVERNMENT INFORMATION The SOFTWARE is Commercial Computer Software under the Federal Acquisition Regulations of the U.S. government and the Agency Supplements to them. The SOFTWARE is provided to the Federal Government and its agencies only under the Restricted Rights Provisions of the above noted regulations applicable to commercial software developed at private expense, and not in the public domain. The use, duplication, or disclosure of the SOFTWARE by the Federal Government or its agencies is subject to the restrictions set forth in the subdivision (c.1.ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 (October 1988) and FAR 52.227-19 (June 1987). 11. DISTRIBUTION You may distribute this unlicensed SOFTWARE copy, but you are specifically prohibited from: 1. Changing any of the contents of the SOFTWARE, including the copyright notice and license information. 2. Distributing the SOFTWARE with a commercial product without the written, express permission from the AUTHOR. 3. Charging fees or asking donations in exchange of or payment for the SOFTWARE, except for shareware distributors charging usual and customary fees. You may not disassemble or otherwise reverse engineer the SOFTWARE. Other uses of the SOFTWARE are prohibited without a written authorization signed by the AUTHOR. WARRANTY DISCLAIMER FOR UNLICENSED COPIES The information contained in the documentation for the SOFTWARE is subject to change without notice. The AUTHOR cannot and does not warrant that any functions contained in the SOFTWARE will meet your requirements, or that its operations will be error free. The entire risk as to the SOFTWARE performance or quality, or both, is solely with the user and not the AUTHOR. You assume responsibility for the selection of the SOFTWARE 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. All other warranties of any kind, either express or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose, are expressly excluded. 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 terms and provisions without any reservation. For information on the terms of the Limited Warranty for licensed software copies or any other information on this program, please write to: FM de Monasterio P.O. Box 219 Cabin John, MD 20818-0219 USA ┌─────────────────────────────────────────────────────────────┐ │ Trademarked names are the property of the respective owners │ └─────────────────────────────────────────────────────────────┘ [End]