Serialize HANDLE
-
You got a smile so bright, You know you could have been a candle. I'm holding you so tight, You know you could have been a handle. Smokey Robinson, "The Way You Do the Things You Do" From the point of view of implementation, a handle under Windows is always realized in one of two categories: 1.An offset into a table that is being maintained by either the executive or a subsystem component. 2.A virtual address in the address space of a process. :confused:
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.commessenger :suhredayan@hotmail.com
-
You got a smile so bright, You know you could have been a candle. I'm holding you so tight, You know you could have been a handle. Smokey Robinson, "The Way You Do the Things You Do" From the point of view of implementation, a handle under Windows is always realized in one of two categories: 1.An offset into a table that is being maintained by either the executive or a subsystem component. 2.A virtual address in the address space of a process. :confused:
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.commessenger :suhredayan@hotmail.com
1.An instance handle is a pointer to the image of an executable file in a client process. 2.A resource handle as obtained by FindResource and LoadResource is a pointer to that process within the image. 3.A handle returned from VirtualAlloc or HeapCreate is a pointer to the beginning of the memory block in the client's address space. 4.A handle returned from HeapAlloc is a pointer into the chunk of memory allocated by 3. 5.A GDI handle is a relative offset into a table located in the client's address space. 6.A USER handle is a relative offset into a table located in the server's address space. 7.A handle to a native Windows NT object is a relative offset into a table located in system space. There are several of those tables—one per process and a few tables maintained by the system. 8.A USER object itself is located in the server's address space. 9.In the case of resources, 8 still holds true, but just as in 2, the resource is referenced through a memory-mapped image of the file that holds the executable, only the image resides in the server's address space this time. This is the scenario you encounter, for example, when calling LoadIcon. 10.The data structures that describe native Windows NT objects reside in system address space. Depending on the object type, part of the object may also be located in a process's address space. (This holds true, for example, for section objects.) 11.The data that describes a GDI object resides in the client's address space. Please also observe the restriction mentioned earlier in this article under "How the Subsystem Realizes Window GDI Objects."
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.commessenger :suhredayan@hotmail.com
-
You got a smile so bright, You know you could have been a candle. I'm holding you so tight, You know you could have been a handle. Smokey Robinson, "The Way You Do the Things You Do" From the point of view of implementation, a handle under Windows is always realized in one of two categories: 1.An offset into a table that is being maintained by either the executive or a subsystem component. 2.A virtual address in the address space of a process. :confused:
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.commessenger :suhredayan@hotmail.com