home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The C Users' Group Library 1994 August
/
wc-cdrom-cusersgrouplibrary-1994-08.iso
/
vol_200
/
271_02
/
smlibtc.doc
< prev
next >
Wrap
Text File
|
1987-08-20
|
45KB
|
1,255 lines
==========================
= STEVE'S LIBRARY =
= for Turbo C =
= - by - =
= Steven E. Margison =
= Version 1.30 =
==========================
Functions and Documentation Copyright 1987
by Steven E. Margison -- All Rights Reserved
ISBN 0-944267-05-X
--------- TABLE OF CONTENTS ---------
Introduction ................................. 1
The Documentation ............................ 1
Installation ................................. 2
Linking ...................................... 3
Real Time Interrupt Handler .................. 4
Video Functions .............................. 5
A. Introduction .......................... 5
B. Initialization ........................ 5
C. De-Initialization ..................... 6
D. Cursor and Character Placement ........ 6
E. Writing Characters and Attributes ..... 7
F. Miscellaneous Operations .............. 7
G. Video Page Switching .................. 8
H. Reading from Video Memory ............. 9
Utilities ..... .............................. 10
Shareware .................................... 15
Warranty ..................................... 16
Registration Form ............................ --
Steve's C Function Library for Turbo C
I. INTRODUCTION
The heart of the C language is its library. Each
compiler has its own library of functions, which is complete
only to the degree that the compiler author wishes to make it.
The Turbo C Compiler is an excellent product, and comes with a
very extensive function library which has all the usual
"standard" functions, plus many DOS functions as well. However,
the more functions a programmer has at his disposal, the shorter
the time from idea to complete program. That's where "Steve's
Library" comes in. At over 100 functions my library greatly
enhances program development with Turbo C.
"Steve's Turbo-C Library" is the third library I have
produced, the other two being for the Datalight C compiler, and
the Lattice C compiler. Many of the functions in this library
may also be found in the other two libraries as well. A
significant exception is the direct video functions. Datalight
C has an excellent (though incomplete) set of functions aimed at
providing direct access to screen memory. Turbo-C does not have
these functions, however, and I think the omission is a serious
flaw in any MS-DOS compiler. I have corrected that situation in
my Turbo-C library by adding an entire package of direct video
access functions, supporting standard IBM-type video boards and
modes.
II. THE DOCUMENTATION
The documentation for the library is contained in a
number of .DOC files, which describe each function. When
printed, these pages may be placed in a standard three-ring
binder. A utility program, PMAN.COM is provided to generate the
entire set of documents. PMAN requires the file LISTALL, which
may be edited to eliminate printing of certain files if desired.
(PMAN is copyrighted, but placed in the public domain.)
To print the DOC files, you must be in a directory (or
on a floppy) containing PMAN, LISTALL, and all the DOC files.
Just type "PMAN" at your system prompt and the files will be
printed to PRN:.
This documentation is not intended to be a complete
course on writing in "C", or on using the Turbo-C compiler. It
is assumed that if you have this library, you already have
Turbo-C and have read Borland's fine manual.
Steve's Library for Turbo C Page 1
III. INSTALLATION
"Steve's Turbo-C Library" is distributed as five library
files for each type of memory model. (Only the full registration
with source has all five libraries.) The filenames are:
SMTCS.LIB Small Memory Model
SMTCC.LIB Compact Memory Model
SMTCM.LIB Medium Memory Model
SMTCH.LIB Huge Memory Model
SMTCL.LIB Large Memory Model
For the remainder of this manual the libraries will be referred
to as SMTCx.LIB.
A typical hard disk installation of Turbo-C will consist of
several directories, one of which will contain all the "include"
files (those with ".H" extensions) and one with the library
files (those with ".LIB" extensions). All files in "Steve's
Library" with a ".H" extension should be placed in the directory
with the Turbo-C ".H" files. Similarly, all "Steve's Library"
files with a ".LIB" extension should be placed with the Turbo-C
".LIB" files. The documentation and source files from "Steve's
Library" do not need to be on the hard disk, as they will only
be used to print the documentation or modify the function
source. They are not used in the direct creation of a program
under Turbo-C. The executable utilities (*.EXE) files supplied
with "Steve's Library" may be optionally placed in any directory
specified in your PATH environment. These programs are all
examples of function usage and C programming, and do not
directly relate to program development for Turbo-C. However,
they are useful and should be placed on your system for access.
The files with "Steve's Library" with an extension of
".SEM" or ".MAC" are required only for re-assembling the
assembly language modules from this library. They do not need
to be placed on your hard disk unless you plan to re-assemble
any ".ASM" source code files.
Steve's Library for Turbo C Page 2
IV. LINKING
The SMTCx.LIB library must be linked with any other
libraries whenever a function is used in your program. Some
programs may not use SMTCx.LIB functions, and therefore the
linking of the library may be eliminated to save time. In
addition, if you have other third party libraries, be sure to
include them after SMTCx.LIB.
There are several methods to invoke the SMTCx.LIBs when
linking under Turbo C. Refer to the Turbo C manual, chapter 3
(User's Guide) for information on using the libraries from
within the TC programming environment. If you use Borland's
"MAKE" utility with "TLINK", then include a link line similar to
this:
libs = \btc\lib\smtcs+\btc\lib\cs
program: program
tlink \btc\c0s+program, program,,$(libs) /M
This command will link program.obj, c0s.obj, and the indicated
libraries. Be sure to include the path if the libraries are NOT
in the directory in which the link tales place.
Steve's Library for Turbo C Page 3
V. REAL TIME INTERRUPT HANDLER
A special feature of "Steve's Library" is the "ticker"
interrupt handler function. This function provides the
programmer with the ability to install a special routine to
intercept DOS interrupt 1CH. ticker() is a pre-built handler
which allows the user to perform operations relative to the
system's clock. A special variable may be loaded with a value
and then tested at intervals. When the variable has hit zero, a
specific amount of time has passed. The variable counts 18.2
times per second, and is installed on INT 1CH.
The usage of this interrupt handler forces some hard
rules on the programmer. Since this is an interrupt routine
which is called asynchronously to your program, it ABSOLUTELY
MUST be un-installed BEFORE your program exits to DOS. To do
otherwise will invariably cause the next program run to crash
the system, since the 1CH interrupt will then be invoked to a
section of code in the new program which is NOT intended to be
run from int 1CH. Therefore, it is imperative to control exits
from your program when using the ticker. This means that your
program should exit from only one place, which calls
removetick() before performing the actual exit. With good
program design, this is easy to accomplish. (Watch out for my
error(), cant(), badext(), and eraok() functions, though, since
they will exit the program all by themselves!) What isn't so
obvious is the manner in which a program may exit beyond control
of the program itself. This is done if the user types a
control-break, or responds with (A)bort to a DOS critical error.
To avoid exiting the program under these circumstances, any
program which uses the ticker MUST ALSO use Turbo-C's ctrlbrk()
AND harderr() functions to trap and cleanly process a program
exit. Refer to the Turbo-C manual for the proper use of these
two interrupt handler functions. Again, once installtick() has
been invoked, be sure that your program cannot possible exit to
DOS unless removetick() has been called first.
One exception: if the program is a terminate and stay
resident (TSR) utility which needs interrupt 1CH to function,
then removetick() should NOT be invoked before using the
resident exit DOS command. Since the program will still reside
in memory, there will be no conflict in having the ticker()
active.
A file is included named TESTINTS.C, which shows the
usage of the ticker functions. This file may be compiled and
run. (Ignore any warnings about suspicious pointer conversions
-- it is really O.K.)
Steve's Library for Turbo C Page 4
VI. VIDEO FUNCTIONS
A. Introduction
"Steve's Library" provides a complete facility for
direct writes and reads in video memory. Direct video memory,
dvid for short, provides the programmer with a means of creating
extremely fast screen displays, with full control over colors
and attributes. Virtually all "real good" programs, commercial
or otherwise, make use of direct video access to create the
rapid, "sparkling" displays that attract users. There is one
gotcha, though. Direct video access works only on systems which
are truly IBM compatible. Thankfully, this is almost every
PC-type system nowadays. However, there still may be the
occasional wierdo system which places video memory at an oddball
address. With these systems, the direct video access package in
this library will fail. However, since there is a BIOS
override, it should still be possible to configure a program to
operate using rom-bios services for those cases.
Using dvid is very simple, but carries some extra
responsibility for the programmer, especially if the program
being created is intended for public distribution. Some things
to consider are:
* provision for forcing black & white on a CGA, in
case the user has only a monochrome monitor
* provision for changing the default colors. (Just
because YOU like magenta text on a blue background
doesn't mean that everybody else is stupid!)
* provision for forcing bios routines in case the user
has an oddball video system.
* sensing a monochrome adapter card (MDA) and altering
the program accordingly; i.e., no video page
switching, and an underline attribute.
Of course, you can always specify that your program
requires a CGA only, or an MDA only, but it is better to have
the ability to work with both if possible. For the remainder of
this discussion it may be handy to have a printout of DUMP.C
(one of the supplied utilities) for reference. This program
does not take into consideration user configuration, since it is
supplied in source form. Don't like the colors? Edit the
source and re-compile it! As a matter of fact, this program
serves as a good "test bed" for the dvid functions. Many
modifications are possible to demonstrate the use of the dvid
functions.
B. Initialization
Before the dvid functions can be used, the dvid_init()
function must be invoked. This function investigates the
system's resources and sets the base video address, number of
rows, and columns, into its private memory area. This
information is critical to proper dvid operation. Using any of
the functions before invoking dvid_init() will probably cause
problems on MONO boards, and definitely cause trouble with CGA
or EGA boards. If the initialization procedure encounters any
Steve's Library for Turbo C Page 5
type of video information which it cannot understand, then a
flag is set and all video access through the system will then be
done through rom-bios video services, instead of directly to
memory. Generally, the only effect of this will be to make
screen writing noticably slower, but still not as slow as normal
text writing. In addition, it will NOT be possible to display
one CGA video page and write to a different one. However, the
occasions when this would occur should be very rare. There are
ways to insure that EGA cards will behave as MONO or CGA cards.
By using the vmode() function you can set the video mode desired
before calling dvid_init(). Then, dvid_init() should obtain the
correct mode from an EGA emulating a CGA, and avoid setting the
bios flag.
dvid_init() has no effect if called more than once,
since a check is made on an initialization flag. Therefore, it
is not possible to change video modes and then recall
dvid_init(). In order for dvid_init() to re-initialize the
video system, dvid_done() must first be called to
"de-initialize" the video system and restore all internal
defaults.
C. De-Initialization
There is really no overwhelming need to call the
dvid_done() function, unless you just happen to be a "neat-nik".
dvid_done() updates the screen cursor position and restores the
cursor shape to what it was when dvid_init() was invoked. In
addition, it will restore all of the dvid function internal
parameters to their default values and make possible the recall
of dvid_init(). Normally, dvid_done() would be called just
prior to exiting the program.
D. Cursor and Character Placement
The dvid system maintains two sets of row/column
parameters. The first indicates where the NEXT character will
be written in the video memory. The second stores the position
of the REAL onscreen cursor. Since rom-bios routines are used
to change the location of the onscreen cursor, it is not
efficient to continually update the onscreen cursor for all dvid
write operations. The dvid_flush() function is provided to
perform that operation. I will refer to the "internal" cursor,
and the "screen" cursor in the following discussions. The
internal cursor is the position which will be next written. The
screen cursor is the actual onscreen cursor, whether it is
actually visible or not.
All of the dvid functions which take a row/col value and
a character or string argument, such as dvid_say() or
dvid_char_at(), will call dvid_flush() at the end of the
operation to update the screen cursor to the internal cursor
position. However, the lower level functions such as
dvid_putchr() will NOT automatically update the screen cursor to
the internal cursor. Normally, dvid_flush() is only called
after a block of text is written and it is necessary for
Steve's Library for Turbo C Page 6
cosmetic reasons to show where the cursor "really" is. Since it
uses rom-bios functions, using dvid_flush() sparingly will
increase overall screen display speed.
The function dvid_move() is used to set the internal
cursor position to a new location. Note that the screen cursor
is NOT affected by a call to dvid_move().
E. Writing Characters and Attributes
When writing with normal DOS functions to the standard
output channel, no concern is ever made about screen attributes
or colors. However, when writing directly to video memory, it
is actually necessary to write out two bytes for each character;
one is the character, the second is the attribute. The dvid
system saves an attribute internally which is automatically
written each time a character is written to video memory. At
initialization, the attribute defaults to normal white on black.
The dvid_attrib() function is used to change the default
attribute to any valid attribute for the video mode in use.
Refer to the file screen.h for a mnemonic list of screen colors
and attributes.
The primary function for placing characters to the
screen is dvid_putchr(), although in practice dvid_say() and
dvid_char_at() may actually be more useful. dvid_putchr() will
properly place all 256 possible character values with these
exceptions:
07H Sounds Bell
08H Backspaces unless internal cursor is in column 0
09H moves internal cursor right to next mod-8 column
(horizontal TAB)
0AH moves internal cursor down 1 row
(linefeed)
If internal cursor is already at bottom of screen,
screen scrolls up by 1 line
0DH moves internal cursor to column 0 of current line
(carriage return)
0BH moves internal cursor up one line, unless cursor is
already on line 0
(vertical TAB)
7FH (delete) is ignored
All other characters below 20H (space) are ignored
F. Miscellaneous Operations
There are a number of other functions to aid in screen
management. As noted above, a screen attribute can be set and
altered at will. The function dvid_getattr() will return the
value of the current attribute in use, and the current video
page selected for writing. In order to erase characters,
dvid_e2eol() is provided to erase from cursor to end of line,
and dvid_e2eos() erases from cursor to end of screen. In each
case, the cursor position used is the internal cursor, and the
screen cursor is updated automatically to match. To clear the
entire screen, do:
Steve's Library for Turbo C Page 7
dvid_move(0,0); /* cursor to upper left corner */
dvid_e2eos(); /* erase from 0,0 to end of screen */
- or -
dvid_cls(); /* performs a direct screen clear &
home cursor */
The CGA video card must be written to (or read from)
only at certain times to prevent video "snow". Monochrome cards
do not have this problem. Normally, all dvid functions will
automatically synchronize with the CGA card to suppress snow.
However, it is possible to turn synchronization on and off with
the dvid_sync() function. An argument of 0 (FALSE) will turn
sync off, and a non-zero argument (TRUE) will turn sync on
(default condition). Why turn sync off? Well, some EGA cards
do not produce snow, so that sync is not needed when they are
used in CGA mode. Or, in some cases, the extra speed of writing
without sync may be preferable to a little video snow. The
function is provided so that full flexibility is possible.
dvid_scroll() is a function which uses rom-bios features
to scroll a region of the current screen up or down. Refer to
the detailed description for this function for an explanation of
its arguments.
If dvid_init() cannot properly initialize itself, it
sets an internal flag which then forces the dvid functions to
use only rom-bios video functions. This slows down video
access, but provides compatibility for oddball video cards. As
a backup to this, the dvid_bios() function can be called AFTER
dvid_init() to force the use of bios. Note that once selected,
there is no way to turn bios off without calling dvid_done() and
re-initializing the entire video system.
It is possible to change the attributes on a section of
the screen by using the dvid_chgattrib(). Parameters are the
starting row and column, the ending row and column, and new
attribute. If using a CGA card, synchronization will be
performed unless it has been turned off with dvid_sync(FALSE).
Note that rom-bios functions will NOT be used with this
function. Therefore, this function MAY fail if used on a card
which does not map video into the "normal" areas, even though
the use-bios flag has been set.
G. Video Page Switching
dvid_setpage() may be used to control the video page in
use, if a CGA card is being used. Note that MDA cards do not
support video paging, and this function will have no effect. If
a CGA card is used in 80 column mode, there are 4 video pages in
memory, numbered 0-3. For 40 column mode, there are 8 pages,
0-7. dvid_setpage() takes two arguments. The first is the video
page to select for all write/read operations. The second
argument is FALSE to select the video page for write/read only,
and TRUE to also select for display. Using this function
judiciously it is possible to write to a video page not
currently being displayed, and then switch to that page
Steve's Library for Turbo C Page 8
instantly. This can be done as follows:
dvid_setpage(0, TRUE); /* select page 0 for write and display */
dvid_setpage(1, FALSE); /* select page 1 for writing, but do
not change currently displayed page */
dvid_say(10, 5, "Hello World"); /* write to page 1 */
dvid_setpage(1, TRUE); /* make page 1 display now */
One caution is necessary when switching video pages. It is
HIGHLY recommended that you insure a full return to page 0
before exiting the program. Leaving the system on a different
page often prevents subsequent programs from working properly.
H. Reading from Video Memory
Although few programs will ever need to read what is on
the screen, there is support in "Steve's Library" to accomplish
this. dvid_getchr() will read the character and video attribute
at a specified row/column position. Synchronization will be
active or inactive as for writing, and the page selected for
writing will be the page used for reading.
Steve's Library for Turbo C Page 9
VII. THE UTILITIES
"Steve's Library" comes with several utilities,
including the C source code. Nothing earth shaking here, just
some convenient programs to make life a little easier. All the
programs use functions from "Steve's Library" , and can serve as
an example of proper usage. Here is a short description of each
utility:
INPATH
This utility searches for an EXECUTABLE program in the
current path. Typing INPATH at the DOS prompt will display the
version number and a short usage message. To use, type:
inpath <filename>
where filename is the basename portion of the executable file to
find. Note that an extension can be specified, but it is
ignored. INPATH will first look for the file in the current
directory, and then look in the PATH environment variable (if it
is present) in the order specified. For each directory, INPATH
first tries to locate a .COM file, then a .EXE file, then a .BAT
file, since that is the order in which DOS searches for files.
On the first match, INPATH reports the directory and full
filename of the program and then exits. If none are found, that
fact is reported.
INPATH demonstrates the use of newext() and error().
TC
This is a quick Text Compare program to compare two
ASCII files. Typing TC at the DOS prompt will display the
version number and a short usage message. To use, type:
tc file1 file2
where file1 and file2 are the two files to compare. If the
files are identical, no more messages will appear. Otherwise,
the program will report any lines which are different with the
filename, line number, and a printout of the actual line. If
one file ends before the other, the program reports which file
terminated first.
TC demonstrates the use of error() and cant().
Steve's Library for Turbo C Page 10
WC
WC counts words, lines, characters, and checksums one or
more files. Typing WC at the DOS prompt will display the
version number and a short usage message. To use, type:
wc filename [-wcls]
where filename is the name of the file to act upon. With no
options, the program will report words, characters, lines, and a
checksum, which is a simple binary addition of all character
values. No, it ain't a CRC, but it is a quick check to see if
it the same as another file under the same name. The options
[wcls] tell the program to report ONLY the items specified:
-w report only words
-l report only lines
-c report only characters
-s report only checksum
Note that giving all options is the same as giving no options.
Since words, lines, and characters are meaningless in a non-text
file, the program examines the filename extension to determine
if the file is a binary or text file. This isn't a perfect
method, but it is good enough. If the file extension is .COM,
.EXE, .OBJ, .REL, .PFS, .LIB, or .BIN, then only the checksum is
reported, overriding all other options. The program supports
wildcards in the filename, as well as drives and directories.
WC demonstrates the use of exttyp(), and cant().
Steve's Library for Turbo C Page 11
OKISET
This program is used to set the printing options
available on an Okidata ML84 (with IBM Plug 'n' Play), or most
other IBM compatible printers. It may be easily customized for
other printers. This is a menu driven program requiring no
options. Just execute it and follow the directions!
F1 PITCH
Use the SPACE key to toggle between normal (10 cpi)
and condensed (17.5 cpi) pitch. Press RETURN to make
the selection.
F2 STYLE Use the SPACE key to toggle between draft
and letter quality style, and press RETURN to select.
F3 LQ SPACING Enter 1 or 2 digits in the range
00-11 to select letter quality spacing. ESCape will
abort this entry, BACKSPACE will allow you to start
the entry over, and RETURN selects the entered value.
This selection assumes letter quality mode, and forces
the style to letter quality, and the pitch to 10 cpi.
F4 LINES PER PAGE Enter 1 or 2 digits in the range
01-99 to set the page length in lines per page.
ESCape, BACKSPACE, and RETURN operate as for F3.
F5 LINE SPACING Use SPACE key to toggle between 6
LPI and 8 LPI spacing, and press RETURN to select.
F7 OUTPUT CHANNEL Use SPACE key to step through
output channels PRN, LPT1, and LPT2. Press RETURN to
select.
F9 NORMAL OPTIONS This key sets all other options
as follows: pitch > 10 CPI style > Draft
lines > 66 space > 6 LPI output > PRN
F10 SEND CONTROL CODES and EXIT No control codes
are sent until this key is pressed. Only control
codes which have been selected are sent. If the pitch
selection remains blank in the menu, for example, the
pitch control code will not be sent. This allows only
some options to be changed without disturbing the
existing printer configuration.
Letter quality and condensed modes cannot be mixed on the
printer. Therefore, if a conflicting selection is made, the
last entry will force correct options.
OKISET will present various beeps for invalid keystrokes, and
warning messages where appropriate.
Steve's Library for Turbo C Page 12
OKISET will demonstrate cls(), mkbox(), d_say(), getkey(),
d_pos(), and show how to manage a non-scrolling program.
Programming idea: re-write this program using the direct video
access routines.
GTOD
This utility will report the current system time and
date in a variety of formats. GTOD may be invoked with or
without options. Options may be preceded by dash, fraction bar,
or nothing at all.
gtod <options>
-d report only date
-t report only time
-e report date in European format (DD/MM/YY)
-s report seconds, if time reporting enabled
-r reverse reporting order, with time first and date second
-l spell out month in long format
-n if option -l, then add name of weekday
-m report time in 24 hour (military) format
-v report version number
-? usage message and exit
no options defaults to -dt
Output may be redirected to a file or another device, except for
error messages.
GTOD demonstrates the system clock interface, as well as
error(), monthis(), wkdayname(), i_dstr(), and weekday().
Program idea: allow calculation for other time zones.
Steve's Library for Turbo C Page 13
DUMP
(Oh! No! Not aNOTHer file dump utility!) Well, yes,
and I apologize all to h*ll. However, this one does some things
that others do not. First, it will be in **COLOR** if it senses
a CGA card installed, and will use blinks and highlights if a
mono card is sensed. The direct video access functions are
used. Second, it will highlight any selected byte whenever it
is found! Third, it displays only 20 lines at a time and waits
for a keypress to continue. Invoke the program as follows:
dump filename <offset> <byte>
where filename is the file to dump, offset is the hex offset
value in which to index into the file before dumping (defaults
is 0000), and byte is the hex value to highlight (default is no
highlight). The parameters MUST be in the order specified, and
the offset must be supplied (as a place holder) if the byte
option is desired.
DUMP demonstrates the use of getkey(), stuff(), error(), plus
the direct video functions of this library, and the use of color
attributes. Programming idea: there are several ways to
increase the speed of the program. I haven't implemented them
so that you can have the fun(!!) of doing it. Hint: the
overhead in printf() is horrendous.
Steve's Library for Turbo C Page 14
VIII. SHAREWARE
ShareWare is "try-before-you-buy" software, reasonably
priced and user-supported. This simply means that you can get
ShareWare software for free from anyone who has a copy, or often
from bulletin board systems. If you use and like the program,
then the author asks that you register (purchase) the program
for a stated fee. By registering you will often also receive
notice of available upgrades or supplemental programs. Payment
under shareware is on the "honor system", but if the program is
useful and the price is right, then please play by the rules and
purchase the program. Also, keep in mind that the purchase of a
program from a public domain distributor or payment to an online
service (such as CompuServe) does NOT constitute registration of
the program since the producer of the program does not receive
one penny of that payment.
"Steve's Library" is shareware. If you use it, please
register your copy on the registration form enclosed at the end
of this manual. For a slightly higher charge, you may elect to
obtain the source code for all functions, and the M, C, H, L
libraries. Please note that the extra libraries and the source
code are NOT SHAREWARE, and should not be distributed. Only the
documentation, utilities, header files, and Small model library
may be passed on under the shareware concept.
Online help is available through CompuServe
(74435,1042), or GEnie mail (S.MARGISON) to registered users
ONLY. Help is also available by mail. I will try to answer all
letters within 48 hours. Non-registered users must include a
SASE for a reply. The degree of help available to
non-registered users is purely discretionary. No phone calls,
please.
"Steve's Library" may be used in a commercial
environment, with no royalties required if functions are
included in a program for sale. However, the library, source
code, and all related documentation may not be sold under any
circumstances without my prior approval. Software library
services and Users Groups may charge a nominal fee for copying
and distributing those files which are shareware. Please
contact me for a complimentary copy to insure that you are
offering the most recent and complete release. The source code
may NOT be offered for sale or trade by other than myself.
"Steve's Library" may not be included or "bundled" with any
other software without prior permission.
"Steve's Library" and its documentation may not be
transferred nor exchanged in any modified form. I cannot be
expected to help others use these functions if they are not the
same as distributed. Under no circumstances may the copyright
notices be altered or removed from the functions or
documentation.
Steve's Library for Turbo C Page 15
IX. WARRANTY
Oh, this shouldn't be necessary among friends and
gentlemen, but it's really the lawyers who run the world and
they say we gotta do this:
** Steve's Library functions and all documentation are
copyright 1987 by Steven E. Margison.
** These functions and documentation are provided "as
is" without warranty of any kind, either expressed or
implied, including but not limited to the implied
warranties of merchantability and fitness for a
particular purpose.
** The user of these functions and documentation agree
to hold the author and/or distributor(s) of this
material harmless for any direct or consequential
damages resulting from its use. In other words,
"you're on your own!"
** IBM is a registered trademark of International
Business Machines Corporation.
** MS-DOS is a trademark of MicroSoft Corporation.
** Turbo-C is a registered trademark of Borland
International, Inc.
** Datalight C is a registered trademark of Datalight,
Inc.
** Lattice is a registered trademark of Lattice, Inc.
Steve's Library for Turbo C Page 16
=======================================================================
SOFTWARE REGISTRATION FORM AND ORDER
=======================================================================
A separate form must be filled out for each product ordered or
registered. This form may be photocopied, printed out, or
edited to include all information and re-printed.
PRODUCT: --------- STEVE'S TURBO-C LIBRARY VERSION 1.30 --------------
QUANTITY: Amount:
_____ Standard registration $10.00 ea $______
_____ Registration with Source code $25.00 ea $______
Shipping outside U.S. or Canada $ 3.00
TOTAL DUE $______
Payment must be made in U.S. Funds
Source code is NOT SHAREWARE and is not to be transferred to other
users. Only the DOC files, header files, utilities,
and S library are released into shareware.
Corporations: Write with your requirements for a quote on
multiple copies or site licensing.
If you already have this library, where was it obtained?
[ ]CompuServe [ ]Friend [ ]Employer [ ]BBS:__________________
Version_____ Serial No._________
Payment is by check[ ] or money order[ ] (Sorry - no COD or charges)
NAME _______________________________________________________
COMPANY ____________________________________________________
ADDRESS ____________________________________________________
CITY _______________________________________________________
STATE___________________________ ZIP _______________________
=======================================================================
Send completed form and payment to:
Steven E. Margison
124 Sixth Street
Downers Grove, IL, 60515
=======================================================================
- do not write below this line -
recd________ sent________ version_______ serial no.__________________