Don't want to destroy your dreams, but cross-building can't be a full solution - or can you point us to tools which can do the driver signing (mandatory for 64bit Windows)? I only know Windows tools, and haven't seen that any of those work with WINE.
And to answer the Solaris build question: VirtualBox can be built with exactly two compilers: the Microsoft ones (the Windows bits), and gcc (all other platforms). Which actually also tells that if you want a mingw based cross build you have to first rewrite/adapt major parts of the Windows specific code.
If you want to compile the additions of another platform, then use a VM. That's the whole point of virtualization, right?
Windows drivers are built with Microsoft compilers. Any attempt to use other tools is simply a waste of time. I'm not saying it's not possible, but we have better things to do.
sandervl wrote:If you want to compile the additions of another platform, then use a VM. That's the whole point of virtualization, right?
Windows drivers are built with Microsoft compilers. Any attempt to use other tools is simply a waste of time. I'm not saying it's not possible, but we have better things to do.
ok i guess that's fair enough as they are kernel drivers they have to be signed on ms platforms.
so hopefully that can be done using vs express at some point in the future.
sandervl wrote:If you want to compile the additions of another platform, then use a VM. That's the whole point of virtualization, right?
Windows drivers are built with Microsoft compilers. Any attempt to use other tools is simply a waste of time.
Yes, and no. My reason for wanting cross-compilation is that I won't need to have a Windows licence in order to build the Guest Additions. But your answer is valid -- I can certainly see why this isn't a priority for anyone. And if support for compiling with free (as in beer) tools from Microsoft within a VM loaded with Windows is coming down the line, I'd say that's more than "good enough" for me.
achimha wrote:It can change over time but the community could of course develop an alternative USB 2.0 EHCI implementation.
Methinks it should be noted that should an open source EHCI controller become available (either community developed or eventually released by Oracle as some future date), USB 1.x controllers (VBox uses OHCI) can be removed with the addition of USB rate matching hubs (RMHs). Intel has recently made this type of move within their south bridge silicon (removing their UHCIs in favor of adding RMHs for USB 1.x support). I have not read up on such things but I imagine a similar thing is available for supporting USB 2 and 1 devices on USB 3 XHCIs.
Thank you, for finally including full USB 1.x support in VBox 4.
achimha wrote:It can change over time but the community could of course develop an alternative USB 2.0 EHCI implementation.
Methinks it should be noted that should an open source EHCI controller become available (either community developed or eventually released by Oracle as some future date), USB 1.x controllers (VBox uses OHCI) can be removed with the addition of USB rate matching hubs (RMHs). Intel has recently made this type of move within their south bridge silicon (removing their UHCIs in favor of adding RMHs for USB 1.x support). I have not read up on such things but I imagine a similar thing is available for supporting USB 2 and 1 devices on USB 3 XHCIs.
Thank you, for finally including full USB 1.x support in VBox 4.
Ditching USB 1 is a bad idea, as you will loose support for legacy systems like Windows 9x. There are no USB 2 drivers available for 9x, you're stuck with 1.1 at best. Don't want to break more than there already is and it's already wonderful that we can run such legacy systems in VB.
VirutalBox OSE is released under GPL. But this is only the software developed in Oracle (by innotech team). Some of the software that is bundled together with VirtualBox can use some other license, but it must be compatible with GPL.
The binary of VirtualBox 4.0.0 (as visible in the betas) is released under GPLv2, except for the third party source components which have a different license (LGPL, BSD, MIT etc). The "OSE tarball" can be used by anyone to build it from sources.
Since "OSE" is effectively meaningless now we'll clean up the terminology and references on the website as we find time.
The extension pack is released under the PUEL license, so if you want these features the licensing conditions are effectively unchanged.