1

Is the hInstance parameter there to tell the main-method that the code within is only valid for instance xy of the application.

So if I open WORD twice and minimize one of the windows, the SAME main-function is called, but by means of the hInstance parameter, the two instances of WORD are kept apart?

And the same would go for any other function that needs an hInstance parameter.

Thanks for corrections and help!

Liam Gallagher
  • 170
  • 1
  • 9
user3813234
  • 1,580
  • 1
  • 29
  • 44
  • 1
    You're having an [XY problem](http://meta.stackexchange.com/questions/66377/), where Y is _"I need to know what the hInstance does"_ (which is explained [here](http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559.aspx), [here](http://msdn.microsoft.com/en-us/library/windows/desktop/ff381406.aspx) and [here](http://stackoverflow.com/questions/13871617/)). Can you explain your original problem X, so you can get the answer you need? And no, for each process a new instance of your executable is loaded, so no, it's not the same code (as in: the same memory location) that is executed. – CodeCaster Jan 16 '15 at 15:07
  • 1
    No, that's not right at all. It's just the `HMODULE` of the process executable file. – David Heffernan Jan 16 '15 at 15:15
  • 5
    You need to get a newer book. The book you have was written for 16-bit Windows. – Raymond Chen Jan 16 '15 at 15:22
  • 1
    Well, the original problem was just: Why do I need to pass a hInstance to functions? And the texts I read gave me the impression that I was to achieve what I describe in my question. But I obviously misunderstood that quite a bit :D – user3813234 Jan 16 '15 at 17:04
  • 1
    Why didn't you ask that question? – David Heffernan Jan 16 '15 at 20:15
  • Well,I chose the other approach: Telling what I know and then seeing if it's correct... sometimes easier than formulating a question – user3813234 Jan 16 '15 at 21:11
  • 1
    The hInstance parameter to WinMain() only exists for backwards compatibility with 16-bit Windows. Feel free to ignore it completely. (Additional: Windows itself does not pass hInstance to the program. It is the C runtime library which looks up the value of hInstance and passes it to WinMain.) – Harry Johnston Jan 17 '15 at 00:11
  • 1
    Ah okay, but with the other functions, the hInstance must be passed for the reasons ElderBug explained, right? – user3813234 Jan 17 '15 at 10:29

1 Answers1

2

Not really. Instances of a same program are kept apart by virtual memory. Each instance has no mean (except with specific api calls) to access the other's memory, they are totally isolated.

HINSTANCE is just a handle to identify your application for others WINAPI calls. But actually, it is not even to identify your application from other instances, but to identify it from others applications executable files inside your applications, like DLLs (a DLL inside your app will have its own HINSTANCE, usually given as a HMODULE, which is the same). If you run your program twice, the HINSTANCE may be the same for both.

As a side note, HINSTANCE is actually a pointer to the memory image of the executable file. Therefore you can do printf("%s\n",hInstance);, and it will always print MZ? (? depends on your locale), because a windows executable file always starts with "MZ\x90\x00".

ElderBug
  • 5,926
  • 16
  • 25
  • 1
    ah, so it is more like: I make a winAPI call and for that called code to know, which instance it was called by, I pass it the hInstance? So to differentiate whether the code was call by my program or by a dll I use? – user3813234 Jan 16 '15 at 17:02
  • 1
    @user3813234 Actually, it's more to identify the executable inside a process. The OS manage the processes, it already knows what process and executable makes the calls. HINSTANCE/HMODULE is for calls that have something to do with specific executables, like `GetProcAddress` (get a proc address from a specific executable inside the app), or `FindResource` (find a ressource from a specific executable). These two API calls need the HINSTANCE because it target a specific executable. Most WINAPI calls have no HINSTANCE parameter. – ElderBug Jan 16 '15 at 17:15
  • Specific executable is a bad choice. Specific module is what counts. Each module has its own resource namespaces. Hence functions that take resource names need also to be told which module to search. – David Heffernan Jan 16 '15 at 20:18
  • 1
    @DavidHeffernan Well no, a module IS an executable file in memory. That's why you have `GetModuleFileName`. Module doesn't really mean anything if you don't know beforehand, so I'm using the equivalent 'executable file'. – ElderBug Jan 16 '15 at 20:38
  • The DLLs in the process are all modules with their own module handles. Don't make up terminology. We use executable for the first module in the process. The one with the entry point. – David Heffernan Jan 16 '15 at 20:42
  • 1
    @DavidHeffernan What ????? I'm not making up terminology. Are you saying DLLs are not executable files ? I'm sorry but the whole internet disagree with you. A DLL is a PE file, like EXE. Portable Executable. Even wikipedia will tell you that an executable is something that contains code. Nothing about entry points (and DLL have entry points). – ElderBug Jan 16 '15 at 20:53
  • We use the term executable for modules that have the process entry point, and DLL for the other modules. There's a big difference. Try passing an executable filename to LoadLibrary. Or a DLL to CreateProcess. If you think that there is no difference between an executable file and a DLL then there's no point in us continuing the conversation. – David Heffernan Jan 16 '15 at 20:58
  • 1
    @DavidHeffernan Of course a DLL is not RUNNABLE. Using 'executable' for something you can double-click on is valid, but the term 'executable file' can be used for ANY file that contain code. That's the definition you find most of the time (read the wikipedia page). Denying that is just silly. I'm not telling you your definition is wrong. And btw, you can use LoadLibrary on an EXE. – ElderBug Jan 16 '15 at 21:14
  • 1
    @DavidHeffernan I'm curious about the terminology you use to refer to files that will have a HMODULE ? – ElderBug Jan 16 '15 at 21:17
  • I'd call them PE files. You yourself note that the asker is lacking in detailed knowledge. The lay person will think of a .exe file when you say executable. I've made my point. Whether you agree or not. It's fine for us to disagree. – David Heffernan Jan 16 '15 at 21:19
  • 4
    @ElderBug: A DLL can be resource-only and contain no executable code at all. Would you still call it an executable? – Jonathan Potter Jan 17 '15 at 03:10
  • 1
    @JonathanPotter A DLL can't be resource only. The entry point is not optional. Linkers allow you to omit it, but actually add an empty stub. So a DLL can't "contain no executable code". It's exactly the same as saying an EXE can be resource only. And please, it's not my terminology, even the file format of DLL is called Portable Executable. – ElderBug Jan 17 '15 at 12:50
  • 2
    @ElderBug: The entry-point is optional. For example, aero.msstyles is a resource-only DLL, that contains resources for use by the Aero theme. There is absolutely zero code in this DLL. Open it up in Dependency Walker, and you will see for yourself. You could also read the image headers and observe the same. It's called *resource-only* for a reason. – IInspectable Jan 17 '15 at 21:54
  • 1
    @IInspectable aero.msstyles is not a DLL. It doesn't have a dll extension and won't load with LoadLibrary. Because a valid DLL need an entry point. The entry point is NOT optional (it's only optional in the code, because linkers provide one). The DLL flag in the header is just a convention to prevent running it. Stop arguing, it's a fact, DLL MUST contain executable code. Now you are right, PE are not only for EXE and DLL. And of course using 'executable' for runnable is valid. My point was just that if it contains code, you can call it executable, and its a common terminology. – ElderBug Jan 17 '15 at 22:20
  • 2
    @ElderBug: A DLL is not required to have a particular extension. aero.msstyles **is** a DLL file, and it will load with `LoadLibraryEx`. You cannot load a resource-only DLL using `LoadLibrary`. A *resource-only* DLL does not have an entry point, and is not required to contain code (`dumpbin /SECTION:.text aero.msstyles`). Or simply follow [Creating a Resource-Only DLL](http://msdn.microsoft.com/en-us/library/24b2tcy0.aspx), and observe that no .text section is present. In other words: **no** code. – IInspectable Jan 17 '15 at 22:28
  • @IInspectable "Resource only DLL" is not a DLL. It's just binary resource file. By your logic, you can call ANY binary file a "DLL". Database, memory dump, etc. – ScienceDiscoverer Jun 28 '22 at 12:17
  • @sci A resource-only DLL **is** a DLL. It doesn't use an arbitrary binary file format, but rather the PE(+) file format, like any other DLL. That is distinctly different from database files, memory dumps, etc. A resource-only DLL simply doesn't have a `.text` section, like executable images. – IInspectable Jun 28 '22 at 16:25
  • @IInspectable But nothing prevents me from using the PE format for storing database or memory dumps. Anyway, this debate was pointless from the beginning. One side is arguing that it's okay to call that a dll because it uses the PE format (PE being in itself a misnomer, since it's not always executable), which is defendable in a sense. On the other side I was arguing that it's not because it's not a library, in the code sense, let alone dynamic-link, since there is no code to link against. It's not the first or last time terms diverge from their original meaning so whatever. – ElderBug Jun 28 '22 at 17:41
  • Of course one can argue that linking and library don't always refer to code, but that's not the primary meaning. – ElderBug Jun 28 '22 at 17:46
  • *"But nothing prevents me from using the PE format for storing database or memory dumps."* - Well, coming up with an entry point would make it somewhat of a poor choice to use the PE format as a dump container. Since, as you might recall, *you* insist that *any* DLL **must** have an entry point (which, quite frankly, is provably wrong). But then, I take it, you aren't very much interested in facts rather than pushing your opinions through. – IInspectable Jun 29 '22 at 08:29