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 0 |
Wine emulates drives by placing their virtual drive roots to user-configurable points in the Unix filesystem, so it's your choice where C:'s root should be (tools/wineinstall will even ask you). If you choose, say, ~/wine (or, in other words, /home/user/wine, since "~" indicates the home directory of a user), as the root of your virtual drive C:, then you'd put this into your Wine configuration file:
[Drive C] "Path" = "${HOME}/wine" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" |
With this configuration, what windows apps think of as "c:\windows\system" would map to /home/user/wine/windows/system in the UNIX filesystem. Note that you need to specify "Filesystem" = "win95", not "Filesystem" = "unix", to make Wine simulate a Windows compatible (case insensitive) filesystem, otherwise most apps won't work.
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) |
These sections are supposed to make certain Unix directory locations accessible to Wine as a DOS/Windows drive (drive 'x:') and thus accessible to Windows programs under the drive name you specified. Every DOS/Windows program sort of expects at least a C: drive (and sometimes also an A: floppy drive), so your configuration file should at least contain the corresponding sections, [Drive C] and [Drive A]. You need to decide on whether you want to use an existing Windows partition as the C drive or whether you want to create your own Wine drive C directory tree somewhere (take care about permissions!). Each drive section may specify up to 6 different settings as explained below.
[Drive x] |
"Path" = "/dir/to/path" |
"Path" = "${HOME}/mywinedrive" |
"Type" = "hd|cdrom|network|floppy" |
"Label" = "blah" |
"Serial" = "deadbeef" |
"Filesystem" = "win95|unix|msdos" |
Case insensitive. Alike to Windows 9x/NT 4. This is the long filename filesystem you are probably used to working with. The filesystem bæhaviour of choice for most programs to be run under wine. Probably the one you want!
Case sensitive. This filesystem has almost no use (Windows apps expect case insensitive filenames), except maybe for Winelib applications. Try it if you dare, but win95 is a much better and always recommended choice.
Case insensitive filesystem. Alike to DOS and Windows 3.x. 8.3 is the maximum length of files (eightdot.123) - longer ones will be truncated.
Note: This is a very bad choice if you plan on running apps that use long filenames. win95 should work fine with apps that were designed to run under the msdos system. In other words, you might not want to use this.
"Device" = "/dev/xx" |
Needed for raw device access and label and serial number reading. Use this only for floppy and cdrom devices. Using it on Extended2 or other Unix file systems can have dire results (when a windows app tries to do a lowlevel write, they do it in a FAT way -- FAT format is completely different from any Unix file system). Also, make sure that you have proper permissions to this device file.
Note: This setting is not really important; almost all apps will have no problem if it remains unspecified. For CD-ROMs it's quite useful in order to get automatic label detection, though. If you are unsure about specifying device names, just leave out this setting for your drives.
Here are a few sample entries:
Here is a setup for Drive C, a generic hard drive: [Drive C] "Path" = "/dosc" "Type" = "hd" "Label" = "Hard Drive" "Filesystem" = "win95" This is a setup for Drive E, a generic CD-ROM drive: [Drive E] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "Total Annihilation" "Filesystem" = "win95" "Device" = "/dev/cdrom" And here is a setup for Drive A, a generic floppy drive: [Drive A] "Type" = "floppy" "Path" = "/mnt/floppy" "Label" = "Floppy Drive" "Serial" = "87654321" "Filesystem" = "win95" "Device" = "/dev/fd0" |
"Windows" = "c:\\windows" |
"System" = "c:\\windows\\system" |
"Temp" = "c:\\temp" |
"Path" = "c:\\windows;c:\\windows\\system;c:\\blanco" |
Behaves like the PATH setting on UNIX boxes. When wine is run like wine sol.exe, if sol.exe resides in a directory specified in the Path setting, wine will run it (Of course, if sol.exe resides in the current directory, wine will run that one). Make sure it always has your windows directory and system directory (For this setup, it must have "c:\\windows;c:\\windows\\system").
"ShowDirSymlinks" = "1" |
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.
Written by James Juran <juran@cse.psu.edu>
(Extracted from wine/documentation/no-windows)
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:
Point [Drive C] in ~/.wine/config to the directory where you want C: to be. Refer to the wine.conf 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. Remember to use "Filesystem" = "win95"!
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 --debugmsg +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.
Written by Steven Elliott <elliotsl@mindspring.com>
(Extracted from wine/documentation/linux-fat-permissions)
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 filesystems, such as /c, to driver letters, such as "c:", as indicated by the ~/.wine/config file. The following excerpt from a ~/.wine/config file does this:
[Drive C] "Path" = "/c" "Type" = "hd" |
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 can not 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.
Written by Petr Tomasek <tomasek@etf.cuni.cz> Nov 14 1999
Changes by Andreas Mohr <andi@rhlx01.fht-esslingen.de> Jan 25 2000
(Extracted from wine/documentation/cdrom-labels)
Until now, your only possibility of specifying drive volume labels and serial numbers was to set them manually in the wine configuration file. By now, wine can read them directly from the device as well. 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 automagically if you specify a "Device" = line in the [Drive x] section in your ~/.wine/config. 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, then you should give fixed "Label" = or "Serial" = entries in ~/.wine/config, as Wine returns these entries instead if no device is given. If they don't exist, then Wine will return default values (label Drive X and serial 12345678).
If you want to give a "Device" = entry only for drive raw sector accesses, but not for reading the volume info from the device (i.e. you want a fixed, preconfigured label), you need to specify "ReadVolInfo" = "0" to tell Wine to skip the volume reading.
Here's a simple example of CD-ROM and floppy; labels will be read from the device on both CD-ROM and floppy; serial numbers on floppy only:
[Drive A] "Path" = "/mnt/floppy" "Type" = "floppy" "Device" = "/dev/fd0" "Filesystem" = "msdos" [Drive R] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Device" = "/dev/hda1" "Filesystem" = "win95" |
Here's an example of overriding the CD-ROM label:
[Drive J] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "X234GCDSE" ; note that the device isn't really needed here as we have a fixed label "Device" = "/dev/cdrom" "Filesystem" = "msdos" |
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.
Better checking for FAT superblock (it now checks only one byte).
Support for labels/serial nums WRITING.
Can the label be longer than 11 chars? (iso9660 has 32 chars).
What about reading ext2 volume label? ....