[vbox-dev] Updated Automated-guest-installs for VirtualBox ! (beta5)

[Alexey Eromenko]

>> 2. Compatibility with Oracle VirtualBox is unstable: I defined new VM
>> types for Red Hat guests, like RHEL7_64, which Oracle VirtualBox fails
>> to understand and renders RHEL VMs inaccessible.
>
> It also changes the API (and forgets to change the UUID of IMachine,
> which means that compiled API clients using the "native" interface would
> crash or call the wrong method). If the UUID of IMachine would be
> updated then existing 3rd party API clients using the "native" interface
> would refuse to work. In other words: there is no solution which truly
> solves the incompatibility.
>
> With the API groundwork of VirtualBox 5.0 it will be possible in the
> future to support multiple interface versions once several generators
> and tools are extended further (no idea when we have time for this).
> Then such API incompatibilities can be handled cleanly. The API wrapper
> generator is designed to be far more than yet another quirky abstraction :)
>

I don't understand this COM issue at all.
 Assume IMachine has UUID: 0x1111
IMachine::Foo() has 0xF00 (assume it is part of Oracle's VirtualBox)
Now I have added a new main API function in my patch:
IMachine::Boo() and decided it has 0xB00 (UUID 0xB00 was never used in Oracle)

What is the problem with this ?

I don't see how adding Boo() with a new UUID can it possibly break
IMachine class or IMachine::Foo() method.

Anyway I did test VBoxPython code, and it seems to work.

>> 3. License is simple BSD.
>
> Previously it was MIT, but that's just a reminder. It's your change, and
> therefore you're free to use whichever license you like (including
> several of them).

Sorry it is MIT (X11). This one seems shorter than BSD.