64-bit and 32-bit handles

Hi,

http://msdn2.microsoft.com/en-us/library/aa384203.aspx
"Handles to named objects such as mutexes, semaphores, and file handles can
all be shared."

Does this mean that I can use DuplicateHandle in a 64-bit process and pass
the duplicated handle truncated to 32-bits to the appropriate 32-bit process
and call DuplicateHandle in a 32-bit process and pass the duplicated handle
zero-extended to 64-bits to the appropriate 64-bit process?

Thanks for your help.

Kornél

Charlie
Sun Dec 10 12:59:14 CST 2006

Most of the regulars here are IT pros or end users, not developers (hence
the .general in the newsgroup name). So you might have better luck posting
this over on one of the MSDN forums.

--
Charlie.
http://msmvps.com/xperts64


"Kornél Pál" <anonymous@discussions.microsoft.com> wrote in message
news:eMNnZ6HHHHA.2112@TK2MSFTNGP03.phx.gbl...
> Hi,
>
> http://msdn2.microsoft.com/en-us/library/aa384203.aspx
> "Handles to named objects such as mutexes, semaphores, and file handles
> can all be shared."
>
> Does this mean that I can use DuplicateHandle in a 64-bit process and pass
> the duplicated handle truncated to 32-bits to the appropriate 32-bit
> process and call DuplicateHandle in a 32-bit process and pass the
> duplicated handle zero-extended to 64-bits to the appropriate 64-bit
> process?
>
> Thanks for your help.
>
> Kornél
>

Chris
Sun Dec 10 17:33:58 CST 2006

Interesting question.

Named objects are shared through their name, i.e. the name is unique across
all 32/64 bit procs.
This only _suggests_ that it _should be_ possible to use DuplicateHandle
where the object behind the HANDLE doesn't have an API function that allows
you to open by name.

I would suggest that you just try it, a test case should be small enough to
whip up.
As a start i would think that if DuplicateHandle returns TRUE then it works.
This implies you used a valid target proc handle and that DuplicateHandle
didn't feel it was a problem creating a handle for it.

I would expect the trunc/0-ext to work.


cmk

Chris
Sun Dec 10 17:41:23 CST 2006

Also see:

http://blogs.msdn.com/larryosterman/archive/2005/01/31/363881.aspx


cmk

Kornél
Sun Dec 10 22:01:20 CST 2006

> http://blogs.msdn.com/larryosterman/archive/2005/01/31/363881.aspx

Thanks you very much. This helped me a lot. And also thanks for your previos
comment.

Kornél

Charlie
Mon Dec 11 13:16:01 CST 2006

Thanks for proving me wrong, Chris. And please, stick around. We do get the
occasional dev questions, and I am definitely NOT the person to answer them.
:)

--
Charlie.
http://msmvps.com/xperts64


"Chris Kushnir" <ckushnir@rogers.com> wrote in message
news:eptZyOLHHHA.1188@TK2MSFTNGP06.phx.gbl...
> Interesting question.
>
> Named objects are shared through their name, i.e. the name is unique
> across all 32/64 bit procs.
> This only _suggests_ that it _should be_ possible to use DuplicateHandle
> where the object behind the HANDLE doesn't have an API function that
> allows you to open by name.
>
> I would suggest that you just try it, a test case should be small enough
> to whip up.
> As a start i would think that if DuplicateHandle returns TRUE then it
> works.
> This implies you used a valid target proc handle and that DuplicateHandle
> didn't feel it was a problem creating a handle for it.
>
> I would expect the trunc/0-ext to work.
>
>
> cmk
>
>

Chris
Mon Dec 11 15:46:01 CST 2006

No problem, i've been lurking, and answering when i can, in this group for
the last year.
I've managed to get more than i've given, but that's the point of stone
soup. :)


cmk


"Charlie Russel - MVP" <charlie@mvKILLALLSPAMMERSps.org> wrote in message
news:65C52E2B-0C9B-4771-9AED-EA8B8F63E5FA@microsoft.com...
> Thanks for proving me wrong, Chris. And please, stick around. We do get
> the occasional dev questions, and I am definitely NOT the person to answer
> them. :)
> --
> Charlie.
> http://msmvps.com/xperts64
>
>
> "Chris Kushnir" <ckushnir@rogers.com> wrote in message
> news:eptZyOLHHHA.1188@TK2MSFTNGP06.phx.gbl...
>> Interesting question.
>>
>> Named objects are shared through their name, i.e. the name is unique
>> across all 32/64 bit procs.
>> ...
>