All of the 16-bit Windows applications are run by default as separate threads in a single process named NTVDM (NT virtual DOS machine.) This process is known as the WOW subsystem, which stands for Windows-16 on Windows-32. This architecture permits 16-bit applications to share the address space the same way they did under 16-bit Windows. It is illustrated in Figure 3.27.
Figure 3.27 16-bit Windows applications on Windows NT
If you want to run a 16-bit application in its own address space, you can use Program Manager to set the application to "Run In a Separate Memory Space," or you can start the application using the /separate option on the start command.
The default single address space architecture obscures Performance Monitor's measurement of these applications in two ways. First, the name of all such applications is that of the single process, NTVDM. Second, if you have two or more such applications running, it is hard to tell them apart because they are identified only by thread number inside that NTVDM.
It can require a little disciplined experimenting to determine which thread is which application. The NTVDM process that handles 16-bit Windows applications is started automatically when Windows NT starts. Before starting any 16-bit applications, use Performance Monitor to look at the NTVDM to see how many threads it has initially. Figure 3.28 shows such a report.
Figure 3.28 16-bit Windows NTVDM before application execution
Now let's start another thread, 16-bit Excel. Here's what we see as a result:
Figure 3.29 16-bit Excel in the WOW NTVDM
There is not room in the illustration for all the threads, so we show the last four. The last two are new. Thread 4, with ID Thread 114, is actually Excel. We can tell this because it is looping. We might as well 'fess up now: this is a bug (oh, no!) in 16-bit Excel 4.0, which causes it to consume processor cycles needlessly under some conditions, one of which is startup. (Because of the Windows NT preemptive multitasking ability, this looping activity is not a problem. Just put Excel in the background and carry on.) Notice the high Context Switch rate of Thread 4. Excel is talking to CSRSS (which is not shown here). Moving the focus to Excel and away again removes the loop. Figure 3.30 shows Excel in the NTVDM after it has stopped looping. (Of course the next version of Excel will not do this. By the way, this bug in Excel was discovered with Windows NT Performance Monitor.)
Figure 3.30 16-bit Excel has calmed down now
Looking at Figure 3.30 you can see that the elapsed times for Threads 4 and 5 are shorter than those of 2 and 3 because the application was started after WowExec was executed. This is another clue about which application thread is which in the WowExec NTVDM. Now let's stop Excel and look at what changes.
Figure 3.31 16-bit Excel has stopped
Can you see that ID Thread 114 is gone now? Notice that Thread 4 is still there, but it is now the thread that was Thread 5 before (its ID Thread is still 49). In Performance Monitor, threads are named sequentially, starting with 0. If one in the middle disappears, the numbers of following threads decrease. So you should use ID Thread to make a positive identification. Because ID Thread numbers get reused, they won't be proof positive, but they do last for the life of the thread, at least. In this example, there is no longer a Thread 5, as indicated by its zeroed counters. Performance Monitor continues to search for any instance selected for measurement, but if an instance cannot be found, its counters are all set to zero.
You can use the PView tool to stop the WowExec NTVDM if you want to get a fresh start on identifying 16-bit Windows applications. Be sure to stop the NTVDM with at least 4 threads! Other NTVDMs run separate 16-bit Windows or non-Windows MS-DOS® applications, as we'll discuss shortly. You can restart the WowExec NTVDM by using CTRL+ESC to bring up Task Manager, pressing TAB to get to the Run box, and entering wowexec. WowExec will also start automatically when you run the first 16-bit Windows application.
In Figure 3.32 we show what happens if we start 16-bit Excel again. Here you'll see a new Thread 5 with ID Thread 163. Notice that the ID Thread is not 114 as before. The ID Thread assignments appear somewhat arbitrary. But here, as long as we keep Excel alive, it will retain the ID Thread 163.
Figure 3.32 WowExec NTVDM threads after restarting 16-bit Excel
Okay, let's start another application. We have a copy of 16-bit Word for Windows handy, so we'll fire that up.
Figure 3.33 WowExec NTVDM threads after starting Excel and Word for Windows
So we see the new Thread 6 with ID Thread 114. This must be Word for Windows. By looking at Thread: Elapsed Time, we can tell which thread belongs to which application.
You get the idea. By executing or stimulating the application of interest and watching the reaction in Performance Monitor, you can isolate which WowExec NTVDM thread is executing its code. From that point until you exit the application, you have a positive identification of the thread.