Path: utzoo!mnetor!uunet!portal!cup.portal.com!Robert_C_Tellefson
From: Robert_C_Tellefson@cup.portal.com
Newsgroups: comp.sys.ibm.pc
Subject: Re: EXEC call (was: Re: shell script program for pc)
Message-ID: <2890@cup.portal.com>
Date: 1 Feb 88 22:10:52 GMT
References: <2638@cup.portal.com> <5706@eecae.UUCP> <19318@bu-cs.BU.EDU>
Organization: The Portal System (TM)
Lines: 116
XPortal-User-Id: 1.1001.2624


In response to:

ihnp4!msudoc!eecae!driscoll (Michael A. Driscoll)
madd@bu-it.bu.edu (jim frost)

regarding the DOS EXEC function and its relationship with COMMAND.COM.
(There was too much previous quoting to quote again here).

This is indeed an interesting subject.  As I am just beginning to
work with OS/2, the subject is again demanding my attention.

Here are a few notes, experiences, and thoughts on the subject.

The workings of COMMAND.COM are not specifically documented anywhere (to
my knowledge).  There are very general references to replacing it using
the SHELL command and that any replacement must duplicate the functions
performed by COMMAND.COM (^C, critical error handlers being the only
clearly stated functions that are required).

Most of the understanding I do have comes from many hours of actually
tracing COMMAND.COM to determine what essential services it does provide.
In this regard, my experience does not include versions prior to 3.xx.

As for version 2.x dependencies, I can only say that during the two years
since we first introduced our product, we have had no users report any
difficulty executing programs.  By the way, our product is called JOBS,
an acronym for Job Organization and Backup System.

One source of confusion relates to how you define the responsibilities of
what is referred to here as the EXEC function.

DOS function 4bh performs the load, relative address adjustments (in the
case of large model .exe files), setup of the PCP (program control
block), copies the current environment, and provides automatic clean up
of the ^C and critical error interrupts (int 23h and 24h).

It does not handle the path search required to find the executable file.
This must be performed by the program requesting the services of function
4bh (most frequently COMMAND.COM).  It does not set up the proper file
control blocks (FCB) for the program being executed unless the calling
program provides them 'ready made' (again usually COMMAND.COM).

Problems that occur using 4bh include a number of idiosyncrasies related
to how the calling program should prepare the FCB's and the format of the
command line that will be passed to the program being executed.  In
particular, some of the most difficult programs to execute properly are
DOS utilities (ie., FORMAT.COM), as these programs take advantage of
their 'inside knowledge' to parse their command lines in non-standard
fashions.  To replace command.com successfully in these cases, you must
duplicate (to the letter) its manner of parsing and putting command lines
together.

What most programs do to avoid these difficulties is execute programs
through COMMAND.COM.  That is, if they want to run FORMAT.COM, they call
upon function 4bh to load COMMAND.COM and pass it the following command
line: '/c format.com'.  COMMAND.COM takes care of the details and then
calls 4bh again to do what was originally intended.  This increases
processing overhead considerably and also costs approximately 4k of
overhead used by the non-transient part command.com (tied up until the
child process terminates) and a temporary overhead of about 17k used by
the transient portion (size dependent of DOS version).

By directly executing your programs (without COMMAND.COM as the
go-between), JOBS is quicker and more memory efficient.  Executing
programs directly with JOBS ties up only 2k, half of that used by
COMMAND.COM.

I am writing (and uploading) this note on an AT using DOS version 3.1.  I
have Desqview executing my editor (Epsilon), JOBS, and Pro-Yam
communication software.  COMMAND.COM has not been loaded once from disk
since I flipped the on switch (to be sure of this I erased COMMAND.COM).

My config.sys file contains:

DEVICE=C:\QEXT.SYS
DEVICE=C:\VDISK.SYS 320 512 20 /E:2
DEVICE=C:\MOUSE.SYS /2
buffers=30
files=24
SHELL=C:\JOBS.EXE MY-BOOT BOOT /E:300  /p

MY-BOOT is the name of a JOBS macro file containing a macro named BOOT
which performs the equivalent functions that AUTOEXEC.BAT would (and a
number of them that .BAT files can't do).  The /E and /P switches perform
the identical functions to those provided by later versions of
COMMAND.COM.

It is true that a number of programs do not use the COMSPEC environment
variable to determine what shell to use.  These programs assume that
COMMAND.COM is always the shell.  We deal with this in a best of both
worlds way.  JOBS leaves COMSPEC=COMMAND.COM (or whatever you have set it
to) so that COMMAND.COM can be used as normal to run batch files and
satisfy any program that requires COMMAND.COM.  JOBS uses its own
variable called JOBSPEC= to determine where to reload itself from.

While JOBS is capable of replacing COMMAND.COM, we don't push this
feature.  The only advantage to booting directly into JOBS is a savings
of about 2k of ram.  JOBS works equally well when run from the
COMMAND.COM prompt and requires less know-how to install this way (JOBS
is designed to be a power user's tool and also provide an easier to use
alternative for the less sophisticated user).

We have just recently released a full feature Shareware version of JOBS
and I would be glad to email a list of its capabilities to anyone that is
interested.

I would be pleased to see more discussion along this vein.  There is
much of interest here, particularly as we move into the next generation
of DOS.

Robert 'Bob' Tellefson           UUCP:  tellefson@cup.portal.com
RCT Design                 Compuserve:  73417,545
                                Genie:  R.TELLEFSON
                                Voice:  (408) 749-9826
                                 USPS:  663 S. Bernardo #7
                                        Sunnyvale, CA 94087