The MASM Forum Archive 2004 to 2012

General Forums => The Workshop => Topic started by: Robert Collins on January 01, 2005, 07:42:17 AM

Title: Application Handle
Post by: Robert Collins on January 01, 2005, 07:42:17 AM
What is a handle? I mean what is it? I dont want a definition of a handle but what it is.
Title: Re: Application Handle
Post by: hutch-- on January 01, 2005, 08:27:29 AM
Robert,

The term "handle" is a generic term for a unique ID for some object. You have different types of handles, Window handles, resource handles, an Instance handle and so on. In Windows most of these "handles" are suppilied by the operating system at runtime and it is the operating systems internal method of keeping track of a massive number of different object types.

think basically "handle = unique ID"
Title: Re: Application Handle
Post by: Robert Collins on January 01, 2005, 05:11:05 PM
Sorry, hutch, that is not the answer I am looking for. You gave a definition of a handle.
Title: Re: Application Handle
Post by: Jimg on January 01, 2005, 05:55:18 PM
Can you give us an example of describing what something is without giving a definition?
Title: Re: Application Handle
Post by: russian on January 01, 2005, 06:08:15 PM
He wants to know what this unique ID number represents. I think in some cases it's the adress of a certain ressource but I'm not sure.
Title: Re: Application Handle
Post by: Robert Collins on January 01, 2005, 06:17:49 PM
Quote from: Jimg on January 01, 2005, 05:55:18 PM
Can you give us an example of describing what something is without giving a definition?

OK. Hutch gave a definition of a handle. To answer your post I will put it this way. I 'think', but not sure, that a handle is the memory location of where the application is residing in memory during it's run time. That is to say, the Windows Operating System assigns that address as the 'handle' for that window. But, like I said I am not sure. Maybe a handle is nothing more than a random number or perhaps it is the next number from a list of already generated 'handle' numbers that the OS fetches and assigns to the next window that requests it's handle.
Title: Re: Application Handle
Post by: russian on January 01, 2005, 07:15:29 PM
about your signature...what's with the cigarettes??
Title: Re: Application Handle
Post by: Robert Collins on January 01, 2005, 07:59:29 PM
Quote from: russian on January 01, 2005, 07:15:29 PM
about your signature...what's with the cigarettes??

I shouldn't reply to that question since it has nothing to do with the topic but just because you asked I will. It's just an old cliche that was used quite often amoung Assembler programmers when cigarettes were not the topic of so much controversial. I remenber in my first assembly shop that it was quite common to see programmers with a cup of coffee in one hand and a cigarette in the other. There was probably one or two non-smokers out of ten to twenty people in the programming department. I'm sure it doesn't apply anymore.
Title: Re: Application Handle
Post by: donkey on January 01, 2005, 08:48:47 PM
In some cases a handle is a memory location, for example the module handle is the actual memory location of the module. However some handles have nothing to do with memory, for example a file handle may be simply 60, it is normally less than 32768 at any rate, GDI handles do not point to GDI memory, for example a Bitmap handle does not point to the position in memory where the bitmap is stored. So Hutch was right, it is simply a unique way of identifying an object and depending on the version of Windows, the type of object and a few other factors may or may not point to an actual location in memory.
Title: Re: Application Handle
Post by: Robert Collins on January 01, 2005, 09:02:44 PM
Quote from: donkey on January 01, 2005, 08:48:47 PM
In some cases a handle is a memory location, for example the module handle is the actual memory location of the module. However some handles have nothing to do with memory, for example a file handle may be simply 60, it is normally less than 32768 at any rate, GDI handles do not point to GDI memory, for example a Bitmap handle does not point to the position in memory where the bitmap is stored. So Hutch was right, it is simply a unique way of identifying an object and depending on the version of Windows, the type of object and a few other factors may or may not point to an actual location in memory.

Yes, he was correct in his definition of a handle. I think I was asking about the handle of an application (the program itself) and not so much about file handles or a bitmap, since neither a file or a bitmap is an application. I think you answered my question when you stated "the module handle is the actual memory location of the module". I kind of thought that was it but I just wasn't sure.

Thank you. You resolved my curriosity.
Title: Re: Application Handle
Post by: hutch-- on January 01, 2005, 11:37:06 PM
I am a little wary of the response when the question in the first place was very general.
Quote
What is a handle? I mean what is it? I dont want a definition of a handle but what it is.
When I answered you that the term is used for a range of tasks, I have simply told you something that is a matter of fact. The distinction between "definition" and "what it is" is at best ill defined and under pressure collapses down to the same thing. Your question states "handle" in the singular in the form of an abstract so the response in the singular form is "unique ID supplied by the operating system".

Keep in mind that the Campus is for questions and answers, not "Quiz Show" style topics. Our members and moderators put in a reasonable amount of work to help people in the Campus and the Campus is set aside for tasks other than debate so I am moving this topic into the Workshop where it beter suits general discussion.
Title: Re: Application Handle
Post by: Robert Collins on January 01, 2005, 11:47:37 PM
Sorry about that, hutch. I know that the question was somewhat vague but I didn't know how else to state it. I also gathered by the responces that I didn't come accross very well with the original question.  ::)   
Title: Re: Application Handle
Post by: Statix Star on January 01, 2005, 11:56:11 PM
The life of the world makes mistakes, you can see a bad dog destroying anything but if you apply discipline, he will stop. After he learnt his lessons.
Title: Re: Application Handle
Post by: Kestrel on January 02, 2005, 04:27:27 PM
Handle like ID, ID like Handle.

but (at Windows System):

Handle: Allocated by System.
ID: Defined by Coder.
Title: Re: Application Handle
Post by: Statix Star on January 05, 2005, 10:03:15 PM
Quote from: russian on January 01, 2005, 07:15:29 PM
about your signature...what's with the cigarettes??
smoking herbs once two weeks is not too bad and it helps you to; calm your nerves. Coffee so they don't sleep they could probably
not sleep during night and study. Is not really healthy not sleeping, the best to calm your nerves is with exercise.
Title: Re: Application Handle
Post by: sluggy on January 08, 2005, 07:36:10 AM
Quote from: Robert Collins on January 01, 2005, 09:02:44 PMI think you answered my question when you stated "the module handle is the actual memory location of the module". I kind of thought that was it but I just wasn't sure.

Thank you. You resolved my curriosity.
You should treat this as coincidental that MS uses the module's base address as its handle, they could change this method anytime in the future. As hutch said, a handle is just a handle, it only has meaning to the functions that know how to use it.
Title: Re: Application Handle
Post by: donkey on January 08, 2005, 09:13:51 AM
Hi Sluggy,

The hInstance=Base Address is not really co-incidental, it was done by design and though the label is now meaningless, I doubt it will ever change. This quote is from MSJ...

QuoteFor the sake of convenience, Windows NT and Windows 95 uses the base address of a module as the module's instance handle (HINSTANCE).
...
In Win32, applications don't need to be distinguished from one another because they don't share the same address space. Still, the term HINSTANCE persists to keep continuity between 16-bit Windows and Win32. What's important for Win32 is that you can call GetModuleHandle for any DLL that your process uses to get a pointer for accessing the module's components.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndebug/html/msdn_peeringpe.asp