Click above to get retro games delivered to your door ever month!

 Printer Connection Strategies
------------------------------------------------------------------------------

     In the old single tasking days it was a simple matter to decide how
     and when to redirect a printer and what to do with those redirections
     at the termination of the application. The first version of this
     library, which I wrote back in the 1980s using assembly language and a
     programming reference manual from D-Link, picked up a list of all
     redirected printers at program startup. During the life of the instance
     of the application, a number of printers were connected and disconnected
     as the need arose, and the original redirections were then restored
     immediately before program termination. So a "NET USE" command after
     program termination would show exactly the same redirection list as
     before program start.

     However, when the users started running my applications under Windows,
     things got a little more complicated. The problem was of course that it
     became impossible to determine what the "original" redirection list
     really was. If several instances of my application (or several different
     applications) were started and terminated in random order on the same
     computer they would not be able to agree between themselves which
     redirection list had been current before the first of them started.

     This problem will probably never be "properly" solved, but I have found
     that the following strategy causes the least grief:

     1) Don't bother with trying to restore the original environment. You
     may end up restoring the wrong redirections anyway. Just leave the
     printer connections as they are when you quit.

     2) Don't change redirections immediately before program termination.
     It may cause Win9x (and Win9x only, AFAIK) to hang the DOS box.

     3) Before deciding to redirect printers at all inside your application,
     you have to determine if it is a wise thing to do considering how
     printers are set up in general on your users' computers. Are other
     applications using printers by LPT names, and if so, is the whole range
     of LPT ports involved? If there is a significant risk of LPT clashes,
     could you limit your printer use to only one port, for example LPT3 in
     order not to disturb other applications running on the computer?
     (Technically the answer is yes. You can connect any number of printers
     to the same local printer port name, one at a time, provided that you
     disconnect them again when you need to connect the next printer).

     4) Give the user a possibility to change the printer port assignments
     (the LPT port name) to avoid clashes with other applications.

     5) Set up the printer redirection for each print job at the last moment.
     If you do it at program startup, another application or another instance
     of the same application may pull the rug away from under your feet before
     you are ready to actually print.

     6) Consider the risk that a user starts printing from two different
     applications or application instances at the same time and that those
     two print jobs will disconnect each other's printers. In my experience,
     that risk is of limited size, especially if you set up your printer
     redirections immediately before printing is started.

     Considering the size of the list of recommendations above, it may sound
     like you would be better off avoiding this matter entirely and instead
     set up the printer redirections separately before your application is
     started. But I have users who run up to four or five instances of the
     same application and regularly use four or five different printers in
     each instance. Since I removed the old restore-on-termination code from
     the days of single tasking operating systems I have had no reports of
     printing failures that could be suspected to have anything to do with
     the redirection strategy. So I believe that, if handled with a little
     care, the redirection functions can be a useful addition to the average
     networked Clipper application.