Differences Between hInstance on Win 3.1 and Windows NT

Last reviewed: November 2, 1995
Article ID: Q103644
The information in this article applies to:
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT versions 3.5 and 3.51
        - Microsoft Windows 95 version 4.0
    

SUMMARY

In Microsoft Windows version 3.1, an instance handle can be used to uniquely identify the instance of an application because instance handles are unique within the scope of an address space. Because each instance of an application runs in its own address space on Windows NT, instance handles cannot be used to uniquely identify an instance of an application running on the system. This article explains why, and some alternative calls that might assist in uniquely identifying an application instance on Windows NT.

MORE INFORMATION

Although the concepts for an instance handle are similar on Windows NT and Windows 3.1, the results you see regarding them might be very different from what you expect.

With Windows 3.1, 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 Windows 3.1 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.)

On Windows NT, 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 Windows NT, each instance has its own, separate address space. Using an instance handle to uniquely identify an application instance, as is possible on Windows 3.1, does not apply in Windows NT. (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 Windows NT, 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.
  • 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".

For further details on using these calls, please see the Win32 SDK help file.


Additional reference words: 3.10 3.50 3.51 4.00 95
KBCategory: kbui
KBSubcategory: UsrMisc


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: November 2, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.