>Original sender: Gene LeFave <gene_at_tekdata.com>
>Rick,
>
>This is the very thing I'm trying to do too. It seems to me that there
>must be a way to do it. The LPT1 driver must be callable, otherwise how
>can the printer drivers and spoolers send data to it? I've tried BIOS
>calls but they crash the system. I've also tried opening LPT1: and PRN:
>as files or Comm devices but that doesn't work either. I will grant you
>that it is a well guarded secret since most terminal emulators do not
>support it either. Yet it must be doable.

Gene,

It is indeed the case that you are not allowed to write directly to the
printer port under windows. The bottom line is that you can actually code
direct port store and fetch operations and do the access under 95/98,
although at a greatly reduced speed. Reason: the windows system services
"virtualize" the i/o and do it for you after a layer of error checking.

Under NT the rules are very different -- no user application may directly
access ports at all. We have and supply a dll/driver pair with SwiftForth
that will let you bypass this limitation, but I would still not recommend
it as a method for printing.

The principle reason to _not_ do direct i/o for the purpose of printing
is that you are subverting the windows printer model by doing so. If you
choose to do it (and you can), any other program trying to print after
you access the port may or may not produce the desired results. It is
absolutely _NOT_ the way to print under windows, and no one can support
your code if you do, nor can you guarantee that it will work on an
arbitrary system if you implement an application in that way.

Rick VanNorman

.
Received on Thu Dec 31 1998 - 17:44:40 PST