arritt@kuhub.cc.ukans.edu (06/11/91)
Shareware and PD programs often contain a file 'printdoc.bat' or
some such, which prints out the documentation file. I've noticed
that most of the time these work by 'copy program.doc prn' rather
than 'print program.doc'. The problem is that copy-to-prn locks
up my system until the file is printed, whereas 'print' would
spool so I could do other stuff while the file was printing
(this is under MS-DOS 3.3+; I don't know if other versions behave
the same way).
Is there a good reason for using copy-to-prn rather than 'print'?
At best it's an annoyance; at worst, it gives a bad first impression
(which is the sort of thing that makes users less inclined to pay a
shareware registration fee...)
Granted one could always go in and print the docs manually -- but then
why bother to include the batch file in the first place?
________________________________________________________________________
Raymond W. Arritt |
Assistant Professor |
Dept. of Physics and Astronomy | "People never travel to look
University of Kansas | at flat landscapes."
Lawrence, KS 66045 | - from _Stop Making Sense_ ,
arritt@kuhub.cc.ukans.edu | by the Talking Heads
arritt@walrus.phsx.ukans.edu |
arritt@ukanvax.bitnet |
ts@uwasa.fi (Timo Salmi) (06/12/91)
In article <1991Jun11.105816.31353@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: : >Is there a good reason for using copy-to-prn rather than 'print'? : Print invokes a resident program which will stay in memory thus reserving some of it (unless you use mark-release). Whether that is of consequence or not is another question depending on your configuration and preferences, but that is the technical difference. ................................................................... Prof. Timo Salmi Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.12.37 School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) (06/12/91)
In article <1991Jun11.105816.31353@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: >Is there a good reason for using copy-to-prn rather than 'print'? It's worse than that: Neither might work, as the printer may be connected to another port than prn:, it might not like the document as provided (e.g., a Postscript printer would need a translation from ASCII to Postscript first), and the paper might be formatted for a different size of paper (this has hit me almost every time, American and Finnish paper sizes seem to differ, Finnish is longer). This alone would not be that much of a problem, since the document printing batch file could say that it requires such and such a printer and such and such a paper. If you have something else, then just reformat the documentation and print it by hand, right? Wrong. More often than not, the only form of documentation is the pre-formatted file filled with unknown control code sequences. -- Lars Wirzenius wirzeniu@cc.helsinki.fi
sun@me.utoronto.ca (Andy Sun) (06/12/91)
ts@uwasa.fi (Timo Salmi) writes: >In article <1991Jun11.105816.31353@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: >: >>Is there a good reason for using copy-to-prn rather than 'print'? >: >Print invokes a resident program which will stay in memory thus >reserving some of it (unless you use mark-release). Whether that is >of consequence or not is another question depending on your >configuration and preferences, but that is the technical difference. >................................................................... >Prof. Timo Salmi >Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.12.37 >School of Business Studies, University of Vaasa, SF-65101, Finland >Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun Yes and no. DOS PRINT does more than eats up memory. PRINT allows background spooling and printing. A good reason for not using COPY is if you do not want to wait till COPY finishes sending to PRN before it returns control to you. With DOS PRINT, you can queue several files to print and immediately resume what you are doing. It is "multi-tasking" in a sense (note the quotes). As far as I know, at least from DOS 3.30 onwards, PRINT allows you to specify the spooling buffer size, the "foreground/background" job time ratio (again in quotes, PRINT is a TSR and it's using interrupt, so in fact it should be called foreground/suspend). Andy _______________________________________________________________________________ Andy Sun | Internet: sun@me.utoronto.ca University of Toronto, Canada | UUCP : ...!utai!me!sun Dept. of Mechanical Engineering | BITNET : sun@me.toronto.BITNET
derek@sun4dts.dts.ine.philips.nl (derek) (06/12/91)
(Raymond W. Arritt) arritt@kuhub.cc.ukans.edu writes: }Shareware and PD programs often contain a file 'printdoc.bat' or }some such, which prints out the documentation file. I've noticed }that most of the time these work by 'copy program.doc prn' rather }than 'print program.doc'. The problem is that copy-to-prn locks }up my system until the file is printed, whereas 'print' would }spool so I could do other stuff while the file was printing }(this is under MS-DOS 3.3+; I don't know if other versions behave }the same way). }Is there a good reason for using copy-to-prn rather than 'print'? }At best it's an annoyance; at worst, it gives a bad first impression }(which is the sort of thing that makes users less inclined to pay a }shareware registration fee...) }Granted one could always go in and print the docs manually -- but then }why bother to include the batch file in the first place? There's a very good reason - if print has not already been installed (it's a TSR) and the batch file is called from another program, such as a shell, then, at best you will get an error message saying that the you cann't install a TSR at this time, at worst, the system will hang. This, I imagine will give an even worse impression. The copy ... version is, mostly, safe. Best Regards, Derek Carr DEREK@DTS.INE.PHILIPS.NL Philips I&E TQV-5 Eindhoven, The Netherlands Standard Disclaimers apply.
acrosby@uafhp.uark.edu (Albert Crosby) (06/12/91)
My $.02 worth is that using copy-to-prn is the better solution for the reason that Prof. Salmi indicates: print loads a memory resident program. Sure, print allows you to multi-task in a limited fashion (and queue jobs, etc.), but most people would prefer not to have their environment modified UNKNOWINGLY by a batch file. If it's really a batch file, and it's a big deal to you, just edit the batch file and replace the copy-to-prn to print. On a side note, I have seen some "compressed" doc printers that allowed you to specify the port. Not needful very often, but a nice touch for the author to include. Albert (Yes, I have no .signature, I have no .signature today!)
raymond@math.berkeley.edu (Raymond Chen) (06/13/91)
In article <6711@uafhp.uark.edu>, acrosby@uafhp (Albert Crosby) writes: >My $.02 worth is that using copy-to-prn is the better solution for the reason >that Prof. Salmi indicates: print loads a memory resident program. Agreed. And what if print.com isn't in the user's path? Say, if the batch file is being run from a floppy-only system? Or if the user has deleted print.com (like me). (For example, if I'm on a network that automatically spools print jobs to a pooled printer.) And what if the batch file is executed from a secondary shell? DOS gets mighty confused when TSR's are installed from secondary shells. (Usually forcing a reboot.) And besides, the fact that it is a TSR means that the batch file has a side-effect. My development machine needs all the memory it can get so I can run my debugger. I would be very annoyed if a purportedly harmless batch program ran a TSR, which then forced me to reboot my system just so I can get that memory back. In summary: `copy file prn' works. It doesn't work well, but it works. `print file' works sometimes. Not always. (And I would even venture to say `rarely'.) And sometimes it forces the user to reboot.
fisher@sc2a.unige.ch (06/13/91)
In article <1991Jun11.105816.31353@kuhub.cc.ukans.edu>, arritt@kuhub.cc.ukans.edu writes: > Shareware and PD programs often contain a file 'printdoc.bat' or > some such, which prints out the documentation file. Yes, and it's often formatted for the local printer of the sender, using for example some native-american "standard" paper size instead of our local native-european "standard" A4... :-) > Is there a good reason for using copy-to-prn rather than 'print'? > At best it's an annoyance; at worst, it gives a bad first impression > (which is the sort of thing that makes users less inclined to pay a > shareware registration fee...) DOS' "print" is a TSR. Let's say I connect to some main-frame or Unix system to read the News, download an archive and shell to DOS to have a look at it. If I then execute a batch file loading the TSR "print", it's nothing but trouble! The memory portion will not be released when you exit COMMAND... How's that for a first bad impression? When the system hangs, you'll think the package is really broken, or that it carries a virus. A simple DOS message stating that the printer is not reachable is not nearly as bad. Markus G. Fischer
bsrdp@warwick.ac.uk (Hylton Boothroyd) (06/14/91)
> > > Is there a good reason for using copy-to-prn rather than 'print'? > > > > Print invokes a resident program which will stay in memory thus > > reserving some of it (unless you use mark-release). > > DOS PRINT does more than eats up memory. PRINT allows background > spooling and printing. So to make sure I don't make holes in memory, I include print /d:PRN /b:16384 > nul in my AUTOEXEC.BAT, then it is there. It took me years to discover that some of my machine crashes were caused by using PRINT after I had pushed above an application! --- -- Hylton Boothroyd h.boothroyd@cu.warwick.uk.ac Warwick Business School Janet: h.boothroyd@uk.ac.warwick.cu University of Warwick Darpa: h.boothroyd%cu.warwick.ac.uk@relay-nsfnet.ac.uk COVENTRY, CV4 7AL Uucp: h.boothroyd@warwick.uucp