Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!super.upenn.edu!dsl.cis.upenn.edu!catone
From: catone@dsl.cis.upenn.edu (Tony Catone)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Secondary command processor w/Turbo
Message-ID: <1129@super.upenn.edu.upenn.edu>
Date: Mon, 4-May-87 12:41:50 EDT
Article-I.D.: super.1129
Posted: Mon May  4 12:41:50 1987
Date-Received: Tue, 5-May-87 01:59:35 EDT
References: <3509@gitpyr.gatech.EDU>
Sender: root@super.upenn.edu.upenn.edu
Reply-To: catone@dsl.cis.upenn.edu.UUCP (Tony Catone)
Distribution: na
Organization: University of Pennsylvania
Lines: 22
Keywords: Do-able.

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