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 ------------------------------------------------------------------------- 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
