LPT timeout and forcing a flush

LPT timeout and forcing a flush

[Roger Leigh]

Hi folks,

In a DOS application I have to support, it prints a lot of print jobs to
LPT2 and LPT3.  However, the LPT timeout is causing problems, even when
set to 1 second.  The problem is that we need a fast response, but it
sends data so frequently that it can take a long time to time out.  i.e.
we are repeatedly (potentially up to tens per second) creating print
jobs.

In order to work around this, I've tried this small hack:

--- dosemu-1.2.1.orig/src/base/dev/misc/lpt.c	2004-01-17 21:59:07.000000000 +0000
+++ dosemu-1.2.1/src/base/dev/misc/lpt.c	2005-09-20 14:38:54.260224500 +0100
@@ -72,6 +72,10 @@
     /* dbug_printf("printer 0x%x status: 0x%x\n", LO(dx), HI(ax)); */
     break;
 
+  case 3:
+    (lpt[LO(dx)].fops.flush)(LO(dx));
+    break;
+
   default:
     error("printer int17 bad call ax=0x%x\n", LWORD(eax));
     show_regs(__FILE__, __LINE__);
@@ -127,6 +131,11 @@
 int
 printer_flush(int prnum)
 {
+  if (lpt[prnum].file == NULL || lpt[prnum].remaining == -1) {
+    p_printf("LPT: flush aborted: nothing to print\n");
+    return 0;
+  }
+
   p_printf("LPT: flushing printer %d\n", prnum);
 
   fflush(lpt[prnum].file);


This is simply to allow me the ability to request that the print buffer
be flushed from within DOS.  By setting AX=0x300, DX=0x1 and calling
INT 17h, the print queue for LPT2 gets flushed.  I'm not too proud of
this--it's a gross hack.  Is there a better way to request a flush?

This at least gives the program doing the printing a measure of control
over the buffering, so that I can tell DOSEMU when a print job has
ended.


I have a couple of concerns here:

fops.flush (print_flush()) is called within print_tick, but I'm
breaking that assumption.  Are there any locking issues to be
aware of?  I really don't want the tick to go off while I'm in
the middle of flushing, because it could crash the emulator e.g.
if the file has been closed and I try seeking on it.  Is there
some lock held in print_tick that isn't available during an
interrupt?

I'm abusing INT 17h.  Is there a cleaner (or at least, approved)
way of doing this?


Many thanks,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: LPT timeout and forcing a flush

[Bart Oldeman]

On Tue, 20 Sep 2005, Roger Leigh wrote:

> I'm abusing INT 17h.  Is there a cleaner (or at least, approved)
> way of doing this?

have a look at 1.3.2 or CVS: the flushing on dosemu's side was removed.
Instead the byte from int17 is written directly to the file/pipe, and C 
stdio is set to use line buffering (_IOLBF), so the C library flushes 
every \n.

Then the tick/timeout causes an fclose() of the printer file (or pipe).

Bart

Re: LPT timeout and forcing a flush

[Roger Leigh]

On Wed, Sep 21, 2005 at 09:33:24AM +1200, Bart Oldeman wrote:
> On Tue, 20 Sep 2005, Roger Leigh wrote:
> 
> >I'm abusing INT 17h.  Is there a cleaner (or at least, approved)
> >way of doing this?
> 
> have a look at 1.3.2 or CVS: the flushing on dosemu's side was removed.
> Instead the byte from int17 is written directly to the file/pipe, and C 
> stdio is set to use line buffering (_IOLBF), so the C library flushes 
> every \n.
> 
> Then the tick/timeout causes an fclose() of the printer file (or pipe).

That sounds a lot better.  Unfortunately, not all the data I'm sending
is line buffered.  Some are sequences of control codes I want the
device to respond to immediately: it's these I need to flush by hand.


Regards,
Roger