(heise online, 10.03.2009 14:19) In future Linux distributions, open source drivers will have to be used with older Radeon GPUs, because AMD will no longer support or maintain current Linux drivers for older graphics hardware

Wine

Wine is a translation layer (a program loader) capable of running Windows applications on Linux and other POSIX compatible operating systems. Windows programs running in Wine act as native programs would, running without the performance or memory usage penalties of an emulator, with a similar look and feel to other applications on your desktop.

The Wine project started in 1993 as a way to support running Windows 3.1 programs on Linux. Bob Amstadt was the original coordinator, but turned it over fairly early on to Alexandre Julliard, who has run it ever since. Over the years, ports for other Unixes have been added, along with support for Win32 as Win32 applications became popular. Microsoft had successfully steered its Windows program to the forefront of personal computers. IBM had hopes that OS/2 would catch on, but even they admitted that support of Windows programs was necessary and built the ability into their product.

Sun's acquisition of Praxsys Technologies in September of 1992 led to the development of a product called Wabi. Sun first demonstrated the software at the 1993 Solaris Developers Conference. It allowed users of Solaris x86 and Solaris 2.2 for SPARC to run Windows applications out of the box. Other products at the time allowed Windows programs to be run, but they required machine-level emulation and the installation of DOS and Windows. Wabi was unique in that it allowed Windows windowing calls to be translated directly to X Windows calls. By emulating the rest of the x86 code it was possible to actually run Windows programs faster on a RISC workstation! Wabi's more advanced features included Bitstream's font handling technology to handle TrueType fonts.

Wine's storied history of licensing has sparked many debates. The issue of licensing surrounds itself with two primary areas - the license of the Wine code itself and the license of applications produced using Winelib. The Wine developers' goal is to give people the ability to both implement and add to the Wine project in such a way it doesn't hinder others from doing the same. At the same time they want to give other developers the chance to port their application without the fear of being bound to a software license that prevents them from doing what they want with their creation.

In the beginning, Wine adopted a BSD-style license. At the end of 1999 discussion began about changing the license. Richard Stallman had pointed out that it was incompatible with the GPL which potentially causes problems with any open source project wishing to use Wine code. Most developers didn't see a need to craft a new license and the X11 license, a derivative of the BSD license, had the most support. A vote was called for and in January of 2000 Alexandre announced that it would become the new license of Wine.

In March of 2002 a poll was conducted among both the free and commercial developers of Wine to see if there was interest in moving to a different license. Most developers did not want their code to be appropriated by a commercial entity and there were concerns that might happen. After much debate they chose the Lesser General Public License and on March 9th, 2002 the Wine source code became bound to those terms. The LGPL, often referred to as a "copyleft" license, required the Wine developers to abide by some guidelines:

Source code (including all changes from the original Wine sources) must be made available to people who receive a binary of Wine. This also applies if Wine is used as a library, in which case only the source of Wine (including all changes) must be made available.

Simply linking with Wine does not mean you need to make the source code available for your program.

The immediate effect was the creation of the ReWind project to further the X11-licensed codebase. Many key developers agreed to allow their additions to be used by both the X11 and LGPL Wine code. Most have decided to focus their efforts on synchronizing with the LGPL'ed Wine and the vast majority of development and new features appear there first. Picking a favorite software license is left as an exercise for the reader.

Shortly after changing the license development began to pick up at a greater pace. More patches began to appear, Alexandre made more CVS commits, and more applications were reported to work. By the end of 2003 DLL separation achieved a milestone with the split of the kernel32/ntdll combination. Most of the architectural changes to support a beta release were in place. Another developer's conference was held in January, 2004 in St. Paul Minnesota sponsored by CodeWeavers. Once again, a roadmap was laid out for tasks that needed to be completed.

Features

Designed for POSIX compatible operatings systems (eg. Linux and FreeBSD)

"bug-for-bug" compatibility with Windows

Graphics

X11-based graphics allows remote display to any X terminal

X11, TrueType (.ttf/.ttc) and Windows Bitmap (.fon) Fonts

DirectX support for games (limited Direct3D support)

Support for OpenGL based games and applications

Printing via PostScript driver or legacy native Win16 printer drivers

Enhanced Metafile (EMF) and Windows Metafile (WMF) driver

Desktop-in-a-box or mixable windows

Windows MultiMedia (WinMM) layer support with builtin codecs

Allows Windows program to interface with:

Sound devices via ALSA, OSS, ARTS, JACK, and libaudio

Multi-lingual keyboards and CJK input method support via XIM

Modems, serial devices

Networks (TCP/IP and IPX)

ASPI Scanners

Windows Tablets via XInput (eg. Wacom)

Wine API

Designed for source and binary compatibility with Win32 code

Win32 API test suite to ensure compatibility

Compilable on a wide range of C compilers

Permits mixing of Win32 and POSIX code

Permits mixing of ELF (.so) and PE (.dll/.exe) binaries in one address space

Win32 compatible header files

Automatically generated API documentation

Resource compiler

Message compiler

IDL compiler

Extensive Unicode support

Internationalization -- Wine supports 16 languages

Built-in debugger and configurable trace messages

External memory checker support using Valgrind

Sample programs

Wine is still under development, and it is not yet suitable for general use. Nevertheless, many people find it useful in running a growing number of Windows programs. Please see the Application Database for success and failure reports for hundreds of Windows programs.