dan@srs.UUCP (Dan Kegel) (01/19/88)
In article <5589@eecae.UUCP> driscoll@eecae.UUCP (Mike Driscoll) writes: > Actually, it (the On Command shell) resides on top of command.com's >resident portion, which contains DOS's ONLY loader. Any program using >the DOS exec call needs this loader. Not quite true. 1. Bare PC-DOS (without COMMAND.COM) can load .COM programs via EXEC. That's how COMMAND.COM is probably loaded. 2. Microsoft's MS-DOS Programmer's Reference Manual 3.1 states that only IBM's version (PC-DOS, not generic MS-DOS) has the .EXE loader in (the transient portion of) COMMAND.COM. IBM wanted it that way to save memory. -- Dan Kegel srs!dan@cs.rochester.edu rochester!srs!dan
ROBERT_C_TELLEFSON@cup.portal.com (01/22/88)
>In article <5589@eecae.UUCP> driscoll@eecae.UUCP (Mike Driscoll) writes: >> Actually, it (the On Command shell) resides on top of command.com's >>resident portion, which contains DOS's ONLY loader. Any program using >>the DOS exec call needs this loader. >Not quite true. > 1. Bare PC-DOS (without COMMAND.COM) can load .COM programs via EXEC. > That's how COMMAND.COM is probably loaded. > 2. Microsoft's MS-DOS Programmer's Reference Manual 3.1 states that > only IBM's version (PC-DOS, not generic MS-DOS) has the .EXE loader > in (the transient portion of) COMMAND.COM. IBM wanted it that way to > save memory. The DOS (MS or PC) Exec function (4b hex) may be called by any application to load and execute a .com or .exe file without command.com's participation. This is how command.com executes programs entered at the command line. My company produces a shell capable of replacing command.com, in which case, command.com plays no part in executing programs. Note that command.com is required for execution of .bat files. Robert 'Bob' Tellefson UUCP: tellefson@cup.portal.com Compuserve: 73417,545 Genie: R.TELLEFSON Voice: (408) 749-9826 USPS: 663 S. Bernardo #7 Sunnyvale, CA 94087
madd@bu-cs.BU.EDU (Jim Frost) (01/27/88)
In article <5706@eecae.UUCP> driscoll@eecae.UUCP (Mike Driscoll) writes: >in article <2638@cup.portal.com>, ROBERT_C_TELLEFSON@cup.portal.com says: [i'm deleting a lot of stuff on whether or not command.com has anything to do with loading .EXE programs)] > I am quoting from the IBM DOS 3.30 Technical Reference, page 6-199, >which has two notes about the functioning of the exec call: > > ... > >2. The EXEC call uses the loader portion of COMMAND.COM to perform the > loading. > >An identical note is found in the IBM DOS 3.10 Tech. Ref. > > I now quote from Ray Duncan's Advanced MS-DOS, Microsoft Press, 1986, >page 191, where the return from EXEC is discussed. The following >statement is made: > > The EXEC function will fail if: > > [First two reasons deleted] > > The transient portion of COMMAND.COM in highest RAM (which contains > the actual loader) has been destroyed and there is not enough > memory to reload it (MS-DOS 2 version only). ^^^^^^^^^^^^^^^^^^^^^ My question is, does anyone know for sure whether the loader sections moved from command.com to internal between versions 2.x and 3.x? >2. If I remove command.com from the root directory of my hard drive > and install your company's shell with the SHELL= command in > config.sys, does your shell just use EXEC without supplying > any loader support? Do you alter the COMSPEC environment > variable to point to your shell? Here is personal experience. I wrote a shell (psh, a pascal shell that acts a lot like csh) under MS-DOS 3.10. I installed it using shell= and didn't have command.com available to MS-DOS. Everything ran. I never even thought about the .EXE thing until friends told me different things wouldn't work on their PC's. A lot of people I know use DOS 2.11. I didn't think that there might be a correllation until somewhat recently so I haven't tested the possibility of version dependency. As for altering the COMSPEC environment variable, sometimes this is a good idea and sometimes it isn't. Many programs REALLY expect you to have DOS-style environment. Be wary of changing COMSPEC. You may break other programs. If you do change comspec, make SURE that your new shell accepts /c (and /C). More info on shells and compatibility with existing tools: Many MS-DOS utilites need properly formatted FCB's, so if you write a shell you better put in FCB building routines. If anyone has questions on building workable shells, ask. I'd have made my psh public but there were a few bugs I never got completely worked out, and redirection is really tough using Turbo Pascal 3.0. Now that I have 4.0 though.... jim frost madd@bu-it.bu.edu
Robert_C_Tellefson@cup.portal.com (02/02/88)
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 94087dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/03/88)
In article <2890@cup.portal.com> Robert_C_Tellefson@cup.portal.com writes: >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. Well, maybe. When I wrote Looz 2.1, which can extract an executable programs from a zoo archive directly into memory for execution, I had to figure out how to load a program, set up file control blocks, do any relocation needed for EXE files, etc. I obtained helped from a sample assembly program for the EXE header format (thanks, Michael), but for all other information I depended exclusively on "Advanced MSDOS: Microsoft's guide for Assembly Language and C programmers" written by Ray Duncan. Since Looz successfully extracts and executes all the MSDOS utilities I've tried, I don't think they can be doing much parameter parsing that is not documented. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
windley@iris.ucdavis.edu (Phil Windley) (02/04/88)
Sorry to post this to the net, but I couldn't get through on mail. Robert Tellefson says he would send info on his shell scripting language to people who are interested. SInce I can't contact you Robert, perhaps you'd try to contact me. Phil Windley Robotics Research Lab University of California, Davis
madd@bu-cs.BU.EDU (Jim Frost) (02/07/88)
In article <2026@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <2890@cup.portal.com> Robert_C_Tellefson@cup.portal.com writes: >>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. > >Well, maybe. [...] >...I don't think they can be doing much >parameter parsing that is not documented. If you parse the command line and build FCB's, then all the MS-DOS utilities will work. CHKDSK and FORMAT both use the FCB "drive" field to determine which drive to use, instead of going to the extra effort of parsing out the drive name from the command line. Sort of a short cut. jim frost madd@bu-it.bu.edu
maa@nbires.nbi.com (Mark Armbrust) (02/08/88)
In article <19737@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >If you parse the command line and build FCB's, then all the MS-DOS >utilities will work. CHKDSK and FORMAT both use the FCB "drive" field >to determine which drive to use, instead of going to the extra effort >of parsing out the drive name from the command line. Sort of a short >cut. Also note that unless you immediately follow the command with the switch character (i.e. "COPY/B ...") there will be a space as the first character in the unformatted arguments string. When I was working on a make utility the 'cl' (4.0) command was sometimes blowing up in strange ways and I tracked it down to this missing space. Incidently, the same arguments passed from command.com as "CL/..." also blew up the compiler. [Sorry I can't remember a specific example, it was quite a while ago.] Some tools ignore the character count byte and scan the argument string until they find a 0x0D byte (return). Command.com puts this byte after the argument string and it IS NOT INCLUDED in the character count byte. Hope this helps. Mark