kpk@gitpyr.gatech.EDU (Kevin P. Kleinfelter) (04/29/87)
The problem with invoking a secondary command processor under Turbo is that Turbo places code at low memory and data (heap or stack) in high memory. Thus you can't really release the memory to do an EXEC call. The solution I created was to write a little "Job Control" program which installed itself into an interrupt vector and then called a Turbo program. The Turbo program could post requests to the Job Control via registers (via inline code) and interrupt calls. Capabilities of the Job Control included "terminate me and run the next program", "add this program to the Job Queue", etc. To simulate a program call, I wrote a parameter file, terminated and ran the next program, and when it was complete I reran the original program (which skipped forward to the point of the call, based on the parameter file). This took me about a month, and I'm pretty good at low-level programming. Good Luck.
ralf@b.gp.cs.cmu.edu (Ralf Brown) (04/29/87)
The query was how to run a second COMMAND.COM from Turbo Pascal, an answer was given involving a "job control program". At least in Turbo 3.0x, there is a much simpler way (provided that you know beforehand that the program will only need a specific amount of heap and stack space). When compiling to a .COM file, specify the mAximum heap space to be the maximum your program will need. When the .COM file is run, Turbo releases any memory beyond the maximum heap size back to DOS. Then simply run COMMAND by executing an INT 21h function call 4Bh (though you should check first to make sure there is enough RAM for COMMAND and whatever you want to do from within COMMAND. -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
catone@dsl.cis.upenn.edu (Tony Catone) (05/04/87)
In article <3509@gitpyr.gatech.EDU> kpk@gitpyr.gatech.EDU (Kevin P. Kleinfelter) writes: >The problem with invoking a secondary command processor under Turbo >is that Turbo places code at low memory and data (heap or stack) >in high memory. Thus you can't really release the memory to >do an EXEC call. The solution I created was to write a little >"Job Control" program which installed itself into an interrupt vector >and then called a Turbo program. >....... The Jan/Feb 1986 issue of Programmer's Journal had a nice article by Arvind Kumar on calling a secondary command processor from Turbo, complete with Pascal (not inline!) source for doing just that. There are a few typo's in the code, but it wasn't more than a few hours work to type it in, fix and customize it, and have it work. It also helps to play with the maximum allowable dynamic memory option in the Turbo compile options menu. Note that this works with Turbo 3.01A; there are indications in the article that pre-version 3 Turbo requires additional magic (which the article does not go into). - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
catone@dsl.cis.upenn.edu.UUCP (05/06/87)
In article <27@b.gp.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > ..... >memory beyond the maximum heap size back to DOS. Then simply run COMMAND >by executing an INT 21h function call 4Bh (though you should check first >to make sure there is enough RAM for COMMAND and whatever you want to do >from within COMMAND. Strictly speaking, this is not necessary, since service request 4B hex will signal you that there was not enough memory for your program by setting the carry flag and returning an error code in ax. All you really need is a function to translate this code into an appropriate error message and inform the user. - Tony catone@dsl.cis.upenn.edu catone@wharton.upenn.edu
ralf@b.gp.cs.cmu.edu (Ralf Brown) (05/11/87)
In article <1154@super.upenn.edu.upenn.edu> catone@dsl.cis.upenn.edu.UUCP (Tony Catone) writes: >In article <27@b.gp.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >> ..... >>memory beyond the maximum heap size back to DOS. Then simply run COMMAND >>by executing an INT 21h function call 4Bh (though you should check first >>to make sure there is enough RAM for COMMAND and whatever you want to do >>from within COMMAND. > >Strictly speaking, this is not necessary, since service request 4B hex >will signal you that there was not enough memory for your program by >setting the carry flag and returning an error code in ax. >.... > - Tony > catone@dsl.cis.upenn.edu > catone@wharton.upenn.edu True, an error code will be returned if the .COM *image* will not fit in the largest available memory block. However, to run any external commands (or the COPY and TYPE internal commands), COMMAND.COM requires additional memory. That is why I mentioned that you should check the available memory. Note that this would not be a problem if COMMAND were a .EXE program, as the header in .EXE files specifies the minimum memory required to run (which may, in fact, be less than the size of the .EXE file--ProComm is 165,000 bytes, but specifies a minimum load size of about 119,000 bytes--if you are using overlays stored in the .EXE file). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ARPA: RALF@B.GP.CS.CMU.EDU USnail: Ralf Brown AT&T: (412) 268-3053 (school) Computer Science Department Carnegie-Mellon University DISCLAIMER? Who ever said I claimed anything? Pittsburgh, PA 15213 "Teaching COBOL ought to be regarded as a criminal act" --- Edsger Dijkstra