|
|
Last updates:
Fri Sep 1 05:38:13 2006
Fri Sep 8 07:35:24 2006
Thu Mar 23 14:07:50 2017
WINE is a recursive acronym for Wine Is Not a (CPU) Emulator. WINE supplies a Microsoft Windows XP library layer that allows direct execution of some Windows executables on Unix systems.
WINE is a collaborative on-going effort to track the moving, and incompletely documented, target of Windows XP. As of fall 2006, About 600 developers have contributed to WINE's current 1.6 million lines of open-source code.
WINE runs on the Intel IA-32, Intel EM64T, and AMD AMD64 architectures with the FreeBSD, GNU/Linux, and Solaris operating systems. The Darwine Project is working on a port of WINE to the new (late 2005) Intel-based Apple Mac OS X product line. However, we cannot provide software support for those new systems until we have a server machine in place, perhaps by late fall 2006.
WINE does not provide a virtual machine , but only a Windows library layer, so it can be run only on hardware platforms that Windows XP itself runs on, namely, the Intel IA-32, and its architectural descendants EM64T and AMD64. For unknown reasons, WINE runs, but silently terminates immediately, on IA-64, which normally supports other IA-32 executables.
Because almost all Microsoft Windows programs require a graphical user interace (GUI), in order to use them, WINE must be run with an X11 Window System display available. Unix workstations built since the mid 1980s have native X11 support. On Apple Mac OS X, X11 is not preinstalled, but is readily available as an optional package.
Once applications are installed under WINE, they can be used without change on any platform on which WINE is available. Applications that conform strictly to the published Windows library interface should run without problems. In reality, many programs, including many of Microsoft's own products, do not conform, and there is widespread use of undocumented features whose reverse-engineered descriptions fill several books .
Much more detail about WINE can be found in its official frequently asked questions list .
The use of WINE to run Windows software on Unix is analogous to using cygwin or U/Win to run Unix software on Windows .
There are other, and possibly better, ways to run Windows programs on Unix systems: see the Web page for Windows on GNU and Unix .
Because the Windows application under WINE runs on the native hardware for which it was compiled, it should run at about the same speed as it would on a native Windows XP operating system installed on the same hardware. There is a small overhead from the library interface, but that overhead exists in both Unix and Windows.
An exception to this rule may apply for programs that are graphics intensive: a native Windows program might be able to communicate directly with a graphics-accelerator device, while under WINE, it may see a simpler, and slower, graphics device that passes its operations on to the X11 Window System library. Of course, that library may itself have support for fast graphics hardware.
What versions of WINE are available?
Vendor-provided versions of WINE are available as /usr/bin/wine on our GNU/Linux IA-32 and AMD64 systems, and as /opt/sfw/bin/wine on our Solaris IA-32 systems.
Where local builds are possible (currently, only GNU/Linux), we have a usually newer version in /usr/local/bin/wine. For most users, that version appears first in the search path defined by the PATH variable, so the command wine normally runs the latest version.
Run WINE with a valid Windows program name and optional program arguments:
% wine notepad myfile.txt
For non-GUI text-based applications, use the command wineconsole instead of wine.
The first time that you run WINE, it creates a hidden directory tree under $HOME/.wine with about 40 directories and 50 files. As you install other Windows applications, this directory tree grows.
More information on running WINE can be found in its Unix manual pages: run the command man wine.
The invocation of WINE is very similar to that used for virtual machines, including Java (java), DotGNU (ilrun) and Mono (mono) for the Microsoft Common Language Infrastructure (CLI), and SIMH (simh) for numerous historical architectures. For more details, see the virtual machines Web page.
If you find yourself using a particular Windows program frequently under WINE, you can always wrap it in a shell script stored somewhere in your Unix search path so that you can invoke the program with a short-and-simple name. Alternatively, you could define a shell alias in your shell startup file.
How can I tell if my machine supports WINE?
If the program wine is found in your search path, then your system has WINE, so just try to run the command.
The command uname -m identifies the CPU architecture of a Unix system. It must report i686, i86pc, or x86_64 if the CPU is one on which WINE can run.
If your system does not appear to have WINE, and you still want to use it, please ask systems staff for advice on choosing a suitable system to login to. For security reasons, and also for avoiding documentation obsolescence, we do not record hostnames in FAQ entries.
How do I refer to files under WINE?
Microsoft Windows applications run under WINE can open any file in the Unix file system to which you have access, but within the Windows application, you must use backslash as the directory separator instead of the Unix and Web forward slash. Although some Windows library routines also recognize a forward slash as a directory separator, that practice is unlikely to be widely supported. The notepad file-open box under WINE reports:
A filename cannot contain any of the following characters:
/ : < > |
If you refer to files on the Windows
C: drive, they are
found in the tree
$HOME/.wine/drive_c.
Thus, the Windows file
C:\Program Files\SSH Communications Security\SSH Secure Shell\SshClient.exe
corresponds to the Unix file
$HOME/.wine/drive_c/Program Files/SSH Communications Security/SSH Secure Shell/SshClient.exe.
The installers for Windows programs normally arrange to add the path to the programs to the system search path, so you need not remember where they reside. Thus, the program in the preceding paragraph can be run with just wine SshClient; WINE supplies any missing .exe extension. You can even use wine sshclient; for your convenience, WINE accepts the lowercase form as an alias for the mixed-case name.
WINE itself recognizes both Unix and Windows pathnames, so you can use either on the WINE command line. However, since almost all punctuation characters, including ampersand, angle brackets, apostrophe, asterisk, backquote, backslash, braces, brackets, dollar sign, question mark, quotation mark, parentheses, semicolon, sharp, space, tilde, and vertical bar, are significant to the Unix shells, you need to protect each such character with a backslash, or enclose the entire pathname in single quotes.
If you access the same files from both Unix and Windows, you will soon discover that the two operating systems have different line-ending conventions in text files. Unix uses a single newline (linefeed, Ctl-J) character, while Windows uses carriage-return (Ctl-M) followed by newline. Older Apple Mac OS systems used just carriage-return, but newer Mac OS X applications use the Unix convention. The local utilities dos2mac, dos2ux, mac2dos, mac2ux, ux2dos, and ux2mac take a list of text files on the command line, and rewrite them in place with changes in line terminators, preserving their last-write time stamps. Use them with caution: their Unix manual pages give further details, and important caveats about their use.
The emacs text editor handles all three, and indicates the line-ending convention in the filename status bar at the bottom of its window with : (for Unix), (DOS), and (Mac). The input convention is preserved if the file is written out again. If you really want to see the line terminators, visit the file with the emacs command M-x find-file-literally, but edit it with care in order to avoid inconsistencies in line terminators.
Java and PostScript files can use any of the three line-ending conventions on any operating system, but most other text files, including C, C++, and Fortran source code, must adhere to the conventions of the native system.
With more extensive experience in both Unix and Windows, you will discover another difference. Unix filenames are case-sensitive, so that README, ReadMe, and readme are distinct files. The Windows filesystem preserves lettercase in filenames, but ignores it when looking them up; thus, the three sample files are identical to Windows applications. If you use the Unix lettercase in Windows applications run under WINE, you will get the expected file, but if you use some other casing, such as ReAdMe, it is impossible to predict which of the three files will be opened.
There are several other important differences between the filename syntaxes in Unix and Windows. Avoid problems by sticking to simple, and relatively short, filenames consisting of letters in a single lettercase, digits, hyphen, and underscore, with an initial letter or digit, at most a single dot, and no more than three characters after the dot. The old MS-DOS 8+3 filenaming rule (at most eight characters before the dot, and no more than three after) is a convention that works on all current operating systems, as well as for CD-ROMs, DVDs, digital cameras, and memory sticks.
Are character sets compatible?
Yet another difference that will soon appear is that many Windows XP applications assume text files in Unicode two-byte UTF16-LE encoding. They may handle ASCII files as well, because all ASCII files are also valid Unicode files in UTF-8 encoding. However, if you access files in UTF16-LE encoding from Unix, you may first need to convert them with the iconv utility:
% iconv -f utf-16le -t ascii < windows-file > unix-file
% iconv -f utf-16le -t iso-8859-1 < windows-file > unix-file
% iconv -f utf-16le -t utf-8 < windows-file > unix-file
The iconv utility terminates with an error if the conversion cannot be completed without loss of data (e.g., accented characters converted to ASCII, which has no such characters).
If iconv fails to convert your file, try its local extension, iconvx, which provides options that control what is done with unconvertible characters, and produces an output file that you can then manually repair as needed.
What commands are available under WINE?
Initially, only a few commands are available under WINE:
How do I install software under WINE?
To get more Windows commands beyond the initial set, you need to run a Windows installer program under WINE. For example, this command installs the free secure-shell client for Windows in the $HOME/.wine directory tree:
% wine /usr/local/src/ssh/SSHSecureShellClient-3.2.9.exe
The first time that the newly installed SshClient program is run under WINE to connect to another Unix system, the fonts are likely to be garbled. Fix this by choosing the SshClient menu path Edit -> Settings -> Fonts: a 10-point Courier font works fine.