Author: Nathan Willis
Like WineTools, Wine Doors is designed to user-friendlify your Wine installation — setting up phony Windows drives, adding Windows applications, and so on. The goal is to let users manage their Wine-based apps with point-and-click ease — from free apps such as Google Earth to closed, commercial software like Photoshop or Internet Explorer — as well as support packages like font packs supplied by Microsoft.
Trouble with WineTools
In fact, it was Internet Explorer that first prompted developer Karl Lattimer to start Wine Doors. He experienced repeated failures trying to install IE with WineTools, so he looked into the WineTools code to search for a solution — and winced. For one thing, the supported applications were hand-coded into the tool, making the system completely inflexible and causing a bottleneck for end users: to add an application not on the supported list required waiting for a new version of WineTools.
Furthermore, the Wine developer community was complaining of WineTools’ inability to play nicely alongside other libraries and applications. It changed registry settings, overwriting defaults expected by other programs, and resulting in spurious bug reports reported to the Wine team — problems caused by WineTools, not Wine itself. More importantly, a number of developers felt WineTools to be philosophically at odds with the goals of the Wine project: it downloaded and installed real Windows DLLs — the same libraries that Wine was working hard to eliminate the need for.
Lastly, WineTools was written in shell script, coded to older, deprecated technologies like GTK+1 and Xdialog, and not regularly updated. The code base in its existing state had been passed down through several teams of developers after having been abandoned by it original creators. The current maintainers acknowledged the problems — technical and philosophical — pointed to by critics, but lamented that there was little they could do about it, as they lacked the time and resources to start over on a new project.
Nevertheless, a WineTools-like application was a necessity. Anecdotally, it is one of the most popular Wine add-ons, and with good reason — many if not most Wine users are migrating from Windows, and need to do whatever is necessary to make their essential Windows apps run under a new operating system. Even commercial Wine resellers such as Transgaming saw the market for a point-and-click app installer; they provide one for their Cedega gaming system.
Redesigning
So the stage was set. Lattimer decided to start from scratch, writing a modernized WineTools-replacement in PyGTK and using Glade for the GUI, a combination that drastically cut down on code size and complexity. More importantly, though, after batting around the options with Wine developers, he decided to design into Wine Doors a much sharper separation between the program itself and the Wine apps it was to install and manage. Wine Doors works with remote, configurable application repositories, offloading the maintenance of individual packages to the community and allowing for more flexibility.
Wine Doors’ installer module utilizes “application packs,” which are XML-based recipes that specify configuration options, prerequisites, file permissions, and other meta-data — much like native Linux .rpm and .deb package formats. The Wine Doors application itself can retrieve application packs and pack lists from remote repositories, maintaining a local cache for the sake of speed.
Wine Doors can thus be integrated with the existing Wine project’s AppDB, akin to the way Debian-based Linux distributions link to remote repositories with APT. But that’s not all. Lattimer is quick to emphasize that third-party independent software vendors can create and maintain their own application repositories. In corporate environments, he says, the ability to deploy a private repository is important to systems administrators — and corporate environments often rely more heavily on Wine to transition their desktops to Linux than do individual home users.
In the long term, Lattimer hopes to integrate Cedega, CrossOver Office, and other “specialized” Wine add-ons into the application. But for right now, the emphasis is on making the core functionality correct. Currently he works with just one other developer, Thomas Dybdahl Ahle, whom he credits with a number of key Wine Doors improvements, such as changes to the hardware abstraction layer code that allows Wine Doors to work with changeable CD drive locations.
The basic packlist loading and processing is in place, testable with a subversion checkout. The team hopes to make a functional release in .rpm (and .deb, if a knowledgeable volunteer can be found) package format within the next month, but is in need of testers to make application repository support robust enough for its first end user release.
