Hi John,
> > How would PRN behave in the situation that strings are
> > output but no End-Of-Print-Job is sent?
> Today I'm programming an HP P4015 to get the DOS output formatted.
> It appears to have a way to program that timer. Knock-wood.
Interesting.
> Earlier in this thread I inc
Eric,
Thank you for the PRN information.
> How would PRN behave in the situation that strings are
> > output but no End-Of-Print-Job is sent?
>
> Well on real hardware it would depend on the printer. Some
> printers have some timeout and if nothing is sent for a
> while then they print the part of
Eric,
Do you have any knowledge about the behavior of the PRN output. How would
PRN behave in the situation that strings are output but no End-Of-Print-Job
is sent?
I just got the PCL5 programming technical reference from HP. As I remember
from the earlier Laser Jets there is a timeout setting t
I was thinking the [SysRq] would be part of the kernel in the form of a
key-action pair. The table would be loaded at boot time and would by-pass
running programs checking keyed input directly. That is what the LINUX
[SysRq] key sequence does. LINUX uses it for example to kill hung
processes.
It
Eric,
Which output method is a good question for which I do not have an answer.
The program is a Clipper 5.2.x and has a number of added libraries. These
may have replaced the original output routines.
I use NET USE LPT1: to intercept the program output. Is that a clue to this
mystery?
On Th
I was thinking it would be useful to have an escape key sequence of some
kind. LINUX consoles have a [system-request] key feature that is a kernel
option as I remember.
Taking this thought further, a general facility defined in an ini-file that
has escape-sequences matched to actions. A key seque
Hi,
> That's fascinating. I'll have to test that. As far as the DOS program I'm
> forced to use, updating it would require a large investment. There is no
> prospect to generate enough cash to pay for the update.
> > Don't write to LPT1:, instead open a file named "LPT1" and
> > write to it n
Alain,
That's fascinating. I'll have to test that. As far as the DOS program I'm
forced to use, updating it would require a large investment. There is no
prospect to generate enough cash to pay for the update.
Somewhere I have some disassembly of DOS which may reveal why. Where did I
put that?
That is one case where millions of ignorant are just plain wrong.
I found a fix for that many many years ago in a Novell manual and it
works on everything except Dosemu:
Don't write to LPT1:, instead open a file named "LPT1" and write to it
normaly. You will see that when you *close de file* th
john s wolter wrote:
> I found not only myself but millions, according to Google, of others
> have experienced printing delays when printing from inside a virtual
> DOS session.
What do you mean by "virtual DOS session"?
Robert Riebisch
--
BTTR Software
http://www.bttr-software.de/
---
I found not only myself but millions, according to Google, of others have
experienced printing delays when printing from inside a virtual DOS session.
FreeDOS's parts [ in | on | inside] XP is not immune to XP's behaviors.
I came across a fix at Tom's Hardware. The delays were 17 seconds and 3
11 matches
Mail list logo
