Date: Fri, 12 Jun 1998 18:06:25 +0100
From: Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
Subject: Re: call in autoexec
To: opendos AT delorie DOT com
Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de
Message-id: <1AE7F2C3FC9@reze-1.rz.rwth-aachen.de>
Organization: Rechenzentrum RWTH Aachen
Precedence: bulk

On Wed, 10 Jun 1998 Mike Vince wrote:

> The last line of my autodos7 file is:
> 
> ? call c:\nwclient\startnet.bat
> 
> If I answer yes one program does not function (Datastorm's procomm plus
> pcplusuk.exe).  I suspected low memory.  However if I answer no, and
> immediately run startnet from the dos prompt pcplusuk functions ok.
> [...]
> The question is what does call from autodos7 do that is different than
> running a batch file from the prompt?

At the moment I have no suspicion, what could be going wrong there.

CALL stores away the current environment, so that the flow of 
execution of the batchjob (usually, see below) will continue with the 
line after the call, once the called program or batchjob is finished.
CALLs can be nested to some extend, and AFAIK the limit of the nesting 
level was enhanced with DR-OpenDOS 7.02+. If you omit the CALL in 
front of STARTNET.BAT, the execution will just branch to the new 
file without return (as it is the last line of AUTOEXEC.BAT there
should be no difference - please try it). 

However, as CALL does not start a new copy of the shell and the
heap is handled internally, there should actually be no difference
in the memory footprint even when using CALL. 

Strange indeed.

 Matthias

BTW, CALL is not identical to %COMSPEC% /C as stated in some DOS 
     books: %COMSPEC% /C loads a new temporary copy of the shell
     and *always* returns to the calling batchjob. If you are
     in a nested batchjob called by CALL, and then branch to
     another file without CALL, the stack of batchjobs will be
     flushed and you will *not* return to the caller after the
     current job is finished (this is not a bug, and exactly the
     same with MS-DOS COMMAND.COM). 
     However, it can be very annoying if you excute external 
     programs in a batchjob, and somewhen later move these
     files to a different location and introduce wrapping 
     batchjobs referring to their new locations (common practice).
     Without realizing it, user s will thereby often break their
     batchjobs - faults that are quite difficult to track down. 
     
     Hence it is always a good idea to call external programs 
     using CALL, even if this might look obsolete at first,
     e.g. use CALL XCOPY instead of just XCOPY.
     

--------------------------------------------------------------------
 Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, GERMANY
 eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
 Web  : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------- 
 Caldera Digital Research Systems/OpenLinux: http://www.caldera.com/
--------------------------------------------------------------------