Author: David Graham
Czekalla discussed the status of the Wine (Wine is Not an Emulator) project’s Win32 API implementation for Linux, and gave his presentation using Microsoft PowerPoint running under Wine. Czekalla has been working with Wine since 1999, when his then-employer Corel needed it for WordPerfect and CorelDraw support in Linux. Czekalla is now an independent contractor, but he says he spends a lot of time working with Codeweavers on Wine.
He expressed the importance of the Wine project, and cited a study by the Open Source Development Labs (OSDL) that says the number one concern of companies looking at migrating to Linux is that applications need to be able to run in the new environment. The applications, he says, were not Microsoft Office or other things for which open source substitutes exist, but things like Visual Basic programs and other applications developed in-house, or niche applications, critical to the function of the business.
Wine started in 1993 initially to bring games to Linux. It is not an emulator, he stated, it is a free implementation of the Win32 API, intended to allow Windows executables to be run in the Linux environment. It is released under the GNU Lesser General Public License (LGPL). Czekalla says that Wine is developed by about 665 developers, with 30 to 40 active at any given time.
He explained the makeup of the layers between the operating system and the program being run in the form of a chart explaining at what level Wine runs on a Linux system. Wine runs in user space, he says, not kernel space, and therefore has no access to hardware or drivers. To the Linux machine, it is just an application. It runs between the kernel and the libraries needed to load the Windows executables, allowing Windows programs to find the Windows libraries they are expecting within Linux.
|
Ulrich Czekalla pauses to take a question |
Theoretically, he says, applications in Wine should run just as fast as they do under Windows. As there is no emulation, there is nothing to slow the execution. However, Wine is still not considered a stable release, and has not yet been optimized, resulting in a lower performance. At the moment, Wine developers’ efforts are focused on making it work, not on optimization. That, he says, will have to come later.
As work progresses on Wine, a lot of effort is put into making one particular application work at a time. Czekalla says that as problems with one application are fixed, many other applications will also become functional in Wine, as the features enabled for the targeted application are also needed by other applications. He cited the process of getting Microsoft Office 2003 to work under Wine as an example of this, calling the side-effects for other programs “collateral damage.”
Czekalla says that while Wine is included with most Linux distributions, it still often needs manual tweaking to make it work with different programs and, in spite of being in development for 13 years, is still in its 0.9 version. Wine releases always have bugs, he cautioned, and one should be prepared for odd crashes. Supporting Wine, he noted, requires someone with both Windows and Linux expertise.
To debug Wine, he says, requires the use of relay logs that can be as large as a gigabyte to see what happened within the application as it progressed, in an effort to figure out what might have killed it. He says to expect it to cost about $1,000 per bug to fix minor bugs, and between $4,000 and $20,000 to fix more difficult bugs. A Wine implementation can look great but become problematic and expensive.
Where is Wine going? There are some messy areas, says Czekalla. One of these is its Component Object Model (COM) implementation. After years of work, it is still not done and is at least six months away from being able to talk to a Microsoft Exchange server.
Right now about 70% of programs can install with Wine’s implementation of the Microsoft Installer (msi.dll) library. In another year, Czekalla expects that number to be about 90%, though he pointed out that while most programs that install will work after being installed, there is no guarantee. One problem Wine has had is with the device-independent bitmap (DIB) engine. At the moment it supports only 24-bit color depth graphics, but many Windows programs still use only 16 bits. He described this as a problem with X.
Because Wine is a userspace program, and cannot see hardware, things such as USB devices (like a USB key) cannot be directly seen by programs running under Wine. An effect of this, he says, is that programs requiring Digital Rights Management (DRM) will not work under Wine and won’t unless and until Linux gets native DRM support. Companies that use DRM, he said, are not willing to help. He gave the latest version of Photoshop as one example of a program that has implemented DRM and will not work in Wine.
Before taking questions, Czekalla pointed out that a lot of work could be saved by using Microsoft’s own libraries (DLLs), but the problem is licensing. You need an appropriate Windows license for any libraries you borrow, though it was pointed out by an audience member that most people already have unused Windows licenses they can use from hardware they’ve bought that included Windows. Czekalla says that Internet Explorer is the Windows application used most often in Wine, because it’s needed by many people for specialized functionality relating to their jobs that will only work in IE.
The first person to ask a question noted that Wine sounds like a pain in the neck, so why should you use it? It is a pain, agreed Czekalla, but a lot of applications do work. For migration, the choices are basically Wine or VMware. Wine, he noted, doesn’t require a Windows license or the performance hit of emulation, while VMware does.
Another attendee asked, who is using Wine? Czekalla cited Intel, Dreamworks, Disney, and basically any company that is migrating from Windows. Wine is unstable, he says, but when rolling your own implementation it can be quite stable for your purposes.
Is Novell involved in Wine? Czekalla says he knows some people at Novell who are contributing, but as a corporation he doesn’t believe so.
One person asked about Wine’s relationship with TransGaming. Czekalla says that not much is happening there. A few years ago, TransGaming modified and sold Wine’s code perfectly within the Wine license, which was then the X11 license — which doesn’t require redistribution of derivative code. But in response, Wine switched its license to the LGPL, which he surmised TransGaming didn’t like as the project hasn’t heard much since. Czekalla expressed the hope that TransGaming and Wine can eventually get back to working together, as there is a lot of duplication between the two.
Linux for the corporate desktop
Novell Canada CTO Ross Chevalier’s keynote on the third day of LWCE Toronto was “2006 – The Year of Linux on the Corporate Desktop.” He started by acknowledging that his keynote’s title was a cliché, and asked why 2006? Why not? It’s always the year of something, and he believes Linux really is ready to hit the corporate desktop.
He pointed to a Novell project called Better Desktop that focuses on desktop usability for Linux. The idea behind it, he says, is to develop the Linux desktop interactively with actual users of Linux desktops in workplaces rather than test environments to figure out what it is they need. The goal is to help companies transition to Linux desktops without any serious retraining costs. People want things to work as they’re used to them working, and the project is working toward that.
|
Ross Chevalier tosses a SUSE gecko to someone who answered a question |
Eye candy, he says, is important. It holds people’s attention and helps them learn. He returned to that theme later with demonstrations of desktop Linux eye candy, such as a three-dimensional cube rendering of multiple desktops in X, allowing the cube to be spun on screen and windows to be dragged between and across desktops.
In order for Linux to be widely adopted, he says, Linux desktop quality and hardware support must be better than the as-yet-unreleased Microsoft Vista and Mac OS X 10.5 operating systems. To that end, USB and FireWire devices, printers, and the like must just work when attached, as users expect from Windows and Mac OS, or adoption slows.
Searching desktop computers, he says, has to be easy. People with large hard drives and large numbers of files need to be able to find stuff easily. He pointed out that the number one and number two Web sites according to Alexa‘s ratings are Yahoo and Google, respectively. Search, he says, is important. Password-protected office files have to be as easy to use in OpenOffice.org as they are in Microsoft Office, he says, or adoption doesn’t happen.
After listing the requirements needed for adoption, he started a demonstration on his SUSE Linux laptop to show that all the capabilities he listed as being required do indeed exist. He concluded that we are up to the point where a Windows user can go to Linux and feel comfortable.
The use of the Linux Standard Base
Jim Zemlin of the Free Standards Group headlined a session entitled “Open Source and Freedom: Why Open Standards are Crucial to Protecting your Linux Investment.” The Free Standards Group is a California-based non-profit organization, Zemlin says, with a broad range of members including “basically everyone but Microsoft.” Membership spans the globe, he says, with many members in many countries around the world.
The Free Standard Group’s main focus is the Linux Standard Base (LSB), which is an ISO standard. The goal of LSB is, according to Zemlin, to prevent Linux fragmentation. A common misconception about open source, he says, is that using open source software prevents the problem of vendor lock-in. He cautioned that this is not true. Open source is a development methodology and choice is not guaranteed.
Zemlin pointed out somewhat ironically that many companies insist on having one throat to choke while complaining about vendor lock-in. The single throat you are choking, he noted, is the vendor that has locked you in. With open standards he says, you get the choice of throats to choke.
|
Jim Zemlin speaks about the importance of the Linux Standard Base |
The Linux Standard Base offers a standard for the installation, libraries, configuration, file placement, and system commands, among others. Zemlin says this provides independent software vendors (ISV) an easier way to develop Linux software, as they know where to find everything and can expect all Linux systems to have the same basic structure. Developing around the Linux Standard Base means that ISVs need only test their product against one distribution, and not have to set up several test cases, saving time and effort for the quality assurance side of development.
The FSG being controlled by open source vendors means that its release cycle for an updated standard base is about 18 months, comparable to most distributions’ own upgrade cycle. As a result of this constant updating, the ISO standard must also be updated regularly. The standard must move with the ever-fluid open source community it is attempting to standardize. All the major commercial Linux distributions, Zemlin says, are LSB-compliant.
In retrospect
This year’s LinuxWorld Conference & Expo Toronto saw a far improved set of speakers from last year, with a noticeable increase in the useful speakers to marketing droid ratio. Conference organizers state that the conference saw more pre-registrations this year than in previous years, but final numbers on actual attendance have yet to come out.
