hInstance Differences Under Win 3.1 and Win32 PlatformsPSS ID Number: Q103644Article Last Modified on 07-12-2000 -------------------------------------------------------------------------------- The information in this article applies to: Microsoft Win32 Software Development Kit (SDK)-------------------------------------------------------------------------------- Summary In 16-bit Windows (Win16) applications running on Windows 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 a 32-bit Windows (Win32) application runs in its own address space, instance handles cannot be used to uniquely identify an instance of an application running on the system. This article explains why, and includes some alternative calls that might assist in uniquely identifying an Win32 application instance. 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. Additional query words: Keywords: kbOSWinNT kbOSWin2000 kbGrpDSUser kbOSWin Issue Type: kbinfo Technology: kbWin32SDKSearch kbAudDeveloper kbSDKSearch kbWin32sSearch
我在一个Exe程序里，对同一个Dll我想同时加载多个，并且这多个加载的对象之间的数据互不影响，能做到吗？
多谢
因为接触Dll不深，所以不明白问题在哪，请教各位帮忙
我跟了一下，两次LoadLibrary得到的HINSTANCE地址是一样的，这个是正常的吗？
HINSTANCE相同是十分正常的事
两次相同,表明你加载逻辑位置相同
如下就不会相同了:
A进程:
LoadLibrary("Adll.dll");B进程:
LoadLibrary("Bdll.dll");
LoadLibrary("Adll.dll");注:在DLLMAIN入口的参数是共享的,用于加载,引用,释放,消毁,一般不要改动
其它就是共享段,楼上都讲了
--------------------------------------------------------------------------------
The information in this article applies to: Microsoft Win32 Software Development Kit (SDK)--------------------------------------------------------------------------------
Summary
In 16-bit Windows (Win16) applications running on Windows 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 a 32-bit Windows (Win32) application runs in its own address space, instance handles cannot be used to uniquely identify an instance of an application running on the system. This article explains why, and includes some alternative calls that might assist in uniquely identifying an Win32 application instance. 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. Additional query words: Keywords: kbOSWinNT kbOSWin2000 kbGrpDSUser kbOSWin
Issue Type: kbinfo
Technology: kbWin32SDKSearch kbAudDeveloper kbSDKSearch kbWin32sSearch