[vbox-dev] Possibly non-documented incompatibility 4.x -> 5.0
klaus.espenlaub at oracle.com
Mon Jul 27 08:50:28 GMT 2015
On 25.07.2015 01:03, Maxime Dor wrote:
> 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
> 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
> 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
> Thank you for the clarification.
More information about the vbox-dev