Open Handle in one Process and Close in another? [Win32 API]

Prev: The project BIEW was renamed into BEYE
Next: web automation issue

From: Jonathan de Boyne Pollard on 26 Feb 2010 03:38

From: David F. on 26 Feb 2010 05:29

I guess it depends on the type of handle:

"64-bit versions of Windows use 32-bit handles for interoperability. When
sharing a handle between 32-bit and 64-bit applications, only the lower 32
bits are significant, so it is safe to truncate the handle (when passing it
from 64-bit to 32-bit) or sign-extend the handle (when passing it from
32-bit to 64-bit). Handles that can be shared include handles to user
objects such as windows (HWND), handles to GDI objects such as pens and
brushes (HBRUSH and HPEN), and handles to named objects such as mutexes,
semaphores, and file handles."

From http://msdn.microsoft.com/en-us/library/aa384203(VS.85).aspx

"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups(a)NTLWorld.COM> wrote
in message

news:IU.D20100226.T083821.P9445.Q0(a)J.de.Boyne.Pollard.localhost...
So everything I've read seems to suggest that Handles are global in Windows
space and even between x64 and x32 processes.
You haven't read nearly enough. Start with the MSDN Libary discussion of
kernel objects.

From: rogero on 26 Feb 2010 09:08

On Feb 26, 10:29 am, "David F." <df2...(a)community.nospam> wrote:
> I guess it depends on the type of handle:

It depends more on how it is created.

If you create a handle with inheritable attributes it is passed down
to the child process using the same handle value. However, each
process actually has its own handle to the same underlying kernel
object and each process must explicitly or implicitly close the handle
before the underlying object is released.

Simply passing the handle value to another process does not enable the
handle to be used by the other process -- in general this value may
even be a genuine handle in the target process but not to the same
object.

Example:

parentProcess.exe:

HANDLE h1 = OpenMutex(MUTEX_ALL_ACCESS, TRUE, "Global\\RogerOrr");
CreateProcess("childProcess.exe", ...)

childProcess.exe:
will be created with an already open handle to the mutex with the same
numeric value as h1.

siblingProcess:
HANDLE h2 = OpenMutex(MUTEX_ALL_ACCESS, TRUE, "Global\\RogerOrr");

h2 may or may not have the same numeric value as h1.

HTH,
Roger.

From: Jonathan de Boyne Pollard on 26 Feb 2010 18:02

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:A954CF83-3185-4207-BDD2-BA153C4FD2CB(a)microsoft.com"
type="cite">
maybe it was just windows handles or for older windows versions?
</blockquote>
No.  Remember that I pointed you to the MSDN Library discussion of
kernel objects?  You asked in the <code>microsoft.public.win32.programmer.kernel</code>
newsgroup, and answers relevant to kernel object handles are
what you are receiving from people posting there.  Other types of
objects are user and GDI objects (for which there are <a
href="news:///microsoft.public.win32.programmer.gdi">other</a> <a
href="news:///microsoft.public.win32.programmer.ui">newsgroups</a>). 
As I said, you need to read much more stuff, such as the remainder of
the "Handles and Objects" section of the MSDN Library that you've
already been pointed to, and <a
href="http://techinterviews.com./windows-programming-interview-questions">this</a>
(to pick one WWW page at random).
</body>
</html>

From: m on 27 Feb 2010 14:29

This excerpt is discussing the behaviour of GDI to ensure interoperability
between 32-bit and 64-bit processes on the same desktop without Windows
acting as a proxy for the 32-bit applications. As you may know, GDI handles
(window handles / HWND, etc.) are not kernel object handles and are not
processes specific. They were once machine global, and are now desktop
specific for security reasons. The design goes back to cooperative
multi-tasking in Win16 and allows are the desktop level UI communication (ie
mouse clicks, keystrokes, clipboard etc.). Kernel object handles do not
reference UI elements, but objects maintained by the kernel like files,
threads, and events. These handles are process specific and act as
references to the underling kernel object. When a process terminates, the
OS will close any open handles that that process might have, allowing it to
cleanup any objects that might have been abandoned by a faulty application
(by contrast UI elements represented by GDI handles are cleaned up when the
owning thread terminates).

based on your other post, I assume that you are trying to pass a volume
handle. This is a kernel object handle and so you must either:
1) open a new handle to the same named object in the second process; or
2) use DuplicateHandle
in both cases, Windows handles 32 / 64 bit issues for you.

"David F." <df2705(a)community.nospam> wrote in message
news:E0195B4A-D9EE-4469-99A3-21406785E111(a)microsoft.com...
> I guess it depends on the type of handle:
>
> "64-bit versions of Windows use 32-bit handles for interoperability. When
> sharing a handle between 32-bit and 64-bit applications, only the lower 32
> bits are significant, so it is safe to truncate the handle (when passing
> it from 64-bit to 32-bit) or sign-extend the handle (when passing it from
> 32-bit to 64-bit). Handles that can be shared include handles to user
> objects such as windows (HWND), handles to GDI objects such as pens and
> brushes (HBRUSH and HPEN), and handles to named objects such as mutexes,
> semaphores, and file handles."
>
> From http://msdn.microsoft.com/en-us/library/aa384203(VS.85).aspx
>
>
> "Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups(a)NTLWorld.COM>
> wrote in message
>
> news:IU.D20100226.T083821.P9445.Q0(a)J.de.Boyne.Pollard.localhost...
> So everything I've read seems to suggest that Handles are global in
> Windows space and even between x64 and x32 processes.
> You haven't read nearly enough. Start with the MSDN Libary discussion of
> kernel objects.

|
Pages: 1
Prev: The project BIEW was renamed into BEYE
Next: web automation issue