DOS App 4-5 x Slower in WIN2K than WIN98

[RH610]

Have tried standard things like playing with the PIF and
control.nt and autoexec.nt; windowed vs. full-screen; among others. Are there any diagnostic tools that can trace WHY this DOS app is running so slow on WIN2K compared to WIN98? I am out of ideas.

Thanks

 

[Quetzalcoatl]

Remember one thing. Win98 is still over DOS and Win2K is other platform. Win2k makes an emulation to run DOS programs. Maybe thats the problem.

 

[RH610]

Yes. I suppose that must be it. I guess my only thought is that one would think that the DOS emulation on a Pentium 4/1.6g with a modern O/S like WIN2K would have been a little bit better than that. Oh, well.....

Thanks for the tip.

 

[donnie4564]

There is a file called config.nt that can be used like config.sys in win98. This file is at winnt\sys32 and
winnt\repair. Make changes to both files. You might try adding a line to this file... buffers=50
Also Dos Apps use NTVDM. If there are more than one 16 bit app running this could slow you down, but you can edit the reg to force each app to use seperate threads.

HKLM\SYSTEM\CurrentControlSet\Control\WOW
Data type Range Default value
REG_SZ yes | no no
Description
Determines the default mode for running 16-bit Windows applications. On Windows 2000, 16-bit applications can run as separate threads in a shared NTVDM process, or each can run in a separate NTVDM process.
Value Meaning
yes By default, 16-bit Windows applications run in a separate process.
no By default, 16-bit Windows applications run as threads in the NTVDM process.

Typically, 16-bit applications are run in a separate process to improve their performance. When sharing a process, only one 16-bit application can run at a time; all other threads of the NTVDM process are blocked. Also, it is easier to monitor an application when it is running in a separate process.

 

[RH610]

Thanks for the tips. Unfortunately, they had no effect. YOu know, I've been in this business for over 20 years and I've seen a lot of goofiness, but even I am beginning to wonder what the heck is going on around here. I've just gotten powerful new PCs for our business with a powerful new O/S because some of our software requires it. Yet I've got to keep old, "downgraded" PCs around because the new, powerful stuff runs our DOS software (which we still need) much slower. I must downgrade MS Office on other machines because certain software that this group uses requires Word2000 specifically, even though Word 2002 now comes on new PCs. I have to wait to upgrade other software because it will not work with other software which has not been updated yet, etc. etc. etc. Seems to be getting worse by the day. It's enough to make me want to retire to the funny farm.

Thanks Again for your help.

 

[Silmarillion]

Have you checked the processor useage when the app is running? We had a similar problem with our accounting system (happens on NT and W2K, but not on Win9x) where it would push the processor useage to 100%, even when it wasn't doing anything. After trying to get help from our software vendor (they had been running it for a few years on NT 4 and knew it was slower, but never bothered to figure out what it was doing or why), I gave up on them and did some of my own research. I found a program at

http://www.tamedos.com

that addresses this issue specifically. It didn't fix the problem at first go, but I e-mailed them and he had it going with a couple of command line switches in no time. His response was very quick, and the price is cheap (under US$20/seat). I have been testing it on a couple of machines for a while now, and it doesn't seem to cause any problems. You can download an eval if you want to test it (unrestricted version).

Hope this helps. )

 

[RH610]

Thanks for the tip Silmarillion, but my app's CPU useage is not pegged at 100% (it's about a 7 -10% average), thus I don't think the TAME product would help in this case. As QuetzalCoatl said, the WIN2K DOS emulation simply does a bad job with this application.

 

[Guest_imported]

I had an aplication made with Qbasic 4.5 that have the same problem: the letters are shown in screen slowly, but the graphics are very high speed. This is over w2000. All others systems are normally (95, 98 Nt. Me, ...)

The aplication can be obtained for study on

http://vigas.start.at/

 

[Guest_imported]

This is a display problem that win2000 has with 16 bit applications. It has nothing to do with emulation or any processor settings. You can demonstrate the problem by simply bringing up the DOS editor and noticing how jerky the keys reflect back to the keyboard. In full screen mode it smooths out. I hammered Microsoft support on this in January and they spent a week trying to find a solution. Then they found that it was inherent in win2000 and gave up. They are not going to fix it, leaving those of us with old but excellent DOS applications stuck on win98. Sorry about that.

 

[Guest_imported]

I'm sorry that I can't add any help to this question. All I can do is ask for help on a similar problem. We have a payroll application called Kronos that is DOS based and lives on a Novell server. It runs in a DOS window on our Wind95/98 workstations.

We are currently upgrading all our PC's to new Windows 2000 pro machines.
Nobody in the World has managed to get this DOS app to run on a Win2000 PC. The vendor sells a Windows version for many tens of thousands of dollars. More than we can afford.

I have installed the Windows 2000, DOS compatability files from Microsoft. And, now as soon as I run the .bat file on the server the app. starts and the login screen appears on my Screen, this is good. Then Once I hit the <enter> key after entering my password, it takes 6 minutes before the executable runs. Once it is loaded to my PC after those first 6 minutes, it runs as fast as it did on our Win95 PC's.
The problem is that this application is a series of executables, and every one takes 6 minutes to start, then they all run fast inside each module.

Any help or suggestions would be appreciated.

 

[dcsi]

I've yet to see an explanation for the cause of this. I have had this CPU utilization problem on a DOS app for years - I have been unable to find the TRUE CAUSE. I know we are all having the same problem. From all my research, it's like a mouse/keyboard polling problem. There should be a fix for this - many of us will never give up these programs for a variety of reasons. Has anyone found a way to stop NTVDM and WOW from hogging all the CPU time?

 

[dcsi]

By the way - you'll have the same problem with XP home/Pro.

 

[zelman]

One thing you may want to try for slow DOS apps on Windows is exiting ALL virus checking software. Not just disabling, mind you, that won't always do it. Good luck!

 

[dcsi]

Been there.....There's much more to it than that.

 

[NJcow]

To lower CPU usage, point the PIF to any .EXE file. Open properties then point command and working lines to appropriate .BAT's or .EXE's. Then under misc., change Idle Sensitivity to FULL. This is a decent quick-fix to CPU usage problem.

 

[Guest_imported]

My problem is: When I try to run a DOS System in Windows 2000 Professional, It show me the message &quot;16 BITS SUBSYSTEM MS-DOS, SISTEMA.EXE, CPU NTVDM FOUND A NOT ALLOWED INSTRUCTION&quot; and don't run the DOS System.

What can I do to run my DOS system ?

Thank you !

 

[avangoch]

You didn't by any chance &quot;upgrade&quot; your server from Novell to Microsoft at the same time, did you? If your app is a database app there are definate performance issues migrating from Novell to NT/2K. You can check MS knowledge base for articles on it, but for us the core issue was not resolved: our apps were &quot;dos commit&quot;-happy. Novell could fake out a commit-to-disk request and cache it, but NT won't return until every byte is physically on the disk. Long programming story there, which I won't bother you with if you don't already know it. We wound up re-working the programs to minimize necessary commits.

 

[Guest_imported]

The notion that Windows XP cannot run DOS apps for some technical reason is poppycock. They just did a lousy job with the DOS support.

I am running VMWARE in WIndows 2000 Professional, and have Windows XP running as a virtual machine, and Windows 98, Windows ME etc.

The ONLY one that produces the 100% CPU usage when running some DOS apps is Windows XP.

VMWARE does a better job virtualizing a machine (which is what NTVDM is supposed to do New Technology Virdual Dos Machine) - a complete windows machine, or Linux machine or DOS box, than does Microsoft, our Multi-Billion dollar software monopoly that is dong all these great things for the public.

Microsoft is the problem, it's their attempt to kill DOS apps, it has nothing whatever to do with what is possible. They could have done a good job, they elected to do a bad job, or they dont' have the requisite skills to do it right, as do the people at VMWARE.

Microsoft XP is simply broken - either by incompetence, or by design, it's your guess.

PS: I only use Windows XP to find problems. I have absolutely no use for it otherwise. I don't suppose &quot;phone home&quot; spying, or Microsoft intrusions, or monopolist apologists who think Microsoft is a saviour.

 

[Guest_imported]

I think I know whats going on - are you starting the command prompt from the shortcut (hence running cmd.exe) or from typing &quot;command&quot; into the run window from 'start'? cmd.exe is _far_ faster than the command.exe. I've got a very fast responsive command prompt from this. Assigning a shortcut (such as ctrl+alt+p) to the prompt is handy as well.

Excellent tips on confif.nt and autoexec.nt - most handy!

hope this helps.

dan p

 

[Guest_imported]

I have a dos application at our bank (teller system) that works great on a dos machine with novell client. Now we have upgraded to Windows 2000. When I launch the dos application, 100% cpu useage. The system uses a btrieve engine to pull data off the server.. Not only is the app slow, but windows itself is slow.. Opening explorer or anything, installing printers while dos app is running, very very slow.. Close dos app, windows returns to normal speed. We are going to upgrade the Btrieve client to a more stable 2000 version. From all the reading here, I dont think that it will solve our 100% cpu useage problem. What else can one do to lower cpu utilization? I get no difference whether I am in a dos window or a full screen. I have not yet tried lowering the idel sensitivity. We have played around w/ all the memory/program settings on the PIF. No differences noticeable.

Thanks.