no text echo in command.com screen

[Art Armfield]

Hello all,

I have a client that is running W2K and an older DOS app -- app is using
runtime engine supported on W2K and I have this same app running on other
clients with W2K with no problems. The problem with this particular system
is for **some** reason I get no text echo back to the screen when running
command.com -- problem does NOT exist within cmd.exe.

The command, whatever it may be is there as when you press enter it executes
(dir for instance) but it will not echo back to the screen. I've found ONE
other post on this that hadn't gotten an answer on Citrix's web site (we are
using MetaframeXP/TS's for remote connectivity) but the issue is occuring on
all three servers, Main file server (backup DC) and both Metaframe servers
(just servers, no DC's).

My client needs to access the command prompt and the DOS app, which has a
config.nt file which sets the shell variable is pointing to:

Shell=%SystemRoot%\system32\command.com /E:4096

is running fine with no problems. Any suggestions welcomed. Servers are a
SP3 level. SP4 I'm still not sold on.

Art

 

[Bill Stewart]

I have a client that is running W2K and an older DOS app -- app is using
runtime engine supported on W2K and I have this same app running on other
clients with W2K with no problems. The problem with this particular
system is for **some** reason I get no text echo back to the screen when
running command.com -- problem does NOT exist within cmd.exe.

The command, whatever it may be is there as when you press enter it
executes (dir for instance) but it will not echo back to the screen. I've
found ONE other post on this that hadn't gotten an answer on Citrix's web
site (we are using MetaframeXP/TS's for remote connectivity) but the
issue is occuring on all three servers, Main file server (backup DC) and
both Metaframe servers (just servers, no DC's).

Hi Art,

What I don't see in the above details is why you have to use command.com,
instead of cmd.exe.

Bill

 

[Art Armfield]

Hi Art,

What I don't see in the above details is why you have to use command.com,
instead of cmd.exe.

Bill

Sorry about that Bill, it's been a question in my mind all along but
according to DataAccess who's DataFlex runtime makes the database run we
have to use command.com even in W2K.

Even if I go start/run/ command.com without the software it performs the
same way. I've got a LOT of W2K boxes out there and none of them do this.
Don't know if I'm missing something basic or not as I installed the servers
from scratch (W2K SP3).

Got any ideas?

Many Thanks,
Art

 

[Mark V]

Sorry about that Bill, it's been a question in my mind all along
but according to DataAccess who's DataFlex runtime makes the
database run we have to use command.com even in W2K.

Even if I go start/run/ command.com without the software it
performs the same way. I've got a LOT of W2K boxes out there and
none of them do this. Don't know if I'm missing something basic or
not as I installed the servers from scratch (W2K SP3).

Got any ideas?

Thin, but check all the Properties of command.PIF.
In that it is possible to set Fore. and Bkgrd. colors the same for
one thing. IIRC

 

[Bill Stewart]

Thin, but check all the Properties of command.PIF. In that it is possible
to set Fore. and Bkgrd. colors the same for one thing. IIRC

That's just what I was going to write.

But I am still sketchy as to why the developer of this application is
demanding that it be run using command.com. Command.com is mostly a stub
program...

 

[Mark V]

That's just what I was going to write.

But I am still sketchy as to why the developer of this application
is demanding that it be run using command.com. Command.com is
mostly a stub program...

Understood.
Clueless developer?
;-)

 

[Art Armfield]

That's just what I was going to write.

But I am still sketchy as to why the developer of this application is
demanding that it be run using command.com. Command.com is mostly a stub
program...

Thanks to both of you. I am going to check that now, never really occured to
me.....

Now you guys have me going over command.com. I've done some testing here at
my shop but in the config.nt file if I change command.com in the shell
environment variable to cmd.exe I get NTVDM illegal instruction errors. I
appreciate the help from both of you very much and I'll check those colors
now.......

Art

 

[Mark V]

Thanks to both of you. I am going to check that now, never really
occured to me.....

Now you guys have me going over command.com. I've done some
testing here at my shop but in the config.nt file if I change
command.com in the shell environment variable to cmd.exe I get
NTVDM illegal instruction errors. I appreciate the help from both
of you very much and I'll check those colors now.......

No.

Just open a cmd.exe prompt. CD to the programdir and excute it.
Does it work? If not what happens? Try a Full Screen cmd window
too.

The developer may indeed be right and "command.com" specifically
required.

 

[Art Armfield]

No.

Just open a cmd.exe prompt. CD to the programdir and excute it.
Does it work? If not what happens? Try a Full Screen cmd window
too.

The developer may indeed be right and "command.com" specifically
required.

DOH!!! I apologize for not making this clearer Mark. The old DOS app runs
FINE, no problems and it does have to use command.com instead of cmd.exe.

The PROBLEM is that when you open a command prompt using command.com instead
of cmd.exe, that is the point where nothing echos back to the screen -- in
the command window ITSELF, not with any specific program. Does this sched
any more light on things? Again whatever you type at the command.com command
prompt (c:\>dir) "dir" does not echo back until you press enter. THEN
whatever command you have typed executes, gives standard output, and the
command "dir" previously unviewable shows up.

Thanks for all you guys help.

Art

 

[Mark V]

DOH!!! I apologize for not making this clearer Mark. The old DOS
app runs FINE, no problems and it does have to use command.com
instead of cmd.exe.

The PROBLEM is that when you open a command prompt using
command.com instead of cmd.exe, that is the point where nothing
echos back to the screen -- in the command window ITSELF, not with
any specific program. Does this sched any more light on things?
Again whatever you type at the command.com command prompt
(c:\>dir) "dir" does not echo back until you press enter. THEN
whatever command you have typed executes, gives standard output,
and the command "dir" previously unviewable shows up.

Oh. My mis-understanding. Sorry to have veered.

Anyway, other than checking the command.pif I have no ideas.
I'd look at not just Colors, but Fonts as well.

Any difference in FullScreen mode?

Any change if you alter any video settings? (Like hardware
Acceleration)...I am fishing now.

Please post the eventual resolution (you will find it eventually!).

 

[Art Armfield]

Oh. My mis-understanding. Sorry to have veered.

Anyway, other than checking the command.pif I have no ideas.
I'd look at not just Colors, but Fonts as well.

Any difference in FullScreen mode?

Any change if you alter any video settings? (Like hardware
Acceleration)...I am fishing now.

Please post the eventual resolution (you will find it eventually!).

Mark and all:

Thanks for all your suggestions. It would seem that Windows has a little
problem with DOS commands and programs (edit among others) and it is
specifically with processors with speeds over 2Ghz in speed. SP4 addresses
this issue and cures it. Here's the MS KB article:

http://support.microsoft.com/?id=320694

Thanks,

Art Armfield

 

[Mark V]

In microsoft.public.win2000.cmdprompt.admin Art Armfield wrote:

[ ]

Mark and all:

Thanks for all your suggestions. It would seem that Windows has a
little problem with DOS commands and programs (edit among others)
and it is specifically with processors with speeds over 2Ghz in
speed. SP4 addresses this issue and cures it. Here's the MS KB
article:

http://support.microsoft.com/?id=320694

Thanks Art for the resolution follow-up and link!