Dictionary of Terms

Wine - Wine Is Not an Emulator

Wine is an Open Source implementation of the Windows API on top of X and Unix.

Think of Wine as a compatibility layer for running Windows programs. Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code, however Wine can optionally use native Windows DLLs if they are available. Wine provides both a development toolkit for porting Windows source code to Unix as well as a program loader, allowing many unmodified Windows programs to run on x86-based Unixes, including Linux, FreeBSD, Mac OS X, and Solaris.

More information can be read in the articles Why Wine is so important, and Debunking Wine Myths. If you are wondering how well a particular application works in Wine, please examine the Applications Database. For installation instructions and step-by-step help with running Wine, take a look at the User Guide.

Wine is free software. The licensing terms are the GNU Lesser General Public License. You can support Wine project via PayPal Donation.

Wine Bottle

Wine uses a dedicated directory to simulate expected Windows directory structure (Drive C:) and Windows registry for applications. Default placement of this directory is ~/.wine. This directory tree with registry is called a Wine Bottle. You may have unlimited number of bottles on your hard drive. Wine applications will use ~/.wine by default unless they are told to do otherwise. You can tell Wine application to use other bottle by exporting the shell variable WINEPREFIX with the value set to the path of the other Wine bottle before running the application. 

WINEPREFIX=/opt/winebot/default-bottle wineprefixcreate
WINEPREFIX=/opt/winebot/default-bottle winecfg
WINEPREFIX=/opt/winebot/default-bottle wine C:\\Program\ Files\\Internet\ Explorer\\iexplore.exe

Package

Programs in most GNU Linux distributions are installed in form of packages - i.e. packed up sets of files.
This is similar to MS Windows installer packages, where program's complete installation is stored in one big .exe file.
User can download a package (a file with suffix .deb, .rpm, .tgz or something similar) from internet site (packages repository) and installs it into the system using root account.

The main feature of packages is the ability to tell which file on PC belongs to which package. When installing from packages, the danger that files from new packages will overwrite old files is minimized. Similarly, when uninstalling a package, all files belonging to package are removed and system is kept up clean and uncluttered.

To assist user in downloading complicated sets of packages interdependent on each other, there are programs called Package Managers.
As different people have different requirements, there are lots of different package types (and package managers). Major package types are DPKG .deb (native for Debian and its derivatives, for example Ubuntu, Knoppix) and RedHat RPM .rpm (native for Fedora/RedHat systems and its derivatives, for example Mandriva, ArkLinux).

Package manager

Package manager is a program designed to help user with resolving package dependencies, i.e. whether package to be installed requires to run some other package(s). Package managers resolve these dependencies automatically and present user with a list of packages to be installed to satisfy dependencies. Most Linux OS use some sort of its native packaging system (Debian DPKG, RedHat RPM, Slackware .TGZ).

Example package manager programs are: yum/rpm/alien (RPM), aptitude/apt/dpkg/Synaptic (DEB)

Metapackage

  • Empty package of native packaging system consisting only of application name, version and prerm script calling winebot uninstall $application_name.
  • This could allow to use apt/aptitude/yum/rpm to uninstall packages installed by winebot.
  • This feature is being investigated, its support may be dropped.

Userspace installation

  • Installation to default bottle ~/.wine
  • Creation of bottle in any place user has write access to
  • Installing into any bottle user has created using Winebot and has write access to

Systemwide installation

  • Default system Wine bottle stored at /opt/wine-system-bottle
  • System wide installed Winebot packages are logged using syslog facility (evaluated at this time)
  • Possibility to register Winebot application packs within native package system (evaluated at this time)
  • Possibility to uninstall Winebot application using native package system (evaluated at this time)

Application pack

  • Application Pack is a tarball consisting of mandatory and non-mandatory contents. It's a filename ending with .wdi extension.
  • Mandatory contents is file pack.xml, see AutoHotKey's pack.xml example.
  • pack.xml has all the neccessary information for Winebot to install and uninstall package.
  • Application Pack may contain the whole application, if its redistribution is allowed freely.

Packages list

  • A packages list is an XML file describing a series of application packs, this XML format is used for installed applications as well as available applications.
  • The applications pack lists can be obtained from the web service pack repository.
  • Basic application pack lists are provided within installer/ winebot package.
  • See the example pack list for base repository.

Repository

  • Repositories store all pack lists and application packs.
  • User can specify multiple pack repositories allowing them to install applications from multiple sources, this resembles yum/apt.
  • Base Pack repositories are provided within winebot install (or via Client installation).
  • More Pack repositories are provided by Server.