Project Alky is dead

Or - why reinventing the wheel is not an automatically good thing to try and do.

A while ago, the internet (ok, just the FOSS world) was temporarily ablaze with talk of a new project. The project was called "Alky", and it was to do what Wine have not managed to do, even after over eleven years of development. It was to allow Linux users to run Windows binaries.

The reason I'm not giving a link to the Alky project's web site is not because I like Wine and I find the Alky's developers approach naive (and slightly arrogant). The real reason is that the project's web site is dead. On IRC, on the Freenode network, the #alky channel holds the following topic: "http://www.alkyproject.com/ - The alky project appears to be dead and cremated; the web site is gone, as was the channel for a while. If anyone knows anything else, please add it to the topic."

When alky launched, it spread healthy amounts of great promises. It said that Wine, while doing a decent enough job in it's own niche, is not fast enough to run games. They said that the reason is the need for each Wine process to communicate certain operations with the wineserver, and that they will preprocess the binaries so that this is not necessary.

Except, of course, they didn't. Instead they closed the project down, public interest nonwithstanding.

And the sad truth is that alky was pretty much doomed from the start. Here's why:
It failed to take on the experience of predecessors.

Wineserver, while indeed a performance bottleneck, has a function. Others (such as Transgaming) did offer other solutions to the same problem that wineserver is after solving, but the simple point of the matter is that some solution needs to be offered. Alky never got around to saying what their solution is going to be.

In a nutshell, Wine is composed of three major sections. One is the PE loader, capable of taking Windows executable or DLL, and mapping it into memory and resolving dependecies the same way that Windows does. The second is the wineserver, that allows synchronization between different processes. The third is the Win32 implementation itself. The last part is, by far, the greatest one. Over 90% of the code in Wine is taken by the implementation of the various DLLs that compose the thing amorphically called the "Win32 API".

Alky got as far as as implementing an alternative to the PE loader (which was done, in Alky, as a preprocessor for the files). It then defined the problem as 90% solved, and went public. As you can understand, the problem was, at best, only 10% solved.

So the project is now dead. Though it may not sound so from my post, I'm actually sorry to see it go like that. At the very least, it would have been nice to still have access to the work already done, and see whether Wine can benefit from it.

Alky, June 2006 - Oct 2006.

Shachar