What was Microsoft thinking in: handle to the application's instance?
Author
I can''t understand why microsoft thought they needed a handle to the application''s instance while creating a window. The second to last parameter of the CreateWindowEx function asks for this, and I just can''t understand its purpose.
/*
HWND CreateWindowEx(
DWORD dwExStyle, // extended window style
LPCTSTR lpClassName, // registered class name
LPCTSTR lpWindowName, // window name
DWORD dwStyle, // window style
int x, // horizontal position of window
int y, // vertical position of window
int nWidth, // window width
int nHeight, // window height
HWND hWndParent, // handle to parent or owner window
HMENU hMenu, // menu handle or child identifier
HINSTANCE hInstance, // handle to application instance
LPVOID lpParam // window-creation data
);
*/
Platform SDK, Windows User Interface reference has the following under Instance Handle:
Instance Handle
Every window class requires an instance handle to identify the application or .dll that registered the class. The system requires instance handles to keep track of all of modules. The system assigns a handle to each copy of a running executable or .dll.
The system passes an instance handle to the entry-point function of each executable (see WinMain) and .dll (see DllMain). The executable or .dll assigns this instance handle to the class by copying it to the hInstance member of the WNDCLASSEX structure.
Windows 95/98/Me: Multiple instances of the same application or .dll use the same code segment, but each has its own data segment. The system uses an instance handle to identify the data segment that corresponds to a particular instance of an application or .dll.
---
I guess that microsoft realize that a handle to the application''s instance was useless for the creation of a window, and for the registration of a windows class, and because of these, NT, 2000 and XP ignore this parameter. I''m not an experienced programmer; actually I''m not even in college, so I don’t know what to think about this. I might be wrong in this thinking and that is why I summit this to the experts.
I did some experimentation, with an application that consists of two dlls and one exe, but this could be done with one dll and one exe. I registered my window classes in the dll, with the dll instance and then I created some windows in the dll, with the dll''s instance; it worked. Then I tried creating the windows and registering the window classes in the same dll, but this time using the exe''s instance for both; it worked. Don’t know which of these is the correct, or optimal way to do it. Don’t know how I should do it, or what aspects I should consider to decide such issue.
Please summit some information about application’s instances and advice about how I should continue with my project.
thx
Diego Mendieta
Have you tried registering and creating the windows in the dll and then unloading the dll?
Colin Jeanne | Invader''s Realm
"I forgot I had the Scroll Lock key until a few weeks ago when some asshole program used it. It even used it right" - Conner McCloud
Colin Jeanne | Invader''s Realm"I forgot I had the Scroll Lock key until a few weeks ago when some asshole program used it. It even used it right" - Conner McCloud
I think Invader X is right. Because module handles are reference counted, the window needs to add a reference to the module that contains the window proc for the window. Else when you unload the module, the window proc points into nowhere land.
Actually, the hInstance holds the address where the program file is loaded into the memory space of the process - typically 0x00400000 for .exes. It varies for dlls, but they are always loaded on 64 kb boundaries.
The hInstance parameter isn''t so important in regards to registering window classes and creating windows - the exe hInstance works just as well as the dll because the dll is loaded into the address space of the process - in which the exe hInstance takes priority.
Where hInstances play a much more important role is in loading resources. As I started off saying, the hInstance holds the address where the module is loaded into the memory space of the process. The various resource manipulation api''s take advantage of this by using pointer arithmetic to parse the pe file header ("pe" is the name of the exe/dll file format) to locate the resources stored in the exe or dll. So, if there are resources in the dll that you want to access, use the hInstance for that dll rather that for the exe.
HINSTANCE and HMODULE are equivalent. The typename HINSTANCE is a relic from Win16 but the underlying functionality is still relevant in Win32.
The hInstance parameter isn''t so important in regards to registering window classes and creating windows - the exe hInstance works just as well as the dll because the dll is loaded into the address space of the process - in which the exe hInstance takes priority.
Where hInstances play a much more important role is in loading resources. As I started off saying, the hInstance holds the address where the module is loaded into the memory space of the process. The various resource manipulation api''s take advantage of this by using pointer arithmetic to parse the pe file header ("pe" is the name of the exe/dll file format) to locate the resources stored in the exe or dll. So, if there are resources in the dll that you want to access, use the hInstance for that dll rather that for the exe.
HINSTANCE and HMODULE are equivalent. The typename HINSTANCE is a relic from Win16 but the underlying functionality is still relevant in Win32.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
