Mail Archives: opendos/1998/06/12/12:08:29
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/
--------------------------------------------------------------------
- Raw text -