[vbox-dev] Possibly non-documented incompatibility 4.x -> 5.0

Klaus Espenlaub klaus.espenlaub at oracle.com
Mon Jul 27 08:50:28 GMT 2015


On 25.07.2015 01:03, Maxime Dor wrote:
> Hi,
> It looks like in 5.0 the ISession::console attribute is no longer
> created under a Shared or Write lock, but only on a VM lock.
> In previous versions of VirtualBox, the console was always available
> regardless of the lock type.

Yes, but the sub-objects of IConsole were already all NULL for non-VM 
locks previously. Since everything worth using by a non-VM API client 
has been moved out of IConsole in 5.0 I'm a but surprised that this 
causes inconvenience.

> This change is not documented in the SDK where you would expect it:
> - IConsole class description
> - ISession class description

Negative documentation is generally considered bad style. In this case I 
really don't see the need, as in 5.0 there is absolutely nothing in 
IConsole which should be used by a "normal" API client. If there's no 
need to use IConsole, why should the attribute be non-NULL?

> - Main API change log

 From my perspective the first bullet item in the change log describes 
everything vital for someone who needs to adjust API clients.

Could you explain a bit more what kind of (for me unexpected) issues you 
ran into?

> The only info is in the ISession::console attribute description.
> Is this change expected? Or are there other subtleties in play?

This change is entirely expected, and is the long awaited final step 
which makes it possible to e.g. take, delete or restore snapshots from a 
32 bit API client on a 64 bit host (which often sabotaged people who 
wanted to use the python API binding on Windows).

Previously this was impossible as it was only implemented in the 64 bit 
variant of the corresponding library which lives in the client process.

It also created the paradoxical situation that the (now moved) 
operations were not implemented by the API service in VBoxSVC, but were 
effectively offered by the first API client which happened to be there 
(so if the VM manager GUI happened to have a session open for a specific 
VM, it would e.g. be responsible for handling snapshot operations, which 
could easily fail if it went away shortly after).

In many ways it's the long awaited correction of a very very old API 
design flaw.


> Thank you for the clarification.
> Max

More information about the vbox-dev mailing list