Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

64-bit and 32-bit COM exe server registration

696 views
Skip to first unread message

Andy McMullan

unread,
Mar 11, 2010, 10:16:08 AM3/11/10
to
The MSDN documentation for the PreferredServerBitness registry setting says
that it is used to decide whether COM will activate a 32-bit or 64-bit
version of a COM exe server. For example it says things like "for a 32-bit
client COM will activate a 32-bit server if available, otherwise it will
activate a 64-bit version of the server".

But in the registry it only seems to be possible to register a single
server, via the LocalServer32 setting. So that single server will either be
32-bit or 64-bit. How can COM 'choose' whether to launch the 32-bit or
64-bit version of the server, if only one exe is registered?

The MSDN doc is here:
http://msdn.microsoft.com/en-us/library/ms694319%28VS.85%29.aspx

Thanks

Igor Tandetnik

unread,
Mar 11, 2010, 11:10:26 AM3/11/10
to

Andy McMullan <dyl...@newsgroups.nospam> wrote:
> The MSDN documentation for the PreferredServerBitness registry
> setting says that it is used to decide whether COM will activate a
> 32-bit or 64-bit version of a COM exe server. For example it says
> things like "for a 32-bit client COM will activate a 32-bit server if
> available, otherwise it will activate a 64-bit version of the server".
>
> But in the registry it only seems to be possible to register a single
> server, via the LocalServer32 setting. So that single server will
> either be 32-bit or 64-bit. How can COM 'choose' whether to launch
> the 32-bit or 64-bit version of the server, if only one exe is
> registered?

As I understand it, HKEY_CLASSES_ROOT\CLSID key itself points to different registry branches when examined by 32-bit and 64-bit process. See

http://msdn.microsoft.com/en-us/library/aa384253.aspx

So there are actually two LocalServer32 values, one in 32-bit branch of the registry and another in 64-bit branch.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

Andy McMullan

unread,
Mar 12, 2010, 9:01:01 AM3/12/10
to

"Igor Tandetnik" wrote:

> As I understand it, HKEY_CLASSES_ROOT\CLSID key itself points to different registry branches when examined by 32-bit and 64-bit process. See
>
> http://msdn.microsoft.com/en-us/library/aa384253.aspx
>
> So there are actually two LocalServer32 values, one in 32-bit branch of the registry and another in 64-bit branch.

Thanks, but as I understand it that only applies to in-proc servers (i.e.
DLLs). The documentation you point to says for CLSID:

"Redirected and reflected only for CLSIDs that do not specify InprocServer32
or InprocHandler32."

In other words for out of proc servers that use LocalServer32 (rather than
InprocServer32) the CLSID key is redirected and reflected, meaning that it is
effectively shared across the 32-bit and 64-bit registries.

Wilson, Phil

unread,
Mar 12, 2010, 1:51:46 PM3/12/10
to
Just to state the obvious, COM doesn't care because the RPC has no bitness
when the 32-bit client calls the 64-bit exe server or vice versa. Just
register one and it will reflect to both places and be called by both
bitness clients.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


"Andy McMullan" <dyl...@newsgroups.nospam> wrote in message
news:221BD508-2283-46C0...@microsoft.com...

Andy McMullan

unread,
Mar 12, 2010, 5:49:01 PM3/12/10
to
> Just to state the obvious, COM doesn't care because the RPC has no bitness
> when the 32-bit client calls the 64-bit exe server or vice versa. Just
> register one and it will reflect to both places and be called by both
> bitness clients.

Right, that's what I assumed, but it doesn't seem to quite work like that.
If I have a 64-bit server running, and a 32-bit client tries to connect, COM
will not service the call through the running server, but instead launch a
new instance of the server. It will only connect to the running server if I
specify CLSCTX_ACTIVATE_64_BIT_SERVER in the CoCreate on the client.

Reading about CLSCTX_ACTIVATE_64_SERVER led me to the PreferredServerBitness
flag, at which point I realised that the documentation for
PreferredServerBitness didn't make any sense to me because it talks about
choosing between a 32-bit and 64-bit server, and I can't see any way to have
both registered, so I can't see how COM can 'choose'.

Wilson, Phil

unread,
Mar 16, 2010, 12:59:20 PM3/16/10
to
All I can think of is that this paragraph from the docs might be relevant:

"Usually, a client will not care whether it uses a 32-bit or a 64-bit
version of the server. However, if the server itself loads an additional
in-process server, then it and the in-process server must both be either
32-bit or 64-bit. For example, suppose that the client wants to use a server
"A", which in turn loads an in-process server "B". If only a 32-bit version
of server "B" is available, then the client must specify the 32-bit version
of server "A". If only a 64-bit version of server "B" is available, then the
client must specify the 64-bit version of server "A". "

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


"Andy McMullan" <dyl...@newsgroups.nospam> wrote in message

news:BAD4E3C3-8D0A-488B...@microsoft.com...

0 new messages