VMWare takes a different approach than coLinux. Instead of rewriting the kernel, apparently the route coLinux took, VMWare creates a super virtualized kernel in the most privileged Ring 0 of the processor, within which Windows, Linux, and virtually any operating system can run, demoted to a lower privilege level, such as Ring1 or Ring3. VMWare runs a specialized device driver to avoid conflicts between operating systems, instead of coLinux's approach that appears to let Windows device drivers control the actual hardware. So, under VMWare, a super monitor vitalizes the hardware and most privileged software operations, marshaling out privileged operations, which seem to require 15 percent overhead for I/O.CoLinux seems to pass the I/O request to the Windows driver and hope for the best.

Each method has its advantages and disadvantages. I'm not sure which is better, or which scales better to massive enterprises. Time will tell on those scores.

I ran a number of CPU and screen intensive tasks, games and business apps under coLinux, and there was no performance drag I could point at. Interestingly, when I ran ports of the same code in the Linux window and Windows window, the Linux code ran more smoothly. Linux showed less jerky motion on the games. Also, Linux was a touch faster for graphics intensive font rendering Linux's OpenOffice versus Windows Word.

Running CPU-only tasks in each window showed almost identical performance. Disk heavy tasks showed varied results: disk reads and directory operations gave about a 10 percent edge to Linux; there was no clear winner for SQL fetches and puts. My benchmarks were just quick hacks to give me a feel for the product and were not formal by any means. I suggest you run a full set of real benchmarks on a variety of operations to get a more accurate result than my, at best, back-of-the-envelope guesstimates.

Gotchas
Basically, this code took a licking and kept on ticking. My preliminary look showed that running bad code in either window would cause that window to crash, BSOD or panic - it didn't cause a real problem in the other window. Running infinite loop disk I/O code did cause some lock ups in the other window, but nothing a "kill -9" (or Window's task manager) couldn't handle in an expected way. Devices are run, it appears, from the Windows device driver: a buggy Windows device driver causes problems in both windows, some serious enough to require a system reboot.

Before opting to put this code in mission critical applications: remember this is still beta code. Test, test and re-test

All in all, I'm impressed. Not awed. But very impressed. And I don't impress all that easily anymore.

And this is still an early beta.

Ross M. Greenberg is a programmer, writer, consultant, and web page designer with experience in Linux, Unix and Windows. He started working on Unix-based systems in the early 1980s. Lately, he's been concentrating on PHP and ASP database programming.