Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/printer/prindir.arc/PRINDIR.DOC

Text File | 1989-11-29 | 10.2 KB | 199 lines

              PRINDIR - Printer Redirection Utility Documentation

                       Program Written by Michael A. Hotz

                              in association with:

                          Techniform Industries, Inc.
                               2107 Hayes Avenue
                              Fremont, Ohio  43420

                Compuserve - 72200,1312          GEmail - MAHOTZ

       Daytime Phone  [phone]       (9 a.m. - 4 p.m. Eastern Time)
       Any other time [phone]       ( if no answer leave message )


          I have put a great deal of time into developing this program. My
     goals when I began writing this program were simple. I wanted an
     effective utility that would let me easily select the destination for
     printer output. The first versions I wrote simply toggled back and
     forth from screen to printer. This was o.k., however, I wanted to be
     able to print to a file. I also wanted to do all of these things in as
     little memory as possible.

          When I began coding the handlers to dump output to a file, I
     tried many different methods. I finally came upon the way that at this
     point seems to work best, and in doing so, I eliminated some of the
     quirks in other printer redirection utilities I have seen and used.

          Before I continue, I would like to mention that I am releasing
     this program as shareware. The requested payment is $10.00, however no
     amount whether larger or smaller will be turned down. This work is
     Copyright (c) 1989 by J.M. Allen Creations. All Rights Reserved by
     Michael A. Hotz. The user assumes all risk which may be involved
     through the use of this program. Neither Michael A. Hotz nor J.M.
     Allen Creations make any warrantees, expressed or implied, as to the
     usefulness or effectiveness of this program. This program may not be
     disassembled, reverse engineered, or modified in any way without
     express written permission from the author.

     I will be glad to offer assistance to those who request it, either by
     phone, E-Mail, U.S. Mail, or whatever other means you may decide to
     use to contact me.

          First of all, you must run the program from the command line (DOS
     2.0 or greater please!) with the proper argument to install it in
     memory. The program requires one argument which will determine where
     in memory it will use a 28k buffer for redirection to a file. The
     program will explain this when you run it, however I will detail these
     options more clearly here.

          If you argument /m, the program will assume you have a monochrome
     video adapter with AT LEAST 32k of display memory beginning at segment
     B000h. The program will then start it's buffer on page two of your
     video ram, effectively saving conventional memory. In general, most
     monochrome display memory starts here, however, not all monochrome
     cards have enough memory. Many of the older MDA adapters only have 1
     page of display RAM. The info that came with your computer, display
     card, or monitor should tell you for sure.







          If you argument /c, the program will assume you have some color
     video adapter with AT LEAST 32k of display memory beginning at segment
     B800h. The program will then start it's buffer on page two of your
     video ram, effectively saving conventional memory. I have tested this
     on CGA, EGA, and VGA monitors, and have had no problems what so ever.
     Again, if you are in doubt, check your paperwork.

          If you argument /s, the program will allocate 28K for the buffer
     at the end of the resident portion of the program, thereby increasing
     the amount of memory it consumes. Using either video buffer, the
     program will keep about 1200 bytes for itself. Not very much at all.
     On the other hand, if you can't use a video ram buffer, the program
     will take in the neighborhood of 29K. Both of these numbers vary
     depending on how much info you have in your environment.

          Obviously, using a video buffer saves a lot of memory, and seems
     effective, however, there are draw backs. First of all, if you use a
     program which uses multiple display pages, redirecting any output to a
     file will more than likely cause the display to do all kinds of
     strange things. Second, the program may do very strange things if you
     attempt file output in any graphics mode. There may be other quirks
     which surface when using the program with a video buffer. If you have
     problems, you can always resort to using conventional memory, and I
     have added a feature to make this even less painful!

          How many times have you loaded a resident program in memory, only
     to find out it is stuck there. You finally end up having to re-boot
     your computer to get it out. Well, I have designed this program to
     unload it's self after it is installed, simply by running the program
     with no arguments. So even if you have to use conventional memory, you
     can easily load and unload this program as needed. You must remember
     that if you attempt to unload PRINDIR after another program has
     changed any of the interrupt vectors that prindir uses, you will not
     be able to unload it until they are restored. PRINDIR will tell you a
     message to this effect if this condition occurs.

          So by now you are wondering why even mess with this offending
     buffer, and just have the data fall through right to an open disk
     file. Well, this is yet another powerful feature of PRINDIR. The
     program, every time it attempts a file write, will open the print
     file, and continue to append data, as long as you want. But, if it
     can't open the file, it will automatically create it, and then
     continue to write to it. I worked with a shareware redirection program
     that opened the file once, and then assumed it was there. But, if it
     was deleted accidentally, the program didn't detect it, and the data
     was written anyway to what would eventually become lost clusters. With
     PRINDIR, this problem is eliminated.

          But there is yet another feature. You have the ability to change
     the name of the output file!  When the program starts, it defaults to
     the file name PRINDIRA.DAT which is created in the root directory on
     drive C: Now if you use the specified key combinations, you can change
     this to PRINDIRB.DAT, or PRINDIRC.DAT, etc... all the way through Z!
     This will allow you to dump whole reports to different files. And you
     can't ever lose data, because the program will not remove or truncate
     existing files, it will only add data at the end.

          Thus, the main reason for the buffer is to hold the data you are
     printing until the operating system is in a safe state, at which point
     PRINDIR detects this and dumps the data to the file, and is then ready






     for more. This concept is what allows the program to be a versatile as
     it is.  One thing you should be aware of, is that may programs will
     not allow the data prindir is holding in it's buffer to go to the file
     until after the program has terminated. This is another reason for the
     buffer, and a problem I am still working on. However, in the mean
     time, I have added some code that will make file name specifier in the
     FIL ? blink when data is waiting to be written. If the letter blinks
     for an excessive amount of time, you will probably need to exit into
     the operating system to dump the buffer to disk.

          Here is a quick summary of the keystrokes which control PRINDIR:

     Hold the LEFT SHIFT and ALT keys and press...

     S = direct output to the screen     P = direct output to the printer

     F = direct output to the file       N = advance file name indicator

                            C = clear the screen


          I should also mention my preferred way of handling and locating
     TSR (terminate and stay resident) programs in memory. This program
     takes an unused interrupt and sets it to point to a special area in
     its data segment. This way, the program can easily tell if it has been
     installed, and at the same time, this interrupt points to all the data
     needed to remove the program from memory. This is also the way I keep
     the resident code so small. The only things resident are the new
     interrupt handlers, and the resident data segment. Every thing else is
     transient, and is released upon program exit. PRINDIR does exactly
     this using interrupt 99h.

          If you have trouble using this program, or experience any
     difficulties, please feel free to contact me so a solution may be
     worked out. I anticipate people requesting that they be able to
     argument their choice of buffer address, as well as a buffer size.
     These are options I plan on in the future, however it is possible to
     make minor changes to the buffer address and length through the DOS
     patch program. For information on how to do this, please send me some
     E-mail, and I will return the commands need to do this.

          PRINDIR was originally developed using Borland Turbo C version
     2.0. After the program was operating properly, it was entirely re-
     written using Borland's Turbo Assembler version 1.0.  De-bugging was
     accomplished using Borland's Turbo Debugger version 1.0. Technical
     information needed for manipulation of the operating system was
     obtained from the DOS Programmers Reference 2nd Edition by Terry
     Dettmann, published by QUE corporation.

     Turbo C, Turbo Assembler, and Turbo Debugger are registered trademarks
     of Borland International, Inc.