Run or execute a program with a switch

[Mark Hunter]

When you run a program from the DOS prompt, you
can specify a parameter or "switch" along with it:
prog/s or prog s
The switch is accessible in the program by the
PB function COMMAND$.

I want to run a program starting from within a
program, using either the RUN or EXECUTE command.
Is it possible to specify a parameter along with
the program? This works:

RUN "prog.exe"

but these don't:

RUN "prog.exe s" ---> error 53 file not found
RUN "prog.exe/s" ---> error 76 path not found
(though / not \)

(I want to avoid, if possible, the program writing a
little file before RUN and prog reading it to get s.)

[Gary Akins]

As I understand it (and I'm sure the PB folks will chime in if I'm wrong ), RUN and EXECUTE do not invoke a copy of COMMAND.COM the way SHELL does - rather, they pass the parameter you give them directly to the DOS service for loading and executing a program. (Which, among other things, is why the original program doesn't get control back when the second program finishes.) Unfortunately, COMMAND.COM is what "parses" the command line, and sends the program name and parameters to the appropriate places; without it, the "exec program" DOS service is being handed what it thinks is a request to run a program named, literally, "prog.exe s".

There are two ways you might be able to work around this, and pass parameters to the second program without an intermediate file. One way is to have your first program stuff the keyboard buffer, then have the second program pick up its instructions via the INKEY$ statement; the other is to declare some variables as COMMON in both programs, then use CHAIN to transfer control from one to the other.

------------------

[Mark Hunter]

Gary Akins --

Good idea stuffing the keyboard buffer.

Another way to pass a parameter to another program
is to use the inter-application communication area:

'In "calling" program

 DEF SEG = &h4F0     'segment of i.a.c.a.
 POKEI(0),%code
 RUN "prog.exe"

'In "called" program (prog)

 DEF SEG = &h4F0	   'segment of i.a.c.a.
 IF PEEKI(0)=%code THEN ...

which is sort of the same idea.



[This message has been edited by Mark Hunter (edited March 21, 2001).]

[Sebastian Groeneveld]

Also have a look at the "pbvUserArea" internal variable. Although
it's limited to 32 characters, I think it was meant for these
situations...

------------------
Sebastian Groeneveld
mailto:[email protected][email protected]</A>

[Martin Myers]

I use parameters with the execute statement all the time. The
following works for me:

runjob$ = "d2twc "+tapedrive$+" "+arg$(2)+" 1" 'arg$(2) is the output file name
execute runjob$




------------------

[Gary Akins]

Aaagh... that'll teach me to try it for myself before I open my big mouth, I guess...

I just tested it with a couple of files, and Martin is correct:

EXECUTE "pkunzip -v D:\host.zip"

works as intended.

RUN "pkunzip -v D:\host.zip"

, however, does not work.

Presumably, then, RUN invokes the "load program" DOS service directly, while EXECUTE does go through the command-line parsing routines in COMMAND.COM. Perhaps someone from PB can explain what reason there would be to prefer one over the other?


In any case, here's the keyboard-stuffing code if anyone's still interested... (this has been tested, BTW, and found to work on both plain DOS, and in DOS sessions under Win9x. Note, however, that it does not work correctly from within the PB/DOS IDE - I have, in fact, managed to confuse PB/DOS with it to the point where the IDE quits responding to the keyboard at all, so use with caution.)

DECLARE SUB KBStuff(STRING)

SUB KBStuff (Cmd$) STATIC PUBLIC
  LOCAL Head%, Tail%    '--head and tail pointers for keyboard buffer
  LOCAL Start&          '--keyboard buffer's starting position in memory
  LOCAL Work$, Length%  '--working (truncated) copy of Cmd$, and its length
  LOCAL PBDataSeg??     '--PowerBASIC data-segment preservation

'-- Limit the string to 14 characters plus <CR>
  Work$ = LEFT$(Cmd$, 14) + CHR$(13)
  Length% = LEN(Work$)

'-- Set the segment for poking, define the buffer head and tail,
'   and then poke each character.
  PBDataSeg?? = pbvDefSeg

  DEF SEG = &H40          '--Switch to BIOS data segment
  Head% = &H1A            '--Buffer head pointer
  Tail% = &H1C            '--Buffer tail pointer
  Start& = PEEKI(&H80)  '--Pointer to keyboard buffer

'-- mow stuff the buffer
  FOR X = 1 TO LEN(Work$)
    POKE Start& + (X - 1) * 2, ASC(Work$, X)
  NEXT

  POKE Head%, Start&                  '--Set new head pointer
  POKE Tail%, Start& + (X - 1) * 2    '--Set new tail pointer

  DEF SEG = PBDataSeg?? '--return to the PowerBASIC default data segment
END SUB

------------------


[This message has been edited by Gary Akins (edited March 21, 2001).]

[keith d. shelton]

If you check the help file you will find that run only works with
programs compiled with pb.
Keith Shelton

------------------

[Mike Doty]

Stuffing the keyboard doesn't work if going to
some programs. Found out the hard way.
I use error levels in a running batch file to
control jumping between programs. It also
has the advantage of clearing all memory and
making sure Windows never gets control.
Something like this:

Start.Bat
:top
If errorlevel 5 if not errorlevel6 goto 5
if errorlevel 4 if not errorlevel5 goto 4
goto end
:5
goto top
:4
goto top
:end



------------------

[Mark Hunter]

Gary --

To go off on a tangent, about the keyboard
stuffer. The following works for me within
a program (not EXECUTE-ing to another).

sub KBstuff(a$)
 dim i as integer
 for i=1 to len(a$)
  reg 1,&h0500             'ah=5  KB services, al= n/a
  reg 3,asc(mid$(a$,i,1))  'cx=ascii (scan not needed if ascii)
  call interrupt &h16
 next
end sub

About run/execute/chain. Run or Execute is preferable
to chain if you are interested in keeping the executable
small -- though you must do extra work to preserve what
variables you want. Chain adds about 32K to the exe file
compared with the other two.

Sebastian Groeneveld --

Yes, pbvUserArea works with run and chain. It doesn't seem
to work with execute. The BIOS inter-application communication
area works with execute as well -- as long as you stay in that
session of DOS and don't jump back to Windows (if Windows is
running).


[This message has been edited by Mark Hunter (edited March 21, 2001).]

[Gary Akins]

Er.. why would you want to stuff the keyboard from within your own program, though? (Not arguing, just curious; it's not something I've ever had reason to do...)

Actually, my question was more "Is there any reason to prefer RUN over EXECUTE", i.e. does RUN fulfill a purpose (other than backwards-compatibility with old code) that EXECUTE doesn't, that would make it the more appropriate or advantageous command to use in some situations?

------------------

[Mark Hunter]

Gary --

Sometimes I stuff the KB buffer in a subroutine to
access a program's menu routine in the main part of
the program. Thus a nether part of the program
can comunicate with the menu without using flags.

Setting the character variable and going to what
follows the get key routine would require some sort
of flag or extra code.

About my original problem: I ended up using
execute and the the inter-application communication
area. It works fine.