

I find it in commercial or research software used to drive high end imaging systems like electron microscopes, interferometers and medical scanners. On linux I use Qemu/KVM primarily for headless server applications.īell Labs Analysis “topo”, it was an early suite of tools that often popped up in imaging software, I suspect as a free alternative to something like IDL. Sounds interesting, is this public software? Personally my uses of virtualbox have been pretty much limited to running linux on windows. The software are all based on the same Bell Labs utilities used for topographic analysis of 3D data. I can’t wait to try it, I have a bunch of legacy Win95 based systems that are unreliable running in Win95 under VBox, mostly software that is used to access stored data from legacy hardware, nearly all of them suffer video driver issues related to time-outs doing 3D plots or other video based translations. The article specifically says the new minidriver is not accelerated, but a lot of win32 applications weren’t accelerated anyways so anything is worth a shot. Did you mean making legacy software more reliable under a VM,…I don’t know, I guess it could especially if the graphics were timing critical for some reason. Hmm, I don’t think it will work with any “legacy hardware”. VBoxSVGA: 970fps +/- 30 (in this mode, Cinnamon warns me that the desktop environment’s graphics are running on CPU)ĭo you think this will make legacy hardware more reliable? VBoxVGA: 60fps +/- 2 (very low, but moving a window around is not smooth so it seems plausible) This user reported performance under linux. I tried to find good benchmarks but didn’t find much…


Theoretically the resulting inefficiency would hurt you twice, once on the guest and again on the host. Not only does this hurt performance on actual hardware, but this could be quite expensive to emulate in a VM too. Different video memory planes would need to be toggled using port IO to access all the video ram. I don’t know if it applies to virtualbox with windows 9x, but legacy 16bit video hardware used nonlinear frame buffers due to the limitations 16bit segments. This is one of those things you don’t notice when it’s there, but when it isn’t there things become annoying (like resizing the window and then having to scroll around the VM’s screen from the host). One immediate benefit of the virtualbox drivers is the ability to have arbitrary screen sizes AND be able to resize the screen on the fly without having to scale the VM’s display. Is the more ‘direct’ approach faster or more stable or easier to maintain?
