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

[Martin Simmons]

>>>>> 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
http://msdn.microsoft.com/en-us/library/ms692621%28v=vs.85%29.aspx).

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.

__Martin