WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] - نسخه متنی

Chris Aschauer

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Monitoring Legacy Applications


For optimal performance, it is recommended that all applications you run under Windows 2000 be 32-bit. However, if you need to continue using 16-bit Windows or MS-DOS-based applications, this section describes how you can monitor their activity.

Monitoring 16-bit Windows Applications


In Windows 2000, by default, all active 16-bit Windows applications run as separate threads in a single multithreaded process called NT Virtual DOS Machine (NTVDM). The NTVDM process simulates a 16-bit Windows environment complete with all of the DLLs called by 16-bit Windows applications.

This configuration poses two challenges for running 16-bit applications:


    It prevents 16-bit applications from running simultaneously, which might impede their performance.

    It makes monitoring a bit trickier because 16-bit applications do not appear by name in the Add Counters dialog box for the performance tools; instead, they appear as undistinguishable NTVDM processes.


As a result, Windows 2000 includes an option to run a 16-bit application in its own separate NTVDM process with its own address space. You can monitor 16-bit Windows applications by identifying them by their thread identifier (ID) while they are running, or by running each application in a separate address space.

In addition to the 16-bit applications, each NTVDM process includes a heartbeat thread that interrupts every 55 milliseconds to simulate a timer interrupt, and the Wowexec.exe thread, which helps to create 16-bit tasks and to handle the delivery of the 16-bit interrupt. This thread supports 16-bit Windows applications in a 32-bit Windows environment. The WOW subsystem provides an NTVDM where all Win16 applications run. You will see the heartbeat and Wowexec threads when monitoring 16-bit applications.

Only one 16-bit Windows application thread in an NTVDM can run at one time and, if an application thread is preempted, the NTVDM always resumes with the same thread. This limits the performance of multiple 16-bit applications running in the same NTVDM process, although this limitation becomes an issue only when the processor is busy.

Because 16-bit applications run in the same process, monitoring more than one 16-bit application can be tricky. You need to distinguish among the threads of the NTVDM process.

To monitor one 16-bit application, select the NTVDM process in System Monitor. (Other performance tools used to monitor processes can be used for monitoring the NTVDM process. For more information, see "Analyzing Processor Activity" in this book.) If you have multiple 16-bit processes running in NTVDM, you can distinguish them by their thread identifiers (IDs). You might have to start and stop the 16-bit process to determine which ID is associated with which 16-bit process.

Figure 27.13 shows a System Monitor report on a single NTVDM process. The ID Process and ID Thread counters are included to help you distinguish among the threads. One of the threads is the heartbeat thread, one is the Wowexec thread, and one is a 16-bit application.


Figure 27.13 NTVDM Threads in System Monitor

System Monitor identifies threads by the process name and a thread number. The thread numbers are ordinal numbers (beginning with 0) that represent the order in which the threads started. The thread number of a running thread changes when a thread with a lower number stops, and all threads with higher numbers move up in order to close the gap. For example, if thread 1 stops, thread 2 becomes thread 1. Therefore, thread numbers are not reliable indicators of thread identity.

Instead, with System Monitor you can track processes and threads using the process IDs and thread IDs. The process ID identifies the process in which the thread runs. The thread ID identifies the thread. Unlike the thread number, which can change over the time the thread runs, the system assigns the thread ID when the thread starts and retains it until the thread stops.

As shown in Figure 27.14, Task Manager makes it easy to identify 16-bit applications because it displays the names of the executable files indented below the NTVDM process name. To monitor 16-bit processes in Task Manager, click the Processes tab, and on the Options menu, click Show 16-bit Tasks.


Figure 27.14 MyApp, Wowexec, and Ntvdm on the Task Manager Process Tab

In this example, you can see the Wowexec (Windows on Windows) and the MyApp threads. The heartbeat thread is not an executable and does not appear as a process in Task Manager. However, the Thread Count column on the far right shows that all threads are running in the NTVDM process.

Running 16-bit Windows Applications in a Separate Process


Windows 2000 lets you opt to run a 16-bit Windows application in a separate, unshared NTVDM process with its own memory space. This eliminates competition between NTVDM threads in a single process, making the 16-bit application thread fully multitasking and preemptive. It also simplifies monitoring.

To run a 16-bit application in its own address space


    At the command prompt, type:

    start /separate processname


In Task Manager and System Monitor, two instances of the NTVDM process appear. You can use their process identifiers to distinguish between them. Figure 27.15 shows NTVDM threads with process identifiers.


Figure 27.15 NTVDM Instances in Task Manager with Process Identifiers

Figure 27.15 shows Task Manager monitoring two copies of a 16-bit application, each in its own NTVDM process.

Monitoring MS-DOS Applications


In Windows 2000, each MS-DOS application runs in its own NTVDM process, eliminating some of the problems encountered in 16-bit Windows applications. All of the NTVDM processes are called Ntvdm.exe by default, but you can use the following procedure to change the name for easier tracking.

To create a new process name for an NTVDM process


    Copy Ntvdm.exe to a file with a different name.

    Change the value of the cmdline entry in HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlWOW to the name of your copy of Ntvdm.exe. The default value is systemrootSystem32Ntvdm.exe.

    When you start an MS-DOS application, it will run in a process with that name. Figure 27.16 shows how your edited process name appears in Regedt32.



Figure 27.16 New Process Name in Regedt32

TIP


You do not have to restart the computer for the registry change to take effect. Thus, you can change the registry between starting different MS-DOS applications and have each start in a uniquely named process. It is also prudent to set the process name back to Ntvdm.exe when you are finished.

If you are not satisfied with the performance of your MS-DOS-based applications in Windows 2000, try changing the following settings, accessed by right-clicking the file in Windows Explorer:


    Under Usage in Screen properties for the .pif file, select Full-Screen to speed up video display performance. Press ALT+ENTER to get in and out of full-screen mode.

    Disable the Compatible Timer Hardware Emulation feature in the _Default.pif or the application's program information file (PIF). To disable it, clear the check box displayed when you click the Windows NT button under Program properties for the file. Because this feature causes a decrease in performance, use it only if it is required to allow an application to run under Windows 2000.

    If the application is in a window and seems to pause periodically, try reducing idle sensitivity by moving the Idle Sensitivity slider to the left in Misc properties for the application's .pif.

    If the MS-DOS-based application can be configured for printing, choose LPT1 or LPT2 rather than parallel port. Most of the applications use Int17 to print when configured for LPT. If you select parallel port mode, these applications print directly to printer ports. Parallel mode is significantly slower in Windows 2000 compared to Windows 3.x.


/ 335