Re: DOS applications ?

From: Jim Carlock (anonymous_at_127.0.0.1)
Date: 09/02/04 

Date: Thu, 2 Sep 2004 12:47:52 -0400

Passing some information along that may be helpful...

I am using XP, SP2.

I was going through messages I've posted in the past. You're
correct about the /C parameter for the command prompt.
There is a /P or a /K though that I think is what I meant to
refer to in order to keep the command prompt open.
cmd.exe uses the /K while command.com uses /P.

One of the problems I've recently had in the near past, was
that I was running pwb.exe (programmers workbench) and
the processor jumped up to 100% useage. I got around it
by starting pwb.exe up inside of a command.com or some
such... and that lead me to a conclusion that there are some
differences between command.com and cmd.exe.

So rereading your message, I decided to look into some of the
differences between a cmd.exe prompt and a command.com
prompt. I was under the assumption that they are two different
and distinct methodologies for running DOS programs.

I started up a cmd.exe prompt. From the cmd.exe prompt I
type in "start command.com". I noticed the following:
1) A second instance of ntvdm.exe was started,
2) There was no second instance of cmd.exe nor a first instance
of command.com.
2) I could not terminate that session without a warning by
trying to click on the close button (X) for that window.
3) Typing in "exit" inside the command.com window exited
properly. TaskManager showed the second ntvdm.exe
disappear (shutdown/destroyed/closed/gone).

Also, I noticed that using the same shortcut to start multiple
instances of cmd.exe resulted in TaskManager showing a
new cmd.exe opening up. But only one ntvdm.exe existed.

I then typed in:
start cmd.exe

This resulted in:
1) Only one (1) ntvdm.exe in existance.
2) A second cmd.exe being displayed inside of TaskManager.
3) I can close that second cmd.exe without any warnings when
clicking on the close icon in the upper right corner (X) of the
window.
4) The second cmd.exe was NOT started from the shortcut so
some properties of the shortcut were not visible... the window
layout was/is different.

Some of the common issues observed between running
start command.com and start cmd.exe:
The second window started in the same directory as the first
window (ie, D:\> the window always inherited the same directory
as the startup directory).

Looking through the internals of the two files, I see:
COMMAND.COM
All text inside is ANSI.
For loops can not be recursive.
The first two characters of this file are not MZ.

CMD.EXE
All text inside is Unicode.
There are quite a few more commands listed inside the file...
PUSHD, POPD and others.

One other comment I'll add is that the command.com file that
came with Windows Me, was 90k in size, just a little bigger
than the 64K limitation that the MS-DOS 6.2 had. I'm not
sure if that means anything, it's just an interesting sidenote.

And while it is quite useless information, perhaps it'll give you
something to talk about. :-) 

-- 
Jim Carlock
http://www.microcosmotalk.com/
Post replies to the newsgroup.
"Joseph M. Newcomer" wrote:
The last I looked at MS-DOS, version 6.x, you could not "open a second command prompt
window". Because this was a concept completely unsupported by the operating system.
Versions of MS-DOS that ran Win9x, however, supported multiple NTVDMs in multiple windows,
as well as having the asynchronous run option. But this only works when you use
32-bit-Windows-on-MS-DOS. That's why I was trying to undestand what the question is, since
there seems to be serious confusion about what is MS-DOS, what is a 32-bit command window,
and running a 16-bit app on a 32-bit environment. These are all different issues than
running on MS-DOS.
If you run a 16-bit app on any 32-bit OS, the rules are different than running a 16-bit
app on a 16-bit MS-DOS system.
Yes, I forgot that command was not actually a .exe, but a .com. .com rules were different
from .exe rules. For example, .com files could only work with small-model code, if I
recall one of the limitations correctly.
/c does not keep the window open. In fact, this is one of the exercises I give my
students, to run a process
cmd /c "dir *.*"
/c simply says to run the command which follows. The command shell terminates after the
command is executed. They depend on this behavior for their exercise.
Mouse drivers in Win16 were loaded as Terminate And Stay Resident (TSR) programs, so when
they exited, they remained in memory.
As far as I know, there is no way to tie together two console windows.
autoexec.bat was loaded each time the command interpreter was started. This is also true
on NT, but I think it only allows SET and PATH execution.
START only applies to 32-bit systems running on top of MS-DOS. It was not supported in
MS-DOS, or Win16 on MS-DOS.
In Win16, you could not start a Windows program from a commmand shell, and you could not
launch a console app by double-clicking it. This inconsistency was removed in Windows, and
the 32-bit-on-MS-DOS versions adopted this as well.
It appears that command.com on XP simply runs command.exe; at least I can't discover a
difference.
joe
On Sun, 23 May 2004 01:09:21 -0400, "Jim Carlock" wrote:
>A DOS batch file runs dos programs sequentially and can run
>programs asynchronously as well. You can start up a second
>command prompt window and keep the second command
>prompt active... I've not done it since Windows 98 but there
>is a /c switch that can be used with command prompts to keep
>the window open... I don't know how to tie the two open
>command prompts together, but I'm sure there's a way to use
>Windows APIs to do it.
>
>You mentioned command.exe. It was really command.com.
>
>The boot process was io.sys, msdos.sys, command.com, then
>Windows.
>
>When Command.com started, that in turn called and ran the
>programs within config.sys, autoexec.bat. Sometimes a mouse
>driver would be contained within the autoexec.bat and once
>the mouse driver was loaded, it stayed running, thus, you had
>a program loaded and called from a command prompt and
>physically running while the command prompt continued
>processing the calling of autoexec.bat.
>
>The only thing I'm not sure about, is whether it was msdos.sys
>that loaded config.sys and autoexec.bat or if it was the initial
>loading of command.com.
>
>The START command (which I think is a command.com or
>cmd.exe internal command) is used to start up separate command
>prompts. This can be demonstrated by the following batch file:
>
>START "Window 1" cmd.exe
>START "Window 2" cmd.exe
>
>In the earlier versions of Windows there was a way to start up
>separate command prompts as well, but I just don't recall if it
>was done in the same fashion.
Joseph M. Newcomer [MVP]
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm