[vbox-dev] Difficulty of Distributing 3rd party Windows apps based on VBoxPython

Martin Simmons martin at lispworks.com
Mon Sep 12 05:23:28 PDT 2011

>>>>> On Fri, 09 Sep 2011 20:27:14 +0200, Klaus Espenlaub said:
> On 04.08.2011 10:32, Grigory Petrov wrote:
> > On 02.08.11 15:08, Alexey Eromenko wrote:
> >>> This is result of unfortunate feature of MSCOM, related to
> >>> cross-bitness COM calls.
> >> Could VBox project provide 32-bit COM interfaces on Windows 64-bit ?
> >> (in addition to current 64-bit COM)
> > I agree. A well-behaved inproc COM server should provide both 64-bit and
> > 32-bit interfaces on 64-bit windows. Making VirtualBox more well-behaved
> > will greatly increase it's popularity in areas where automation is
> > required. And it's not hard to implement.
> Just wasted a lot of time searching through MSDN and not finding 
> anything useful. Found even claims 
> (http://msdn.microsoft.com/en-us/library/ms810720.aspx) that our rather 
> simple interfaces should work without trouble with both 32bit and 64bit 
> clients. Which is not correct according to Alexey.
> Also, just to get this right: most of our API is not provided by an 
> "inproc" server, but by a "local" server, implemented by VBoxSVC.exe. 
> This server has LOTS of local state, and at the moment I can't even 
> imagine how 32bit and 64bit interfaces could possibly cooperate in such 
> a server. Leave alone that I found no way to tell MIDL about any bitness.
> Any hints are appreciated - I may have missed something totally obvious.

COM uses rpc for "local" servers, so cross-bitness can work (see

Moreover, if the VirtualBox interfaces are compatible with Automation (it
looks like they are), then the standard marshaling provided by Ole32.dll
should do everything without the need for special stubs/proxies.

Perhaps Nikolay can give more information about the unfortunate feature.


More information about the vbox-dev mailing list