Away back in pre-history, actually in the days when the 33Mhz i80486 stalked the land as king of the PC world, I got an odd little assignment: negotiate for, and then set-up and run, a 30 user Resumix (resume search and retrieval) system for a former employer's Dallas office.
To do it, I used a single Sun server - a SPARCStation 20 with dual 100Mhz HyperSPARC processors and 512MB of RAM - along with 32 NCD 21 inch X-terminals. This worked very nicely, but after a while users started muttering about how they'd really like to have access to Microsoft Word and Excel on those same enormous screens.
To make it happen I added, in late 95 I think, a second workstation - another maxed out SPARC20, this time with dual 125s and Solaris 2.5.1. It became the primary NCD host with both Windows 3.11 (via Sun's WABI: Windows Applications Binary interface) and Resumix auto-started at user login.
As a result my users could run Office 4 and later 5 right alongside their primary work application. It was insanely great: Office on HyperSPARC was blazingly fast, and the 21 inch high resolution screens led more than one user to start up Excel or Word just to show off for visitors. Most importantly, at least to me, the only trouble the set-up ever gave during just over four years of run-time life was that we had to keep adding external disk as user files built up.
The reason I mention all this is that I had an interesting conversation come out of my Apple comments last week that got me looking at WABI all over again.
Basically the guy's argument was that products like WABI then, and possibly WINE now, reduce or eliminate the competitive advantage Microsoft gets from owning the desktop and thus that the re-emergence of this technology could lead to a significant Unix desktop breakthrough.
The EU, of course, has been grinding away at Microsoft about fully documenting and releasing their (server) APIs. It's a simple idea, but one that directly threatens Microsoft's hold on the market and therefore something they're fighting by all available means.
WABI and Wine represent different approachs to the same problem and a merger of these two sets of ideas might lead to something that would sever the link between Microsoft's desktop operating system control, including its ability to dictate hardware continuence, and its applications. In my client's case, for example, we licensed Microsoft Office for each user, but didn't need Intel hardware to run Intel binaries.
SAMBA, of course, implements that same separation now, letting you run Microsoft clients without Microsoft servers; and WINE (Wine Is Not an Emulator) based products like those from codeweavers and win4lin let you install and run most major Microsoft applications on Linux.
In other words, we're part of the way there - but there are legal and technical constraints stopping another WABI from coming along and making it all pretty easy.
On the legal side there's probably nothing most of us can do directly, but all of this has been leading to a question on the technology side a lot of readers might be able to contribute to answering: is there any reason we can't create a software machine to automatically discover, excercise, and document Microsoft's APIs?
If such a machine existed and could be proven correct, it would eliminate the shadow boxing now going in the EU trade courts over what has, or has not, been disclosed and what continues, or does not continue, to pertain to actual working systems. Clarity would, in turn, make it very difficult for Microsoft to continue circumventing the terms in various consent and related agreements in force in the United States.