How to install Wine... Written by Ove Kåven ovek@winehq.com A Windows installation consists of many different parts. Registry. Many keys are supposed to exist and contain meaningful data, even in a newly-installed Windows. Directory structure. Applications expect to find and/or install things in specific predetermined locations. Most of these directories are expected to exist. But unlike Unix directory structures, most of these locations are not hardcoded, and can be queried via the Windows API and the registry. This places additional requirements on a Wine installation. System DLLs. In Windows, these usually reside in the system (or system32) directories. Some Windows applications check for their existence in these directories before attempting to load them. While Wine is able to load its own internal DLLs (.so files) when the application asks for a DLL, Wine does not simulate the existence of nonexisting files. While the users are of course free to set up everything themselves, the Wine team will make the automated Wine installation script, tools/wineinstall, do everything we find necessary to do; running the conventional configure && make depend && make && make install cycle is thus not recommended, unless you know what you're doing. At the moment, tools/wineinstall is able to create a configuration file, install the registry, and create the directory structure itself. The default registry is in the file winedefault.reg. It contains directory paths, class IDs, and more; it must be installed before most INSTALL.EXE or SETUP.EXE applications will work. The registry is covered in more detail in an earlier article. Here's the fundamental layout that Windows applications and installers expect. Without it, they seldom operate correctly. 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 applications Program Files\ Application binaries (.EXE and .DLL files) 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, /var/wine, as the root of your virtual drive C, then you'd put this in your wine.conf: [Drive C] Path=/var/wine Type=hd Label=MS-DOS Filesystem=win95 With this configuration, what windows apps think of as "c:\windows\system" would map to /var/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. The Wine team has determined that it is necessary to create fake DLL files to trick many applications that check for file existence to determine whether a particular feature (such as Winsock and its TCP/IP networking) is available. If this is a problem for you, you can create empty files in the system directory to make the application think it's there, and Wine's built-in DLL will be loaded when the application actually asks for it. (Unfortunately, tools/wineinstall does not create such empty files itself.) Applications sometimes also try to inspect the version resources from the physical files (for example, to determine the DirectX version). Empty files will not do in this case, it is rather necessary to install files with complete version resources. This problem is currently being worked on. In the meantime, you may still need to grab some real DLL files to fool these apps with. And there are of course DLLs that wine does not currently implement very well (or at all). If you do not have a real Windows you can steal necessary DLLs from, you can always get some from a DLL archive such as http://solo.abac.com/dllarchive/. written by ??? (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 DLL's 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 applications without Windows installed. If you want to try it, follow these steps: Create empty C:\windows, C:\windows\system, C:\windows\Start Menu, and C:\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). Point [Drive C] in wine.conf or .winerc to where you want C: to be. Refer to the Wine man page for more information. Remember to use filesystem=win95! Use tools/wineinstall to compile Wine and install the default registry. Or if you prefer to do it yourself, compile programs/regapi, and run: programs/regapi/regapi setValue < winedefault.reg Run and/or install your applications. Because Wine is not yet complete, some programs will work better with native Windows DLL's 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 application with --debugmsg +module,+file to find out which files are needed. Copy the required DLL's one by one to the C:\windows\system directory. Do not copy KERNEL/KERNEL32, GDI/GDI32, or USER/USER32. These implement the core functionality of the Windows API, and the Wine internal versions must be used. Edit the [DllOverrides] section of wine.conf or .winerc to specify native before builtin for the Windows DLL's you want to use. For more information about this, see the Wine manpage. Note that some network DLL's 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/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32 only as pairs to your Wine directory (these DLL's are clean to use). Make sure you have these specified in the [DllPairs] section of wine.conf or .winerc. Be consistent: Use only DLL's from the same Windows version together. Put regedit.exe in the C:\windows directory (office95 imports a *.reg file when it runs with a empty registry, don't know about office97). Also add winhelp.exe and winhlp32.exe if you want to be able to browse through your programs' help function. 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 applications 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.conf file. The following excerpt from a wine.conf 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 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 something 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 applications to be able to write to any part of the filesystem. There 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 applications that Wine runs unrestricted access to FAT files systems. Running wine as root also allows applications 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 application can do to the system. 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 group (gid). Shadowing provides a finer granularity of control. Parts of the original FAT filesystem can be copied so that the application can safely work with those copied parts while the application continue to directly read the remaining parts. This is done with symbolic links. For example, consider a system where an application 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' /usr/local/etc/wine.conf 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 Bruce Milner; Additions by Andreas Mohr (Extracted from wine/documentation/aspi) This file describes setting up the Windows ASPI interface. THIS MAY TRASH YOUR SYSTEM IF USED INCORRECTLY THIS MAY TRASH YOUR SYSTEM IF USED CORRECTLY Now that I have said that. ASPI is a direct link to SCSI devices from windows programs. ASPI just forwards the SCSI commands that programs send to it to the SCSI bus. If you use the wrong scsi device in your setup file, you can send completely bogus commands to the wrong device - An example would be formatting your hard drives (assuming the device gave you permission - if you're running as root, all bets are off). So please make sure that **all** SCSI devices not needed by the program have their permissions set as restricted as possible ! Cookbook for setting up scanner: (At least how mine is to work) The scanner software needs to use the "Adaptec" compatible drivers (ASPI). At least with Mustek, they allow you the choice of using the builtin card or the "Adaptec (AHA)" compatible drivers. This will not work any other way. Software that accesses the scanner via a DOS ASPI driver (e.g. ASPI2DOS) is supported, too. [AM] You probably need a real windows install of the software to set the LUN's/SCSI id's up correctly. I'm not exactly sure. Your scsi card must be supported under linux. This will not work with an unknown scsi card. Even for cheap'n crappy "scanner only" controllers some special Linux drivers exist on the net. Compile generic scsi drivers into your kernel. Linux by default uses smaller scsi buffers than Windows. There is a kernel build define SG_BIG_BUFF (in sg.h) that is by default set too low. The SANE project recommends 130560 and this seems to work just fine. This does require a kernel rebuild. Make the devices for the scanner (generic scsi devices) - look at the scsi programming how-to for device numbering. I would recommend making the scanner device writable by a group. I made a group called scanner and added myself to it. Running as root increases your risk of sending bad scsi commands to the wrong device. With a regular user, you are better protected. Add a scsi device entry for your particular scanner to wine.conf. The format is [scsi cCtTdD] where C=controller, T=target, D=LUN For example, I set mine up as controller 0, Target 6, LUN 0. [scsi c0t6d0] Device=/dev/sgi Yours will vary with your particular SCSI setup. The mustek scanner I have was shipped with a package "ipplus". This program uses the TWAIN driver specification to access scanners. (TWAIN MANAGER) ipplus.exe <---> (TWAIN INTERFACE) <---> (TWAIN DATA SOURCE . ASPI) -> WINASPI The biggest is that it only works under linux at the moment. The ASPI code has only been tested with: a Mustek 800SP with a Buslogic controller under Linux [BM] a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux accessed via DOSASPI. Note that I had color problems, though (barely readable result) [AM] a Fujitsu M2513A MO drive (640MB) using generic scsi drivers. Formatting and ejecting worked perfectly. Thanks to Uwe Bonnes for access to the hardware ! [AM] I make no warranty to the aspi code. It makes my scanner work. Your devices may explode. I have no way of determining this. I take zero responsibility!