INFO: hInstance Differences Under Win 3.1 and Win32 Platforms (103644)

MORE INFORMATION

Although the concepts for an instance handle are similar between Win32 and Win16, the results you see regarding them might be very different from what you expect.

With Win16, when you start several instances of the same application, they all share the same address space. You have multiple instances of the same code segment. However, each of these instances has a unique data segment associated with it. Using an instance handle (hInstance) is a way to uniquely identify these different instances and data segments in the address space.

Instance handles are unique to the address space. On Windows NT, when looking at the value of the instance handle, or the value returned from GetWindowLong(hWnd, GWL_HINSTANCE), a developer coming from a Win16 background might be surprised to see that most of the windows on the desktop return the same value. This is because the return value is the hInstance for the instance of the application, which is running it its own address space. (An interesting side note: The hInstance value is the base address where the application's module was able to load: either the default address or the fixed up address.)

In Win32, running several instances of the same application causes the instances to start and run in their own separate address space. To emphasize the difference: multiple instances of the same application on Windows 3.1 run in the same address space; in Win32 applications running on Windows NT or Windows 9x, each instance has its own, separate address space. Using an instance handle to uniquely identify an application instance, as is possible in Win16, does not apply in Win32. (Another interesting side note: Remember that even if there are multiple instances of an application, if they are able to load at their default virtual address spaces, the virtual address pages of the different applications' executable code will map to the same physical memory pages.)

In Win32, instance handles are not unique in the global scope of the system; however, window handles, thread IDs, and process IDs are. Here are some calls that may assist in alternative methods to uniquely identify instance of applications on Windows NT:

• GetWindowThreadProcessID() retrieves the identifier of the thread that created the given window and, optionally, the identifier of the process that created the window.
• OpenProcess() returns a handle to a process specified by a process ID.
• GetCurrentProcessID() returns the calling process's ID.
• EnumThreadWindows() returns all of the windows associated with a thread.
• The FindWindow() function retrieves the handle of the top-level window specified by class name and window name.
• Windows NT only: To enumerate all of the processes on the system, you can query the Registry using RegQueryValueEx() with key HKEY_PERFORMANCE_DATA, and the Registry database index associated with the database string "Process".
• Windows NT 4.0 only: To enumerate all of the processes on the system, you can use the EnumProcesses PSAPI function. See the Platform SDK documentation for more information on EnumProcesses
• Windows 95 and later, Windows 2000 and later: To enumerate all of the processes on the system, you can use the 32-bit Toolhelp APIs. See the Platform SDK documentation on the following APIs: CreateToolhelp32Snapshot, Process32First, and Process32Next

For further details on using these calls, please see the Platform SDK documentation.