Re: NTVDM 100% CPU Utilization
- From: "Wesley Vogel" <123WVogel955@xxxxxxxxxxx>
- Date: Wed, 24 Aug 2005 18:30:03 -0600
>From various sources...
Windows does not support 16-bit programs that require unrestricted access to
hardware. If your program requires this, your program will not work in
Windows NT, Windows 2000, or Windows XP.
Note that if the program requires a virtual device driver (VxD), it will not
work properly under Windows XP.
16-bit applications that directly access hardware must supply a Windows XP
virtual device driver and a Windows XP 32-bit device driver, or they won’t
In general, 16-bit applications do not run as fast as comparable 32-bit
applications. The 16-bit programs are restricted to using a single thread,
even on a multithreaded operating system such as Windows XP. And calls made
by a 16-bit application must be translated for the 32-bit operating system.
This translation process, called thunking, adds to execution time.
Some 16-bit applications require 16-bit device drivers, which are not
supported in Windows XP. Applications that directly access hardware must
supply a Windows XP virtual device driver and a Windows XP 32-bit device
driver, or they won’t run.
Generally speaking, any program that will not run under Windows Me or which
requires a "restart in MSDOS mode" in order to run under Windows 95 or 98
will not work with Windows XP.
Also DOS programs that bypass the operating system so as to work directly
with the computer hardware will not work under Windows XP. Many games were
written this way, as were a number of communications programs and also some
specialized software program that use a program authorization plug connected
to the parallel port (a Dongle).
But there's some old software that XP won't handle: Some really, really
ancient software tries to control the PC hardware directly, bypassing the
OS. This is a trick used when machines ran at very slow speeds--- speeds
about 1/500th as fast as today's. It's not only unnecessary now, but
actually causes trouble: If an app takes over the hardware and then crashes,
it will take down everything else with it--- including the OS.
Many 16-bit programs use the Windows 3.x–vintage Win.ini and System.ini
files to store program-specific configuration information (some programs use
private .ini files as well). Windows XP retains bare-bones copies of Win.ini
and System.ini in the %SystemRoot% folder. If you encounter problems with a
16-bit application, you might find clues in these two files.
By default, Windows XP treats each running 16-bit application as a thread
within a single virtual machine. If you’re running multiple 16-bit
applications, they share a common memory space, and a crash in one Windows
3.x–based application will typically bring down all the others—causing you
to lose any unsaved information in all 16-bit applications. If you regularly
run multiple 16-bit applications and one of them hangs or crashes
frequently, you should run it in a separate memory space.
Running some MS-DOS programs properly might require that you change the
system configuration used by the MS-DOS virtual machine. Two files,
Autoexec.nt and Config.nt, serve this function in Windows XP. These two
files serve a purpose similar to that of Autoexec.bat and Config.sys in
MS-DOS and Windows 95/98, with several important differences:
• Autoexec.nt and Config.nt are located by default in the
%SystemRoot%\System32 folder. (The corresponding files on an MS-DOS or
Windows 95/98 machine are in the root folder of drive C.)
• In Windows XP (as in Windows 2000), you can create custom versions of
Autoexec.nt and Config.nt for specific applications. To associate your
custom configuration files with a specific application, copy the default
files to a separate location and edit them as needed. Next, open the
properties dialog box for the MS-DOS program, click the Advanced button on
the Program tab, and then enter the correct locations as shown below. (Note
that this dialog box includes a Compatible Timer Hardware Emulation check
box. This option imposes a performance penalty, so you should select it only
if your application won’t run with the box cleared.)
• Commands you enter in these two files affect only the MS-DOS subsystem.
Many commands, such as Buffers and Break, are ignored, although they can be
entered for compatibility purposes when an MS-DOS program insists that they
be present. Windows XP includes its own versions of Himem.sys, Ansi.sys,
Country.sys, and Setver.exe. Avoid using the following unsupported and
unnecessary Windows 95/98 drivers in Config.nt: Emm386.exe, Smartdrv.sys,
Ramdrive.sys, and Dblspace.sys/ Drvspace.sys. Windows XP ignores all entries
in Autoexec.nt except those defined by Set or Path commands, which it adds
to the startup environment for that MS-DOS virtual machine.
Compatible Timer Hardware Emulation
[[Enables MS-DOS-based programs to reduce the rate at which the computer’s
timer sends timing signals.]]
To set compatible timer hardware emulation
Using DOS Emulation
Application Compatibility Tools in Windows XP
To set up two shortcuts for an MS-DOS program
To create or change a program information file (PIF)
To allocate system resources for an MS-DOS-based program and change its idle
To create custom startup files for an MS-DOS-based program that may require
a special configuration
To specify custom startup files for MS-DOS-based programs
To open an MS-DOS program from a command prompt window
Hope this helps. Let us know.
MS-MVP Windows Shell/User
CoSNikO! <CoSNikO@xxxxxxxxxxxxxxxxxxxxxxxxx> hunted and pecked:
> Sorry i thought that cpu overhead was my problem but i was wrong.
> The utility dpakbd.com with parameters managed to reduce my cpu overhead
> by 95%. But i still have a problem.
> My 16-bit application connects with an analyser machine through COM port.
> When the application tries to take data from analyser i hear long noises
> and it takes about 1 minute to complete. With Windows 98 this procedure
> takes about 10 seconds and these sound lasts for 5 seconds.
> And something else.... When i do something wrong the application beeps
> much more longer than Windows 98.
> I hope that you have something for this?
> Thanks a lot!!!
> "Wesley Vogel" wrote:
>> Here are some things to look at.
>> Long PATH Environment Variable Causes 16-bit Apps to Hang
>> [[If this is your problems, the path is too long.
>> Shorten the path, if any, in AUTOEXEC.NT.]]
>> 16-bit app hangs and NTVDM consumes 100% of the CPU?
>> Problems with 16bit apps
>> Increasing the environment memory available to DOS programs
>> See info about dpakbd.com
>> If problems with just one 16-bit program, try www.tamedos.com and
>> download the
>> trial version it reduces cpu usage of ntvdm with dos progs.
>> Troubleshooting NTVDM and WOW Startup Errors
>> Look through other posts about NTVDM 100% CPU usage
>> Hope this helps. Let us know.
>> MS-MVP Windows Shell/User
>> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@xxxxxxxxxxxxx,
>> CoSNikO! <CoSNikO@xxxxxxxxxxxxxxxxxxxxxxxxx> hunted and pecked:
>>> This page did not provide me information about my problem.
>>> Any other ideas?
>>> "CoSNikO!" wrote:
>>>> Thanks, i will check it out and i will reply to you.
>>>> "Wesley Vogel" wrote:
>>>>> Troubleshooting MS-DOS-based programs in Windows XP
>>>>> Hope this helps. Let us know.
>>>>> MS-MVP Windows Shell/User
>>>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@xxxxxxxxxxxxx,
>>>>> CoSNikO! <CoSNikO@xxxxxxxxxxxxxxxxxxxxxxxxx> hunted and pecked:
>>>>>> When I am trying to execute an 16-bit application the ntvdm process
>>>>>> gets a value of 100%.
>>>>>> Will something help this situation?
- Re: NTVDM 100% CPU Utilization
- From: CoSNikO!
- Re: NTVDM 100% CPU Utilization