If you're planning to include access to a CD-ROM drive in your Wine configuration on Linux, then make sure to add the "unhide" mount option to the CD-ROM file system entry in /etc/fstab, e.g.:
/dev/cdrom /cdrom iso9660 ro,noauto,users,unhide 0 0Several Windows program setup CD-ROMs or other CD-ROMs chose to do such braindamaged things as marking very important setup helper files on the CD-ROM as "hidden". That's no problem on Windows, since the Windows CD-ROM driver by default displays even files that are supposed to be "hidden". But on Linux, which chose to hide "hidden" files on CD by default, this is FATAL! (the programs will simply abort with an "installation file not found" or similar error) Thus you should never forget to add this setting.
Windows applications refer to disc drives by letters such as A:, B: and C:, and to serial and parallel ports by names such as COM1: and LPT1:.
You need to tell Wine how to interpret these. You do so by specifying the Unix file system nodes and devices that Wine should map them onto, as described later in this section.
You can map a Windows fixed disc drive onto any node in your Unix file system - this need not be the root node of a drive. For example, you could map your Windows drive C: onto your Unix directory /usr/share/wine-C. Then the Windows folder C:\Windows\Fonts would be at /usr/share/wine-C/Windows/Fonts in your Unix file system.
Make sure that you have assigned drive letters for directories that will cover all the items Wine needs to access. These include the programs that you run, the data files they need and the Wine debugger (in case anything goes wrong).
It is best to use a number of drive letters, and map them onto directories that cover small sections of the file system containing the files that Wine will need to access. This is safer than simply assigning a single drive letter to the Unix root directory /, which would allow Windows applications to access the whole of your Unix file system (subject, of course, to Unix permissions). If one of them misbehaved, or if you accidentally installed a virus, this might leave you vulnerable.
For replaceable media, such as floppy discs and CD-ROMs, you should map Windows drive letters onto the mount points for these drives in your Unix file system - for example /mnt/floppy or /mnt/cdrom.
If your applications access serial and parallel ports directly, you should map these onto the corresponding Unix devices - for example /dev/ttyS0 and /dev/lp0.
Here's the fundamental layout that Windows programs and installers expect and that we thus need to configure properly in Wine. Without it, they seldomly operate correctly. If you intend to use a no-windows environment (not using an existing Windows partition), then it is recommended to use either WineSetupTk's or wineinstall's capabilities to create an initial windows directory tree, since creating a directory structure manually is tiresome and error-prone.
C:\ Root directory of primary disk drive Windows\ Windows directory, containing .INI files, accessories, etc. System\ Win3.x/95/98/ME directory for common DLLs WinNT/2000 directory for common 16-bit DLLs System32\ WinNT/2000 directory for common 32-bit DLLs Start Menu\ Program launcher directory structure Programs\ Program launcher links (.LNK files) to programs Program Files\ Application binaries (.EXE and .DLL files)
The dosdevices directory contains the entries that tell Wine how to map Windows disc drive letters onto Unix file system nodes, and how to map Windows serial and parallel ports onto Unix devices. It is located in the .wine sub-directory of your home directory, i.e. ~/.wine/dosdevices.
The entries in the dosdevices directory are symbolic links to Unix file system nodes and devices. You can create them by using the ln command in a Unix terminal. Alternatively, many File Managers have the capability of creating symbolic links.
For example, if you have decided to map your Windows C: drive onto /usr/share/wine-c, you could type the following (after changing to your dosdevices directory):
ln -s /usr/share/wine-c c:
Replaceable media are a little more complicated. In addition to creating a link for the file system on the medium, for example:
ln -s /mnt/floppy a:you also need to create a link for the device itself. Notice that this has a double colon after the drive letter:
ln -s /dev/fd0 a::
For serial and parallel ports, you simply create a link to the device; notice that no colon is required after the Windows device name:
ln -s /dev/ttyS0 com1 ln -s /dev/lp0 lpt1
Windows shares can are mapped into the unc/ directory so anything trying to access \\machinename\some\dir\and\file will look in ~/.wine/dosdevices/unc/machinename/some/dir/and/file. For example, if you used Samba to mount \\machinename\some on /mnt/smb/machinename/some then you can do
ln -s /mnt/smb/machinename/some unc/machinename/someto make it available in wine (don't forget to create the unc directory if it doesn't alrady exist).
"Windows" = "c:\\windows"This tells Wine and Windows programs where the Windows directory is. It is recommended to have this directory somewhere on your configured C drive, and it's also recommended to just call the directory "windows" (this is the default setup on Windows, and some stupid programs might rely on this). So in case you chose a "Windows" setting of "c:\\windows" and you chose to set up a drive C e.g. at /usr/local/wine_c, the corresponding directory would be /usr/local/wine_c/windows. Make one if you don't already have one. No trailing slash (not C:\\windows\)! Write access strongly recommended, as Windows programs always assume write access to the Windows directory!
"ShowDirSymlinks" = "1"Wine doesn't pass directory symlinks to Windows programs by default, as doing so may crash some programs that do recursive lookups of whole subdirectory trees whenever a directory symlink points back to itself or one of its parent directories. That's why we disallowed the use of directory symlinks and added this setting to reenable ("1") this functionality. If you really need Wine to take into account symlinked directories, then reenable it, but be prepared for crashes in certain Windows programs when using the above method! (in other words: enabling it is certainly not recommended)
Old Path, Temp, System configuration are now moved into the registry. See the Environment Variables paragraph.
Windows uses a different (and inferior) way than Unix to describe the location of files in a computer. Thus Windows programs also expect to find this different way supported by the system. Since we intend to run Windows programs on a Unix system, we're in trouble, as we need to translate between these different file access techniques.
Windows uses drive letters to describe drives or any other form of storage media and to access files on them. For example, common drive names are C: for the main Windows system partition on the first harddisk and A: for the first floppy drive. Also, Windows uses \ (backslash) as the directory separator sign, whereas Unix uses / (slash). Thus, an example document on the first data partition in Windows might be accessed by the name of D:\mywork\mydocument.txt.
So much for the Windows way of doing things.
Well, the problem is, in Unix there is no such thing as "drive letters". Instead, Unix chose to go the much better way of having one single uniform directory tree (starting with the root directory /), which has various storage devices such as e.g. harddisk partitions appended at various directory locations within the tree (an example would be /data1/mywork, which is the first data partition mounted/attached to a directory called data1 in the root directory /; mywork is a sub directory of the data partition file system that's mounted under /data1). In Unix, the Windows example document mentioned above could e.g. be accessed by the name of /data1/mywork/mydocument.txt, provided that the administrator decided to mount (attach) the first data partition at the directory /data1 inside the Unix directory tree. Note that in Unix, the administrator can choose any custom partition location he wants (here, /data1), whereas in Windows the system selects any drive letter it deems suitable for the first data partition (here, D:), and, even worse, if there is some change in partition order, Windows automatically changes the drive letter, and you might suddenly find yourself with a first data partition at drive letter E:, with all the file naming and referencing confusion that entails. Thus, the Windows way of using ever-changing drive letters is clearly inferior to the Unix way of assigning fixed directory tree locations for every data storage medium. As we'll see soon, fortunately this Windows limitation of changing drive letters doesn't affect us in Wine at all, since we can properly map never-changing drive letters to fixed locations inside the Unix directory tree (and even if the location of the respective Unix directory changes, we can still simply update the Wine drive mapping to reflect the updated location and at the same time keep the original drive letter).
OK, now that we know some theory about Windows and Unix drive and filename mapping, it's probably time to ask how Wine achieves the magic of mapping a Unix directory location to a Windows drive...
Wine chose to do the following: In Wine, you don't assign some real physical storage medium (such as a harddisk partition or similar) to each drive letter mapping entry. Instead, you choose certain sub directory trees inside the Unix directory tree (that starts with /) that you would like to assign a drive letter to.
Note that for every Unix sub directory tree that you intend to start Windows programs in, it is absolutely required to have a Wine drive mapping entry:
For example, if you had a publicly writable "Windows directory space" under /usr/mywine, then in order to be able to access this sub directory tree from Wine, you should have a drive mapping entry that maps a certain drive letter (for example, let's take drive letter P:) either to /usr/mywine or /usr (to also access any directories belonging to the parent directory) or / (to also access any directory whatsoever on this system by this drive letter mapping). The DOS drive/directory location to access files in /usr/mywine in Wine in these configuration cases would then be P:\ or P:\mywine or P:\usr\mywine, respectively.
A major goal of Wine is to allow users to run Windows programs without having to install Windows on their machine. Wine implements the functionality of the main DLLs usually provided with Windows. Therefore, once Wine is finished, you will not need to have Windows installed to use Wine.
Wine has already made enough progress that it may be possible to run your target programs without Windows installed. If you want to try it, follow these steps:
Make a symbolic link in ~/.wine/dosdevices to the directory where you want C: to be. Refer to the wine man page for more information. The directory to be used for emulating a C: drive will be the base directory for some Windows specific directories created below.
Within the directory to be used for C:, create empty windows, windows/system, windows/Start Menu, and windows/Start Menu/Programs directories. Do not point Wine to a Windows directory full of old installations and a messy registry. (Wine creates a special registry in your home directory, in $HOME/.wine/*.reg. Perhaps you have to remove these files). In one line: mkdir -p windows windows/system windows/Start\ Menu windows/Start\ Menu/Programs
Run and/or install your programs.
Because Wine is not yet complete, some programs will work better with native Windows DLLs than with Wine's replacements. Wine has been designed to make this possible. Here are some tips by Juergen Schmied (and others) on how to proceed. This assumes that your C:\windows directory in the configuration file does not point to a native Windows installation but is in a separate Unix file system. (For instance, "C:\windows" is really subdirectory "windows" located in "/home/ego/wine/drives/c").
Run the program with WINEDEBUG=+loaddll
to find out which files are
needed. Copy the required DLLs one by one to the
C:\windows\system directory. Do not
copy KERNEL/KERNEL32, GDI/GDI32, USER/USER32 or NTDLL. These
implement the core functionality of the Windows API, and
the Wine internal versions must be used.
Edit the "[DllOverrides]" section of ~/.wine/config to specify "native" before "builtin" for the Windows DLLs you want to use. For more information about this, see the Wine manpage.
Note that some network DLLs are not needed even though Wine is looking for them. The Windows MPR.DLL currently does not work; you must use the internal implementation.
Copy SHELL.DLL/SHELL32.DLL, COMMDLG.DLL/COMDLG32.DLL and COMMCTRL.DLL/COMCTL32.DLL only as pairs to your Wine directory (these DLLs are "clean" to use). Make sure you have these specified in the "[DllPairs]" section of ~/.wine/config.
Be consistent: Use only DLLs from the same Windows version together.
Put regedit.exe in the C:\windows directory. (Office 95 imports a *.reg file when it runs with an empty registry, don't know about Office 97). As of now, it might not be necessary any more to use regedit.exe, since Wine has its own regedit Winelib application now.
Also add winhelp.exe and winhlp32.exe if you want to be able to browse through your programs' help function (or in case Wine's winhelp implementation in programs/winhelp/ is not good enough, for example).
Some people intend to use the data of an existing Windows partition with Wine in order to gain some better compatibility or to run already installed programs in a setup as original as possible. Note that many Windows programs assume that they have full write access to all windows directories. This means that you either have to configure the Windows partition mount point for write permission by your Wine user (see Dealing with FAT/VFAT partitions on how to do that), or you'll have to copy over (some parts of) the Windows partition content to a directory of a Unix partition and make sure this directory structure is writable by your user. We HIGHLY DISCOURAGE people from directly using a Windows partition with write access as a base for Wine!! (some programs, notably Explorer, corrupt large parts of the Windows partition in case of an incorrect setup; you've been warned). Not to mention that NTFS write support in Linux is still very experimental and dangerous (in case you're using an NT-based Windows version using the NTFS file system). Thus we advise you to go the Unix directory way.
This document describes how FAT and VFAT file system permissions work in Linux with a focus on configuring them for Wine.
Linux is able to access DOS and Windows file systems using either the FAT (older 8.3 DOS filesystems) or VFAT (newer Windows 95 or later long filename filesystems) modules. Mounted FAT or VFAT filesystems provide the primary means for which existing programs and their data are accessed through Wine for dual boot (Linux + Windows) systems.
Wine maps mounted FAT file systems, such as /c, to drive letters, such as "c:", by means of symbolic links in the dosdevices directory. Thus, in your dosdevices directory, you could type the command:
ln -s /c c:
Although VFAT filesystems are preferable to FAT filesystems for their long filename support, the term "FAT" will be used throughout the remainder of this document to refer to FAT filesystems and their derivatives. Also, "/c" will be used as the FAT mount point in examples throughout this document.
Most modern Linux distributions either detect or allow existing FAT file systems to be configured so that they can be mounted, in a location such as /c, either persistently (on bootup) or on an as needed basis. In either case, by default, the permissions will probably be configured so that they look like:
~>cd /c /c>ls -l -rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat -rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys drwxr-xr-x 41 root root 16384 Dec 30 1998 windows
where all the files are owned by "root", are in the "root" group and are only writable by "root" (755 permissions). This is restrictive in that it requires that Wine be run as root in order for programs to be able to write to any part of the filesystem.
There are three major approaches to overcoming the restrictive permissions mentioned in the previous paragraph:
Run Wine as root
Mount the FAT filesystem with less restrictive permissions
Shadow the FAT filesystem by completely or partially copying it
Each approach will be discussed in the following sections.
Running Wine as root is the easiest and most thorough way of giving programs that Wine runs unrestricted access to FAT files systems. Running wine as root also allows programs to do things unrelated to FAT filesystems, such as listening to ports that are less than 1024. Running Wine as root is dangerous since there is no limit to what the program can do to the system, so it's HIGHLY DISCOURAGED.
The FAT filesystem can be mounted with permissions less restrictive than the default. This can be done by either changing the user that mounts the FAT filesystem or by explicitly changing the permissions that the FAT filesystem is mounted with. The permissions are inherited from the process that mounts the FAT filesystem. Since the process that mounts the FAT filesystem is usually a startup script running as root the FAT filesystem inherits root's permissions. This results in the files on the FAT filesystem having permissions similar to files created by root. For example:
~>whoami root ~>touch root_file ~>ls -l root_file -rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
which matches the owner, group and permissions of files seen on the FAT filesystem except for the missing 'x's. The permissions on the FAT filesystem can be changed by changing root's umask (unset permissions bits). For example:
~>umount /c ~>umask 022 ~>umask 073 ~>mount /c ~>cd /c /c>ls -l -rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat -rwx---r-- 1 root root 245 Oct 10 17:58 config.sys drwx---r-- 41 root root 16384 Dec 30 1998 windows
Mounting the FAT filesystem with a umask of 000 gives all users complete control over it. Explicitly specifying the permissions of the FAT filesystem when it is mounted provides additional control. There are three mount options that are relevant to FAT permissions: uid, gid and umask. They can each be specified when the filesystem is manually mounted. For example:
~>umount /c ~>mount -o uid=500 -o gid=500 -o umask=002 /c ~>cd /c /c>ls -l -rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat -rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows
which gives "sle" complete control over /c. The options listed above can be made permanent by adding them to the /etc/fstab file:
~>grep /c /etc/fstab /dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1
Note that the umask of 002 is common in the user private group file permission scheme. On FAT file systems this umask assures that all files are fully accessible by all users in the specified user group (gid).
Shadowing provides a finer granularity of control. Parts of the original FAT filesystem can be copied so that the program can safely work with those copied parts while the program continues to directly read the remaining parts. This is done with symbolic links. For example, consider a system where a program named AnApp must be able to read and write to the c:\windows and c:\AnApp directories as well as have read access to the entire FAT filesystem. On this system the FAT filesystem has default permissions which should not be changed for security reasons or cannot be changed due to lack of root access. On this system a shadow directory might be set up in the following manner:
~>cd / />mkdir c_shadow />cd c_shadow /c_shadow>ln -s /c_/* . /c_shadow>rm windows AnApp /c_shadow>cp -R /c_/{windows,AnApp} . /c_shadow>chmod -R 777 windows AnApp /c_shadow>perl -p -i -e 's|/c$|/c_shadow|g' ~/.wine/config
The above gives everyone complete read and write access to the windows and AnApp directories while only root has write access to all other directories.
Wine can read drive volume labels and serial numbers directly from the device. This may be useful for many Win 9x games or for setup programs distributed on CD-ROMs that check for volume label.
Reading labels and serial numbers just works automatically if you specify the correct symbolic links for the devices (with double colons after the drive letters) in your dosdevices directory. Note that the device has to exist and must be accessible by the user running Wine if you do this, though.
If you don't want to read labels and serial numbers directly from the device, you can create files at the root of the drive named .windows-label and .windows-serial respectively. These are simple ASCII files that you can create with any text editor; the label can be set to any string you like, the serial number should be expressed as an hexadecimal number.
Here's a simple example of CD-ROM and floppy:
cd ~/.wine/dosdevices ln -s /mnt/floppy a: ln -s /dev/fd0 a:: ln -s /mnt/cdrom r: ln -s /dev/hda1 r::
The CD-ROM label can be read only if the data track of the disk resides in the first track and the cdrom is iso9660.
Support for labels/serial nums WRITING.
What about reading ext2 volume label? ....