Sign in with
Sign up | Sign in
Your question

NTVDM 100% CPU Utilization

Last response: in Windows XP
Share
Anonymous
a b à CPUs
August 18, 2005 11:03:05 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

When I am trying to execute an 16-bit application the ntvdm process gets a
value of 100%.

Will something help this situation?

Thanks!
Anonymous
a b à CPUs
August 18, 2005 5:15:12 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

Troubleshooting MS-DOS-based programs in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;314106



--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
>
> Thanks!
Anonymous
a b à CPUs
August 19, 2005 5:37:01 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

Thanks, i will check it out and i will reply to you.

"Wesley Vogel" wrote:

> Troubleshooting MS-DOS-based programs in Windows XP
> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
>
>
>
> --
> Hope this helps. Let us know.
>
> Wes
> MS-MVP Windows Shell/User
>
> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
> >
> > Thanks!
>
>
Related resources
Anonymous
a b à CPUs
August 22, 2005 9:31:22 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

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
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
> >
> >
> >
> > --
> > Hope this helps. Let us know.
> >
> > Wes
> > MS-MVP Windows Shell/User
> >
> > In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
> > CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
> > >
> > > Thanks!
> >
> >
Anonymous
a b à CPUs
August 22, 2005 12:55:09 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

Here are some things to look at.

Long PATH Environment Variable Causes 16-bit Apps to Hang
http://support.microsoft.com/default.aspx?scid=kb;[LN];169171

[[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?
http://www.jsifaq.com/SUBC/tip1200/rh1227.htm

Problems with 16bit apps
http://www.jsifaq.com/SUBA/tip0100/rh0151.htm

Increasing the environment memory available to DOS programs
http://www.jsifaq.com/SUBA/tip0000/rh0047.htm

See info about dpakbd.com
http://groups.google.com/group/alt.os.windows-xp/browse...

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
http://support.microsoft.com/default.aspx?scid=kb;en-us;220155

Look through other posts about NTVDM 100% CPU usage
http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...


--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
CoSNikO! <CoSNikO@discussions.microsoft.com> 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
>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
>>>
>>>
>>>
>>> --
>>> Hope this helps. Let us know.
>>>
>>> Wes
>>> MS-MVP Windows Shell/User
>>>
>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
>>>>
>>>> Thanks!
Anonymous
a b à CPUs
August 24, 2005 1:03:03 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

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
> http://support.microsoft.com/default.aspx?scid=kb;[LN];169171
>
> [[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?
> http://www.jsifaq.com/SUBC/tip1200/rh1227.htm
>
> Problems with 16bit apps
> http://www.jsifaq.com/SUBA/tip0100/rh0151.htm
>
> Increasing the environment memory available to DOS programs
> http://www.jsifaq.com/SUBA/tip0000/rh0047.htm
>
> See info about dpakbd.com
> http://groups.google.com/group/alt.os.windows-xp/browse...
>
> 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
> http://support.microsoft.com/default.aspx?scid=kb;en-us;220155
>
> Look through other posts about NTVDM 100% CPU usage
> http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...
>
>
> --
> Hope this helps. Let us know.
>
> Wes
> MS-MVP Windows Shell/User
>
> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
> >>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
> >>>
> >>>
> >>>
> >>> --
> >>> Hope this helps. Let us know.
> >>>
> >>> Wes
> >>> MS-MVP Windows Shell/User
> >>>
> >>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
> >>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
> >>>>
> >>>> Thanks!
>
>
Anonymous
a b à CPUs
August 24, 2005 10:30:03 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

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
run.

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
http://www.microsoft.com/resources/documentation/window...

Using DOS Emulation
http://www.pcguru.plus.com/xpguide/dosemulation.htm

Application Compatibility Tools in Windows XP
http://www.microsoft.com/windowsxp/using/setup/expert/h...

To set up two shortcuts for an MS-DOS program
http://www.microsoft.com/resources/documentation/window...

To create or change a program information file (PIF)
http://www.microsoft.com/resources/documentation/window...

To allocate system resources for an MS-DOS-based program and change its idle
time
http://www.microsoft.com/resources/documentation/window...

To create custom startup files for an MS-DOS-based program that may require
a special configuration
http://www.microsoft.com/resources/documentation/window...

To specify custom startup files for MS-DOS-based programs
http://www.microsoft.com/resources/documentation/window...

To open an MS-DOS program from a command prompt window
http://www.microsoft.com/resources/documentation/window...

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:0A8E4FD2-5EDE-43E2-AEED-5986EC14D1BA@microsoft.com,
CoSNikO! <CoSNikO@discussions.microsoft.com> 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
>> http://support.microsoft.com/default.aspx?scid=kb;[LN];169171
>>
>> [[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?
>> http://www.jsifaq.com/SUBC/tip1200/rh1227.htm
>>
>> Problems with 16bit apps
>> http://www.jsifaq.com/SUBA/tip0100/rh0151.htm
>>
>> Increasing the environment memory available to DOS programs
>> http://www.jsifaq.com/SUBA/tip0000/rh0047.htm
>>
>> See info about dpakbd.com
>>
http://groups.google.com/group/alt.os.windows-xp/browse...
>>
>> 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
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;220155
>>
>> Look through other posts about NTVDM 100% CPU usage
>> http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...
>>
>>
>> --
>> Hope this helps. Let us know.
>>
>> Wes
>> MS-MVP Windows Shell/User
>>
>> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hope this helps. Let us know.
>>>>>
>>>>> Wes
>>>>> MS-MVP Windows Shell/User
>>>>>
>>>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
>>>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
>>>>>>
>>>>>> Thanks!
Anonymous
a b à CPUs
August 31, 2005 4:07:01 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

I tried anything you suggested. Nothing helps the situation. This application
still takes 1 minute to complete the transfer through the com port.

"Wesley Vogel" wrote:

> 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
> run.
>
> 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
> http://www.microsoft.com/resources/documentation/window...
>
> Using DOS Emulation
> http://www.pcguru.plus.com/xpguide/dosemulation.htm
>
> Application Compatibility Tools in Windows XP
> http://www.microsoft.com/windowsxp/using/setup/expert/h...
>
> To set up two shortcuts for an MS-DOS program
> http://www.microsoft.com/resources/documentation/window...
>
> To create or change a program information file (PIF)
> http://www.microsoft.com/resources/documentation/window...
>
> To allocate system resources for an MS-DOS-based program and change its idle
> time
> http://www.microsoft.com/resources/documentation/window...
>
> To create custom startup files for an MS-DOS-based program that may require
> a special configuration
> http://www.microsoft.com/resources/documentation/window...
>
> To specify custom startup files for MS-DOS-based programs
> http://www.microsoft.com/resources/documentation/window...
>
> To open an MS-DOS program from a command prompt window
> http://www.microsoft.com/resources/documentation/window...
>
> --
> Hope this helps. Let us know.
>
> Wes
> MS-MVP Windows Shell/User
>
> In news:0A8E4FD2-5EDE-43E2-AEED-5986EC14D1BA@microsoft.com,
> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
> >> http://support.microsoft.com/default.aspx?scid=kb;[LN];169171
> >>
> >> [[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?
> >> http://www.jsifaq.com/SUBC/tip1200/rh1227.htm
> >>
> >> Problems with 16bit apps
> >> http://www.jsifaq.com/SUBA/tip0100/rh0151.htm
> >>
> >> Increasing the environment memory available to DOS programs
> >> http://www.jsifaq.com/SUBA/tip0000/rh0047.htm
> >>
> >> See info about dpakbd.com
> >>
> http://groups.google.com/group/alt.os.windows-xp/browse...
> >>
> >> 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
> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;220155
> >>
> >> Look through other posts about NTVDM 100% CPU usage
> >> http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...
> >>
> >>
> >> --
> >> Hope this helps. Let us know.
> >>
> >> Wes
> >> MS-MVP Windows Shell/User
> >>
> >> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
> >> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
> >>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Hope this helps. Let us know.
> >>>>>
> >>>>> Wes
> >>>>> MS-MVP Windows Shell/User
> >>>>>
> >>>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
> >>>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
> >>>>>>
> >>>>>> Thanks!
>
>
Anonymous
a b à CPUs
August 31, 2005 4:28:16 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

What is the name of your 16-bit application?

Some 16-bit apps just plain are not going to work correctly when running on
XP.

Why don't you see if there is a newer version of your program that is
written for Windows XP?

[[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.]]

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:69D6849B-67ED-4ACE-B1F7-6B46929BAFF8@microsoft.com,
CoSNikO! <CoSNikO@discussions.microsoft.com> hunted and pecked:
> I tried anything you suggested. Nothing helps the situation. This
> application still takes 1 minute to complete the transfer through the com
> port.
>
> "Wesley Vogel" wrote:
>
>> 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 run.
>>
>> 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
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> Using DOS Emulation
>> http://www.pcguru.plus.com/xpguide/dosemulation.htm
>>
>> Application Compatibility Tools in Windows XP
>>
http://www.microsoft.com/windowsxp/using/setup/expert/h...
>>
>> To set up two shortcuts for an MS-DOS program
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> To create or change a program information file (PIF)
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> To allocate system resources for an MS-DOS-based program and change its
>> idle time
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> To create custom startup files for an MS-DOS-based program that may
>> require
>> a special configuration
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> To specify custom startup files for MS-DOS-based programs
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> To open an MS-DOS program from a command prompt window
>>
http://www.microsoft.com/resources/documentation/window...
>>
>> --
>> Hope this helps. Let us know.
>>
>> Wes
>> MS-MVP Windows Shell/User
>>
>> In news:0A8E4FD2-5EDE-43E2-AEED-5986EC14D1BA@microsoft.com,
>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
>>>> http://support.microsoft.com/default.aspx?scid=kb;[LN];169171
>>>>
>>>> [[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?
>>>> http://www.jsifaq.com/SUBC/tip1200/rh1227.htm
>>>>
>>>> Problems with 16bit apps
>>>> http://www.jsifaq.com/SUBA/tip0100/rh0151.htm
>>>>
>>>> Increasing the environment memory available to DOS programs
>>>> http://www.jsifaq.com/SUBA/tip0000/rh0047.htm
>>>>
>>>> See info about dpakbd.com
>>>>
>>
http://groups.google.com/group/alt.os.windows-xp/browse...
>>>>
>>>> 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
>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;220155
>>>>
>>>> Look through other posts about NTVDM 100% CPU usage
>>>>
http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...
>>>>
>>>>
>>>> --
>>>> Hope this helps. Let us know.
>>>>
>>>> Wes
>>>> MS-MVP Windows Shell/User
>>>>
>>>> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
>>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
>>>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hope this helps. Let us know.
>>>>>>>
>>>>>>> Wes
>>>>>>> MS-MVP Windows Shell/User
>>>>>>>
>>>>>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
>>>>>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
>>>>>>>>
>>>>>>>> Thanks!
Anonymous
a b à CPUs
September 5, 2005 4:51:02 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

It is a custom medical application and it is not supported so i can not find
a newer version. I must use windows 98 that are not supported by Microsoft to
continue using this application. I would like to send it to you but i think
that you would not figure out what i mean because the problem exists in
conjuction with a medical machine.

"Wesley Vogel" wrote:

> What is the name of your 16-bit application?
>
> Some 16-bit apps just plain are not going to work correctly when running on
> XP.
>
> Why don't you see if there is a newer version of your program that is
> written for Windows XP?
>
> [[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.]]
>
> --
> Hope this helps. Let us know.
>
> Wes
> MS-MVP Windows Shell/User
>
> In news:69D6849B-67ED-4ACE-B1F7-6B46929BAFF8@microsoft.com,
> CoSNikO! <CoSNikO@discussions.microsoft.com> hunted and pecked:
> > I tried anything you suggested. Nothing helps the situation. This
> > application still takes 1 minute to complete the transfer through the com
> > port.
> >
> > "Wesley Vogel" wrote:
> >
> >> 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 run.
> >>
> >> 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
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> Using DOS Emulation
> >> http://www.pcguru.plus.com/xpguide/dosemulation.htm
> >>
> >> Application Compatibility Tools in Windows XP
> >>
> http://www.microsoft.com/windowsxp/using/setup/expert/h...
> >>
> >> To set up two shortcuts for an MS-DOS program
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> To create or change a program information file (PIF)
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> To allocate system resources for an MS-DOS-based program and change its
> >> idle time
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> To create custom startup files for an MS-DOS-based program that may
> >> require
> >> a special configuration
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> To specify custom startup files for MS-DOS-based programs
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> To open an MS-DOS program from a command prompt window
> >>
> http://www.microsoft.com/resources/documentation/window...
> >>
> >> --
> >> Hope this helps. Let us know.
> >>
> >> Wes
> >> MS-MVP Windows Shell/User
> >>
> >> In news:0A8E4FD2-5EDE-43E2-AEED-5986EC14D1BA@microsoft.com,
> >> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
> >>>> http://support.microsoft.com/default.aspx?scid=kb;[LN];169171
> >>>>
> >>>> [[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?
> >>>> http://www.jsifaq.com/SUBC/tip1200/rh1227.htm
> >>>>
> >>>> Problems with 16bit apps
> >>>> http://www.jsifaq.com/SUBA/tip0100/rh0151.htm
> >>>>
> >>>> Increasing the environment memory available to DOS programs
> >>>> http://www.jsifaq.com/SUBA/tip0000/rh0047.htm
> >>>>
> >>>> See info about dpakbd.com
> >>>>
> >>
> http://groups.google.com/group/alt.os.windows-xp/browse...
> >>>>
> >>>> 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
> >>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;220155
> >>>>
> >>>> Look through other posts about NTVDM 100% CPU usage
> >>>>
> http://www.google.com/search?hl=en&q=NTVDM+100%25+CPU&b...
> >>>>
> >>>>
> >>>> --
> >>>> Hope this helps. Let us know.
> >>>>
> >>>> Wes
> >>>> MS-MVP Windows Shell/User
> >>>>
> >>>> In news:EFA15830-D74C-49BA-9A17-4DB39C695EC2@microsoft.com,
> >>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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
> >>>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;314106
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Hope this helps. Let us know.
> >>>>>>>
> >>>>>>> Wes
> >>>>>>> MS-MVP Windows Shell/User
> >>>>>>>
> >>>>>>> In news:C2F6C601-573D-44B6-8388-DD3A636812CD@microsoft.com,
> >>>>>>> CoSNikO! <CoSNikO@discussions.microsoft.com> 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?
> >>>>>>>>
> >>>>>>>> Thanks!
>
>
!