DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Charles M. Wil » Sat, 27 Dec 1997 04:00:00



I hope someone out there can help me out with this problem.

Here is the situation:
Windows NT 4.0 workstation (Service Pack 3)
DOS terminal emulation program that uses COM port to connect to our old
mainfram

Now for the most part this all runs fine, the terminal emulation itself
even KERMIT file transfers.  However, I run into a problem when I send
escape sequences to the emulation program from the host.  The escape
sequence tells the emulation program to shell out to DOS and run a batch
file.  This part works fine.  My problem is when the batch file finishes
and hands control back over to the emulation program the emulation's screen
stops updating.  The emulation itself is still working, ie. it lets the
host know that the DOS command has finished and the host continues its job.

This procedure worked fine in Win95.  The only thing I can think of is that
it is a problem with the shell to DOS that somehow relates to the Video
Mode that the emulation program is in.  But the emulation program is a text
mode program and the batch file that I run simply using FTP to connect to
our new system and pulls a file back using the /s switch on the FTP command
with output redirected to a log file that I can check for errors using the
find command.

My questions:
What is the difference between CMD.EXE and COMMAND.COM, the way I
understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
'RUN' command on the start menu, and go into my DOS app from the resulting
command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
all this relate to the ntcmdprompt command in the config.nt file?

What PIF properties have an effect on the VIDEO emulation of the DOS apps?
What effect does the 'Compatible Timer Hardware Emulation' switch have?

Any other ideas on what I should try?

Sorry this is so long, but any help would be greatly appreciated!

Thanks in advance

--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by David Co » Sun, 28 Dec 1997 04:00:00


DOS apps that try to access the hardware directly on NT dont work. W95
behaves differently on this.

cmd.exe is the NT DOS environment that is similar to but not quite the same
as MSDOS5.

command.com is (usually) the W95 command line that looks the same but
behaves again differently to cmd.exe

cmd.exe is part of NT and includes such wonderful executables as a 32 bit
version of edlin for those with long memories and a lot of patience!

HTH

--
David Cox MCSE MCT


>I hope someone out there can help me out with this problem.

>Here is the situation:
>Windows NT 4.0 workstation (Service Pack 3)
>DOS terminal emulation program that uses COM port to connect to our old
>mainfram

>Now for the most part this all runs fine, the terminal emulation itself
>even KERMIT file transfers.  However, I run into a problem when I send
>escape sequences to the emulation program from the host.  The escape
>sequence tells the emulation program to shell out to DOS and run a batch
>file.  This part works fine.  My problem is when the batch file finishes
>and hands control back over to the emulation program the emulation's screen
>stops updating.  The emulation itself is still working, ie. it lets the
>host know that the DOS command has finished and the host continues its job.

>This procedure worked fine in Win95.  The only thing I can think of is that
>it is a problem with the shell to DOS that somehow relates to the Video
>Mode that the emulation program is in.  But the emulation program is a text
>mode program and the batch file that I run simply using FTP to connect to
>our new system and pulls a file back using the /s switch on the FTP command
>with output redirected to a log file that I can check for errors using the
>find command.

>My questions:
>What is the difference between CMD.EXE and COMMAND.COM, the way I
>understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
>DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
>'RUN' command on the start menu, and go into my DOS app from the resulting
>command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
>all this relate to the ntcmdprompt command in the config.nt file?

>What PIF properties have an effect on the VIDEO emulation of the DOS apps?
>What effect does the 'Compatible Timer Hardware Emulation' switch have?

>Any other ideas on what I should try?

>Sorry this is so long, but any help would be greatly appreciated!

>Thanks in advance

>--
>Charles Wilt
>Miami Luken, Inc.
>Springboro, OH.  45066

>--remove the .no.spam


 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Tim Hil » Sun, 28 Dec 1997 04:00:00


This is not related to CMD.EXE or COMMAND.COM (or even NTCMDPROMPT). It's
almost certainly a compatibility bug within the application, and you're
probably stuck with looking for an update or an alternate terminal emulator
(there are LOTS of these available for WIndows NT).

For the record, CMD.EXE is the NT command shell. COMMAND.COM, as shipped
with Windows NT, is merely a "pass through" for 16-bit apps. Interactive
features of CMD.EXE and COMMAND.COM differ, but all command lines are
actually executed by CMD.EXE.

--
Tim Hill -- Windows NT MVP


>I hope someone out there can help me out with this problem.

>Here is the situation:
>Windows NT 4.0 workstation (Service Pack 3)
>DOS terminal emulation program that uses COM port to connect to our old
>mainfram

>Now for the most part this all runs fine, the terminal emulation itself
>even KERMIT file transfers.  However, I run into a problem when I send
>escape sequences to the emulation program from the host.  The escape
>sequence tells the emulation program to shell out to DOS and run a batch
>file.  This part works fine.  My problem is when the batch file finishes
>and hands control back over to the emulation program the emulation's screen
>stops updating.  The emulation itself is still working, ie. it lets the
>host know that the DOS command has finished and the host continues its job.

>This procedure worked fine in Win95.  The only thing I can think of is that
>it is a problem with the shell to DOS that somehow relates to the Video
>Mode that the emulation program is in.  But the emulation program is a text
>mode program and the batch file that I run simply using FTP to connect to
>our new system and pulls a file back using the /s switch on the FTP command
>with output redirected to a log file that I can check for errors using the
>find command.

>My questions:
>What is the difference between CMD.EXE and COMMAND.COM, the way I
>understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
>DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
>'RUN' command on the start menu, and go into my DOS app from the resulting
>command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
>all this relate to the ntcmdprompt command in the config.nt file?

>What PIF properties have an effect on the VIDEO emulation of the DOS apps?
>What effect does the 'Compatible Timer Hardware Emulation' switch have?

>Any other ideas on what I should try?

>Sorry this is so long, but any help would be greatly appreciated!

>Thanks in advance

>--
>Charles Wilt
>Miami Luken, Inc.
>Springboro, OH.  45066

>--remove the .no.spam

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Charles M. Wil » Mon, 29 Dec 1997 04:00:00


Why does NT have both CMD.EXE and COMMAND.COM?  What is the difference, if
any, in the way DOS apps run?

from CMD.EXE---
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.

H:\WILTC>

from COMMAND.COM--
Microsoft(R) Windows NT DOS
(C)Copyright Microsoft Corp 1990-1996.

H:\WILTC>

Also, note that if I have the ntcmdprompt line in my CONFIG.NT file, the
prompt from COMMAND.COM is the same as that from CMD.EXE.  Lastly, the
COMMAND.COM window can only be closed with an EXIT command.  The CMD.EXE
window can be closed by closing the window.
--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam



> DOS apps that try to access the hardware directly on NT dont work. W95
> behaves differently on this.

> cmd.exe is the NT DOS environment that is similar to but not quite the
same
> as MSDOS5.

> command.com is (usually) the W95 command line that looks the same but
> behaves again differently to cmd.exe

> cmd.exe is part of NT and includes such wonderful executables as a 32 bit
> version of edlin for those with long memories and a lot of patience!

> HTH

> --
> David Cox MCSE MCT


 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Maurice Chepepi » Mon, 29 Dec 1997 04:00:00


There is a program on the WinNT CD that is used to run Win95 apps in
the NT world. It essentially tries to fool the app into thinking it's
on a 95 machine. I can't remember the name of the program...maybe
someone else can chime in. This might help you.

MC

On Fri, 26 Dec 1997 17:47:32 -0500, "Charles M. Wilt"


>I hope someone out there can help me out with this problem.

>Here is the situation:
>Windows NT 4.0 workstation (Service Pack 3)
>DOS terminal emulation program that uses COM port to connect to our old
>mainfram

>Now for the most part this all runs fine, the terminal emulation itself
>even KERMIT file transfers.  However, I run into a problem when I send
>escape sequences to the emulation program from the host.  The escape
>sequence tells the emulation program to shell out to DOS and run a batch
>file.  This part works fine.  My problem is when the batch file finishes
>and hands control back over to the emulation program the emulation's screen
>stops updating.  The emulation itself is still working, ie. it lets the
>host know that the DOS command has finished and the host continues its job.

>This procedure worked fine in Win95.  The only thing I can think of is that
>it is a problem with the shell to DOS that somehow relates to the Video
>Mode that the emulation program is in.  But the emulation program is a text
>mode program and the batch file that I run simply using FTP to connect to
>our new system and pulls a file back using the /s switch on the FTP command
>with output redirected to a log file that I can check for errors using the
>find command.

>My questions:
>What is the difference between CMD.EXE and COMMAND.COM, the way I
>understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
>DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
>'RUN' command on the start menu, and go into my DOS app from the resulting
>command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
>all this relate to the ntcmdprompt command in the config.nt file?

>What PIF properties have an effect on the VIDEO emulation of the DOS apps?
>What effect does the 'Compatible Timer Hardware Emulation' switch have?

>Any other ideas on what I should try?

>Sorry this is so long, but any help would be greatly appreciated!

>Thanks in advance

>--
>Charles Wilt
>Miami Luken, Inc.
>Springboro, OH.  45066

>--remove the .no.spam

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Jon-Alfred Smi » Tue, 30 Dec 1997 04:00:00




Quote:>For the record, CMD.EXE is the NT command shell. COMMAND.COM, as shipped
>with Windows NT, is merely a "pass through" for 16-bit apps. Interactive
>features of CMD.EXE and COMMAND.COM differ, but all command lines are
>actually executed by CMD.EXE.

It can't be true that Command.com merely is a "pass through". To me it
seems that Cmd.exe always will try to execute the command in question
first and do so with a 32-bit NT app. If none is found, it will pass
it to the DOS, Posix or OS/2 subsystem. This also explains why the
16-bit 4OS2 command line interpreter worked with at least NT 3.51
(haven't tried with 4.0).

For instance, take Edlin.exe, which is a 16-bit DOS app. If you rename
Command.com, you won't be able to execute Edlin. This suggests that in
the case with DOS apps, Cmd.exe acts as a "pass through" for
Command.com.

If you issue ver, Ver.exe will be executed, which is a 32-bits NT app.
If however the Ver command is the last line in Autoexec.nt, the one
internal to Command.com will be executed:

Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.

C:\>edlin boot.ini

MS-DOS Version 5.00.500

If you peek inside Command.com, all the well-knowninternal commands
are in place, also the messages. And MS even forgot to translate
Command.com. I'm using the Norwegian version.

jas

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Charles M. Wil » Tue, 30 Dec 1997 04:00:00


Thanks for the reply.  I think I have fixed the problem I was having.
Although I don't understand why, apparently the problem was related to some
extra <CR><LF> being sent after the escape sequence.  They didn't bother 95
but NT didn't like them.  

That said, I am still curious about my CMD.EXE vs COMMAND.COM in Win NT
4.0.  Anyone with addtionsl info please feel free to post.
--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam



Quote:> There is a program on the WinNT CD that is used to run Win95 apps in
> the NT world. It essentially tries to fool the app into thinking it's
> on a 95 machine. I can't remember the name of the program...maybe
> someone else can chime in. This might help you.

> MC

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Charles M. Wil » Tue, 30 Dec 1997 04:00:00


Thanks for the reply.  I think I have fixed the problem I was having.
Although I don't understand why, apparently the problem was related to some
extra <CR><LF> being sent after the escape sequence.  They didn't bother 95
but NT didn't like them.  

Your info was helpful.  So what you are saying is that even when I run
CMD.EXE to get a command line from which  I start a 16-bit DOS app, the app
will use COMMAND.COM?
--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam



Quote:> This is not related to CMD.EXE or COMMAND.COM (or even NTCMDPROMPT). It's
> almost certainly a compatibility bug within the application, and you're
> probably stuck with looking for an update or an alternate terminal
emulator
> (there are LOTS of these available for WIndows NT).

> For the record, CMD.EXE is the NT command shell. COMMAND.COM, as shipped
> with Windows NT, is merely a "pass through" for 16-bit apps. Interactive
> features of CMD.EXE and COMMAND.COM differ, but all command lines are
> actually executed by CMD.EXE.

> --
> Tim Hill -- Windows NT MVP

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Charles M. Wil » Tue, 30 Dec 1997 04:00:00


Thanks for the reply.  I think I have fixed the problem I was having.
Although I don't understand why, apparently the problem was related to some
extra <CR><LF> being sent after the escape sequence.  They didn't bother 95
but NT didn't like them.  

Your info was helpful.  So what you are saying is that even when I run
CMD.EXE to get a command line from which  I start a 16-bit DOS app, the app
will use COMMAND.COM?

--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam


Quote:> It can't be true that Command.com merely is a "pass through". To me it
> seems that Cmd.exe always will try to execute the command in question
> first and do so with a 32-bit NT app. If none is found, it will pass
> it to the DOS, Posix or OS/2 subsystem. This also explains why the
> 16-bit 4OS2 command line interpreter worked with at least NT 3.51
> (haven't tried with 4.0).

> For instance, take Edlin.exe, which is a 16-bit DOS app. If you rename
> Command.com, you won't be able to execute Edlin. This suggests that in
> the case with DOS apps, Cmd.exe acts as a "pass through" for
> Command.com.

> If you issue ver, Ver.exe will be executed, which is a 32-bits NT app.
> If however the Ver command is the last line in Autoexec.nt, the one
> internal to Command.com will be executed:

> Microsoft(R) Windows NT(TM)
> (C) Copyright 1985-1996 Microsoft Corp.

> C:\>edlin boot.ini

> MS-DOS Version 5.00.500

> If you peek inside Command.com, all the well-knowninternal commands
> are in place, also the messages. And MS even forgot to translate
> Command.com. I'm using the Norwegian version.

> jas

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Alain Guimberte » Tue, 30 Dec 1997 04:00:00


edlin or edit ? 8-)

On Sat, 27 Dec 1997 11:20:55 -0000, "David Cox"


>DOS apps that try to access the hardware directly on NT dont work. W95
>behaves differently on this.

>cmd.exe is the NT DOS environment that is similar to but not quite the same
>as MSDOS5.

>command.com is (usually) the W95 command line that looks the same but
>behaves again differently to cmd.exe

>cmd.exe is part of NT and includes such wonderful executables as a 32 bit
>version of edlin for those with long memories and a lot of patience!

>HTH

>--
>David Cox MCSE MCT


>>I hope someone out there can help me out with this problem.

>>Here is the situation:
>>Windows NT 4.0 workstation (Service Pack 3)
>>DOS terminal emulation program that uses COM port to connect to our old
>>mainfram

>>Now for the most part this all runs fine, the terminal emulation itself
>>even KERMIT file transfers.  However, I run into a problem when I send
>>escape sequences to the emulation program from the host.  The escape
>>sequence tells the emulation program to shell out to DOS and run a batch
>>file.  This part works fine.  My problem is when the batch file finishes
>>and hands control back over to the emulation program the emulation's screen
>>stops updating.  The emulation itself is still working, ie. it lets the
>>host know that the DOS command has finished and the host continues its job.

>>This procedure worked fine in Win95.  The only thing I can think of is that
>>it is a problem with the shell to DOS that somehow relates to the Video
>>Mode that the emulation program is in.  But the emulation program is a text
>>mode program and the batch file that I run simply using FTP to connect to
>>our new system and pulls a file back using the /s switch on the FTP command
>>with output redirected to a log file that I can check for errors using the
>>find command.

>>My questions:
>>What is the difference between CMD.EXE and COMMAND.COM, the way I
>>understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
>>DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
>>'RUN' command on the start menu, and go into my DOS app from the resulting
>>command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
>>all this relate to the ntcmdprompt command in the config.nt file?

>>What PIF properties have an effect on the VIDEO emulation of the DOS apps?
>>What effect does the 'Compatible Timer Hardware Emulation' switch have?

>>Any other ideas on what I should try?

>>Sorry this is so long, but any help would be greatly appreciated!

>>Thanks in advance

>>--
>>Charles Wilt
>>Miami Luken, Inc.
>>Springboro, OH.  45066

>>--remove the .no.spam

 
 
 

DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

Post by Paul Thornet » Thu, 01 Jan 1998 04:00:00



>Now for the most part this all runs fine, the terminal emulation itself
>even KERMIT file transfers.  However, I run into a problem when I send
>escape sequences to the emulation program from the host.  The escape
>sequence tells the emulation program to shell out to DOS and run a batch
>file.  This part works fine.  My problem is when the batch file finishes
>and hands control back over to the emulation program the emulation's screen
>stops updating.  The emulation itself is still working, ie. it lets the
>host know that the DOS command has finished and the host continues its job.

I've had several problems with Dos sessions. I've found that the video is
unbelievably slow in a Dos windowed, and absolutely fine in a Dos
full-screen, session. I've found that I've had to issue a "mode con: cols=80
lines=25" statement in the controlling batch file to force this video mode
even though it should be the default one. And I've (so far unsuccessfully)
experimented with Forcedos (this forces use of Command rather than Cmd).
I've had PIF files that didn't work on several occasions, but which suddenly
started working properly on other occasions - with absolutely no changes for
me! For what it's worth, here is my Config.Nt file:
   emm=ram
   dos=high, umb
   device=%SystemRoot%\system32\himem.sys
   devicehigh=%SystemRoot%\system32\ansi.sys
   shell=d:\winnt\system32\command.com /p /e:1024
   files=61
 
 
 

1. command.com vs cmd.exe

What is the difference between command.com and cmd.exe? Which one should I use
to run my old DOS programs? How can I customize my DOS sessions? For example,
how do I get doskey macros, environment variables, batch files, etc. to run
when I start a DOS session? Thanks for any help.

--
Brett Pantalone

2. monster truck madness 2

3. CMD.EXE vs COMMAND.COM

4. XP or something is trying to install font

5. CMD.EXE vs. COMMAND.COM

6. MSVC++ 4.2 Problems (urlmon.dll)

7. What is the difference between command.com and cmd.exe?

8. Windows 95 logon

9. Cmd.exe vs. custom shell need to stop Cmd.exe from blocking

10. How do I speed up the curser in cmd.exe and command.com

11. font for Windows-NT console window (command.com, cmd.exe)

12. Old DOS commands using cmd.exe

13. SP1 - cmd.exe and other cmd-line apps won't run after install