🚀 go-pugleaf

On or about <Dec 18 02:39>, Jon Arnold (1:105/7@fidonet.org) scribbled:

 JA> From: jarnold@tixel.mv.com (Jon Arnold)
 JA> Newsgroups: alt.lang.basic
 JA> Reply-To: jarnold@tixel.mv.com

 JA> This might be more an MS/DOS question, but I'll post it here, since 
 JA> I'm
 JA> trying to accomplish this using Basic.  In DOS (v5.0), the *first* 
 JA> time
 JA> you go to use the PRINT command, DOS will ask you where you want the
 JA> file printed to;  You can override this question by using the "/D:"
 JA> switch on the PRINT command line.

 JA> However, *after* the first time you print, the "/D:" switch is no 
 JA> longer
 JA> valid; in fact, it generates an error message.

 JA> I've got a program where I want to shell out to DOS to print a report.
 JA> However, I don't know how to setup the program so that it will know 
 JA> whether
 JA> it needs to PRINT/D: or just PRINT.  Is there an environment variable
 JA> or something that can be examined to determine whether or not the 
 JA> "/D:"
 JA> switch will be required, or if a PRINT has already been done since the
 JA> last boot?

Get a hold of the MS-DOS Programmer's Reference.  PRINT.EXE is a TSR - when
you 
first load it, you can/must specify certain parameters that remain in effect
for 
the duration of its existence in memory.  The device to send output to is one

such parameter - if you specify it on subsequent calls, it generates an error,

as you see.  If you need to specify different devices on subsequent calls, you

might want to use a "mark & release" strategy - mark the memory location
before 
loading, then release it before the next call.  If that's not the case, INT
2Fh 
has a function that returns the state of PRINT.EXE (loaded or not).

        mov     ax, 0100h       ;Get PRINT.EXE Installed State
        int     2Fh             ;Multiplex Interrupt

Upon return, the AL register contains 0FFh if PRINT.EXE has been loaded or 00h

if it has not (from pages 132-134 of MS-DOS Programmer's Reference version 5).
 

A less optimal/technical way of finding PRINT.EXE is to do a shell to DOS and

redirect the output of MEM/C to a file, then open the file and look for
"PRINT" 
- not very elegant, but it'll do the trick.

Happy coding,
ptl

paul.leonard@p111.f48.n105.z1.fidonet.org

"We come into this life naked, bloody, and screaming.  But it doesn't have
to end there if you know how to live right."
                                          === Dana Gould