Date: Thu, 15 Apr 1999 13:30:53 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc: Kbwms AT aol DOT com, djgpp-workers AT delorie DOT com
Subject: Re: LBInstDJ
In-Reply-To: <m10X8km-000S96C@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.990415133027.26213Q-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 13 Apr 1999, Salvador Eduardo Tropea (SET) wrote:

> Jumps to .EXEs (doesn't uses CALL):
> 
> goto %config%
> 
> :C1
> Rem Call Volkov Commander
> vc
> :C2
> ....
> SET PATH....

These cases can be handled.  First, there are some known names of
programs that are invoked from AUTOEXEC.BAT, like nc etc.  For the
rest of them, where you don't know if that's a batch file or a
program, you can either bypass them or ask the user whether to bypass
them or invoke them.

I'm telling that in the context of what I suggested earlier about
actually running AUTOEXEC.BAT inside a subshell.  Ignoring any
programs and batch files migh solve the complications that were
brought up as disadvantages of that approach.

Another approach would be to build a COMMAND.COM simulator.  Shouldn't
be too hard.  You still will need to detect and bypass all calls to
batch files and external programs, though.