So this ticket is basically asking the VirtualBox maintainers to take a reliably working part of the product and to port it to a different compiler, retest everything, fix any bugs caused by differences between compilers and update the build process as well. So as an end user of VirtualBox, I would either notice no difference at all (BIOS isn't a performance bottleneck really), or will get a regression due to bugs.
With all due respect to the free software community, I would say switching the compiler used in a stable product without an apparent improvement noticeable by the users would not serve their best interests. It is also a bit strange to see it not in a form of "hey, we really care about free software, so we ported this part to use a free compiler, here's the performance comparison, here are the unit tests, here are the build instructions", but rather in asking someone else to spend considerable effort on implementing this.
That's nonsense, both GCC and Clang handle this perfectly well. It's how we handle compiling 16 bit option ROMs in qemu:
Can VirtualBox just switch to SeaBIOS?
I seem to see this shift in ideology from People.
Yeah, but we're already getting VirtualBox for free, so we can't only take into account the benefits of the end-users ; if the developers find it more convenient to use this new compiler, so be it.
Can you elaborate?
Everything in it that is copyrighted Symantec or Digital Mars is now Boost licensed. In particular, stuff that is copyrighted by Microsoft is NOT Boost licensed and cannot be redistributed.
This ticket is not about changing the compiler that builds VirtualBox itself.
Can you use Tianocore as your BIOS for VirtualBox the way that you can use it (in the form of OVMF) for qemu?
How is SeaBIOS built?
This has the advantage that you don't need any new compiler to build your program, neither OpenWatcom or Digital Mars. (Nothing against the Digital Mars compiler! I just think that it isn't the right engineering direction for VirtualBox to depend on retrocomputing.)
Edit: unless the code within the emulator is trying to run the BIOS within an emulator of its own. Turtles all the way down...
Common with the VGA BIOS BTW.
Again, qemu works fine without a retrocomputing compiler. Is VirtualBox doing something that prevents it from taking whatever approach qemu uses? (qemu even has the cool thing where "-curses" will cause it to copy segment B800 as text to your host-side terminal emulator and avoid rendering graphics at all.)
Why should VirtualBox take the pain now rather than waiting and seeing if the theoretical issue every materializes? I mean, if someone does the work and tests it, then sure, VirtualBox should adopt it. But why is this their problem to solve now?