Rob Thomas, of LinuxElectrons.com, has been thinking and writing about the software, presently codenamed "David," that we reported on last week in our story Linux vs Windows: Another Great OS Leap Forward On the Way? 

David is being touted by its Philippines-based inventors, SpecOps Labs, as solving the conundrum still not yet solved by Wine - the Open Source implementation of the Windows API on top of X and Unix - namely that of enabling all major Microsoft Windows applications to run on Linux.

"From a very high level view of Project David," Thomas writes, "SpecOpS seems to be serious about the venture. Nonetheless, their Web site is not complete and is missing quite a few links. Some of the most important links on this page which contain PDF documents that support their claims are broken."

An analysis is in order, Thomas says, from the facts known today. He then proceeds "The analysis will consist of only the nuggets that can be gleaned from the SpecOpS Labs Web site:

"One of the problems of the MS Windows OS is that it is subject to crash applications and itself. While studying the Microsoft Windows OS, we found the design flaw that causes this problem. One of the causes of this flaw is the method that Microsoft used to interface the WES with the OS Kernel. Certain functions within the WES are integrated directly into the Windows OS with full system privileges. This gives more speed to applications, but due to the full OS access the applications are prone to conflict at times, which causes the applications to crash."

I don't know how SpecOpS Labs "discovered" this design flaw. If I remember correctly, NT 3.51 had a video performance problem. The performance bottleneck was due to the video API not residing in kernel space (lots of overhead). The fix was to move the video API into kernel space with NT 4.0, and it happened. In fact, most hardware kernel intensive task's moved into kernel space. SpecOpS is lame for even claiming that.

"An example of another improvement that we have made in Microsoft's WES is the positioning of the Windows API. In the MS Windows OS, the Windows API is now sitting on top of several layers that separate it from the Windows OS kernel. These layers affect the speed of the OS. In our design we have integrated the Windows API directly into the Linux kernel giving our WACS greater speed than the Windows OS."

When Microsoft moved those bottlenecks into kernel space, they opened up a "can of worms" so to speak. Moving that code into ring 0/kernel space meant that any programming error could now crash the whole OS. We are all familiar with the BSOD's (blue screen of death). In NT 3.51, that API was in ring 3 for a reason, to offer crash protection. That was the trade off in NT 4, moving bottlenecks into kernel space, but increasing the probability of an OS crash immensely. Given this history, SpecOpS probably can increase the performance of WIN32, but SpecOpS will face the same challenge that Microsoft has had in the past. Looking over Project David's validation plan, it is not apparent how they will not experience the same problems that have plagued Microsoft. Unless they exercise every single API function with all the possible combinatorial variables and concurrent paths, there is no guarantee that SpecOpS will be faster or more stable than Microsoft.

With Windows 2000 Microsoft introduced a new driver architecture to solve those pesky BSOD's. Most of the BSOD's were caused by poorly written third party drivers. Of course end users had no way of discerning exactly who caused the crash, so of course, they called Microsoft, or their hardware vendor. These calls translated into bad PR and huge support costs. The new driver architecture removed most of the actual driver programming (logic) from the third parties and placed it into the hands of Microsoft. Most device drivers are now written against an interface block that Microsoft provides for the kernel. However, kernel mode programming is still available.

"This is the construction phase of David, and is done concurrently with the systems design. The purpose of this phase is to implement the systems design and develop it into a fully functioning production model of the software. During this phase David is fabricated, built, integrated, tested, and evaluated. DLSU and the NCC will work together to complete this phase of the development. Time to complete: 6 to 8 weeks."

Six to eight weeks to write what took Microsoft 10 years to do. This sounds suspect. Unless they are starting out with a code base that already exists, this is an impossible milestone to achieve in the allotted time. Gee, you have to emulate WIN3.1 (WOW16) all the way to the Windows XP API.

From someone who has sat in front of Windows kernel debuggers and logic analyzer screens for quite a few years (from the MS-DOS days), I remain highly skeptical. From the SpecOpS website it appears that they have been working on this since the 00'-01' time frame. So maybe they do have working code. If their claims are true, then SpecOpS Labs is set to slay Goliath."

• Linux vs Windows: Another Great OS Leap Forward On the Way?