Power-Programmierung

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

/ Power-Programmierung / CD2.mdf / c / library / dos / strings / tclib13 / smlibtc.doc < prev next >

Wrap

Text File | 1987-09-24 | 45.4 KB | 1,283 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.__________________ ----------------end-of-author's-documentation--------------- Software Library Information: This disk copy provided as a service of The Public (Software) Library Disks in the P(s)L are updated monthly, so if you did not get this disk directly from the P(s)L, you should be aware that the files in this set may no longer be the current versions. For a copy of the latest monthly software library newsletter and a list of the 800+ disks in the library, call or write The Public (Software) Library P.O.Box 35705 - F Houston, TX 77235-5705 (713) 721-6104 or (713) 721-5205 We are not the authors of this program, nor are we associated with the author in any way other than as a distributor of the program in accordance with the author's terms of distribution. Please direct shareware payments and specific questions about this program to the author of the program, whose name appears elsewhere in this documentation. If you have trouble getting in touch with the author, we will do whatever we can to help you with your questions. All programs have been tested and do run. To report problems, please use the form that is in the file PROBLEM.DOC on many of our disks or in other written for- mat with screen printouts, if possible.