Announcement

Collapse
No announcement yet.

Getting the return value from a shelled EXE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting the return value from a shelled EXE

    In my DOS program, I am shelling to an EXE that calls a DLL.
    The EXE returns a 0 or 1.

    Currently, I am doing this (with line numbers):
    Code:
    10 SHELL "<program> <params>"
    12 IF ERRORLEVEL = 0 THEN GOTO 29000
    , but it does not work.

    What is the proper way to check the return value in the DOS
    program?

    Thanks in advance.

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

  • #2
    Code:
    ' EXECDOS.BAS
    ' Execute an exteernal program as a child proccess, interrogate
    ' it's return code.
    ' For PB/DOS 3.2
    ' Author: Michael Mattias Racine WI 
    ' from original version for Microsoft QuickBASIC by Ethan Winer.
    
    
    '============================================================
    '     SUB TO Execute a program as a child process           
    ' Function value = return code of process; if < 0, error is 
    ' -1 * (dos error)
    '============================================================
    
    ' REG equates as expected in REGS.INC
    DEFINT A-Z
    FUNCTION DosExecute% (Program$, Parameter$) LOCAL
      '---- Prepare the program name and parameter strings for processing.  DOS
      '     requires that the parameter string hold the length of the parameter
      '     text, followed by the parameter text, and then followed by a CHR$(13)
      '     Enter byte.  The parameter block holds two CHR$(0) bytes followed by
      '     the address and segment of the parameter string.
      '
      DIM Block   AS LOCAL STRING * 14    'this is the DOS parameter block
      DIM Parm    AS LOCAL STRING * 80    'and this is the actual parameter text
    
      DIM ZBuffer AS LOCAL STRING * 80    'this holds a copy of the program name
    
      SaveDefSeg = pbvDefSeg
      DEF SEG
      DefaultDS = pbvDefSeg
      Zero$ = CHR$(0)                  'invoke CHR$() only once for efficiency
      DOS = &H21                       'saves a few bytes
      ZBuffer$ = Program$ + Zero$      'make an ASCIIZ string for DOS
    
      LSET Parm$ = CHR$(LEN(Parameter$)) + Parameter$ + CHR$(13)
      LSET Block$ = Zero$ + Zero$ + MKI$(VARPTR(Parm$)) + MKI$(VARSEG(Parm$))
    
      Dummy& = SETMEM(-500000)         'free up memory for the program being run
      REG %RegAX, &h4B00
      REG %RegDX, VARPTR (ZBuffer$)
      REG %RegES, VARSEG(Block$)
      REG %RegBX, VARPTR(Block$) 
      REG %RegDS, DefaultDS
      CALL INTERRUPT DOS
      Flags = REG(0)
      ReturnAX = REG(%RegAX)
      IF (Flags AND 1) THEN          'DOS error trying to run the program?
        DosExecute% = -(ReturnAX)    'yes, set function value to -1 * error code
        GOTO Execute.Done            'and jump to reclaim memory
      END IF
    
      REG %RegAX, &H4D00               'retrieve subordinate process code
      CALL Interrupt DOS
      DosExecute% = REG (%RegAX)          'set function value to exit code
    
    Execute.Done:
      Dummy& = SETMEM(500000)          'reclaim the memory relinquished eariler
      DEF SEG = SaveDefSeg             ' restore DS to what it was at entry.
    
    END FUNCTION
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      No, I do not have a clue if this works calling a Windows program from a DOS application.

      But I'm sure you will tell us what happened.

      MCM
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        A DOS program can get the exit code from a CONSOLE app - it cannot from
        a GUI app.


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

        Comment


        • #5
          >a dos program can get the exit code from a console app - it cannot from a gui app.

          hmm, then maybe my little workaround for the pb/dll 6.x/cc2.x exit code "issue" can actually be of some use...?

          cc3/win7 exit code bug workaround october 26, 2002

          i'll bet it wasn't four weeks after i posted this that a new release of pb came out with this bug fixed, rendering above moot.

          but... you could still shell the program from a dos program, which would shell the gui program, which would return a code to the cc program, which returns the code to the dos program....

          (hell, nobody asked for 'elegant' did they?)

          mcm



          [this message has been edited by michael mattias (edited february 02, 2004).]
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Clay ..

            Why can't you run the console app as a part of a batch file? Will
            it collapse into the batch file and yield any results that way? I
            really don't know the answer to this question, but wanted to ask.

            I know that in OS/2 you can run either a command line instance app or
            a PM app with various versions of utility programs that do this that
            can be used in a batch file. That means DOS-VDM's or even PM OS/2
            applications. From there, if you are using REXX, I think it is possible
            to even get back error codes from all this, but I really never have
            thought much about it..

            REXX isn't limited to OS/2 IIRC, no?


            Thanks ..

            ------------------
            Mike Luther
            [email protected]
            Mike Luther
            [email protected]

            Comment


            • #7
              Mike,

              I have successfully run 32-bit console apps in a BAT file and used
              their exit codes within the BAT file. This was under Win98SE.


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

              Comment

              Working...
              X