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 that ejects the
current page. Maybe this will be sufficient for this problem.
Printfil has a Windows print utility that intercepts LPT1 output from DOS
programs. It routes that output to a file which Printfil watches. It then
routes that output as Raw output or through GDI formatting. I found this
utility a good idea but it was not printing reliably. The program itself
did not crash when running.
I wanted to mention TameDOS which tamed my Clipper application which was
using 99% of the Windows XP CPU time. It worked ok and helped if running
Windows programs along side DOS programs. The Clipper CPU time fell to 14%
according to the DOS Monitoring utility. It would be a fine addition for a
development or Game. I wonder how this would effect Booch's simulator with
FreeDOS.
I'm finding more of these obsolete programs that need to run in a modern
environment. LINUX with simulator and FreeDOS? It could be a consulting
business.
On Thu, Oct 9, 2008 at 7:17 AM, Eric Auer <[EMAIL PROTECTED]> wrote:
>
> 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 normaly. You will see that when you *close the file*
> > > the spool is flushed.
>
> Sounds both simple and useful :-). I mean the problem is
> probably that you have to know when printing is finished,
> as some non-DOS printers prefer to print job-wise and not
> byte-wise... However, there is not only LPT1 and LPT1:
> but also printing to BIOS int17, the printer port I/O or
> the DOS char device directly and explicitly. I wonder
> what your existing software does. If it prints to LPT1:
> via a file then it should be easy to binary patch it to
> print to LPT1 instead. However, it could also print to
> PRN (int 21.05) or use the BIOS (int 17, quite possible)
> or use the char device (sort of unlikely imho) which is
> less trivial to modify...
>
> If there are many people printing from DOS in Windows
> then it might be useful to recommend some "redirect
> int 17 printing to a buffer in RAM, save it to a file
> and then, when the app is done, print that file using
> any command, for example COPY FILE.TXT LPT1" tool in
> this mailing list :-). Anybody remembers a nice one?
>
> Eric
>
>
>
--
John S. Wolter President
Wolter Works
Mailto:[EMAIL PROTECTED]
Desk 1-734-665-1263
Cell: 1-734-904-8433
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
