Written by &name-marcus-meissner; &email-marcus-meissner; Updated by &name-jeremy-white; &email-jeremy-white; Updated by &name-andreas-mohr; &email-andreas-mohr; The information contained in this document is extremely time sensitive. It is vital that a packager stay current with changes in Wine. Changes to this document could be tracked e.g. by viewing its CVS log. Due to Wine's fast development, a recent revision date does not necessarily indicate that this document is 100% on par with what Wine's full installation requirements are (especially whenever lazy developers don't properly update the documentation to include info about new features they implemented). This document was last revised on November 14, 2001. There are several terms and paths used in this document as place holders for configurable values. Those terms are described here. WINECONFDIR WINECONFDIR is the user's Wine configuration directory. This is almost always ~/.wine, but can be overridden by the user by setting the WINECONFDIR environment variable. PREFIX PREFIX is the prefix used when selecting an installation target. The current default is /usr. This results in binary installation into /usr/bin, library installation into /usr/wine/lib, and so forth. This value can be overridden by the packager. In fact, FHS 2.1 specifications suggest that a better prefix is /opt/wine. Ideally, a packager would also allow the installer to override this value. ETCDIR ETCDIR is the prefix that Wine uses to find the global configuration directory. This can be changed by the configure option sysconfdir. The current default is /etc. WINDOWSDIR WINDOWSDIR is an important concept to Wine. This directory specifies what directory corresponds to the root Windows directory (e.g. C:\WINDOWS). This directory is specified by the user, in the user's configuration file. Generally speaking, this directory is either set to point at an empty directory, or it is set to point at a Windows partition that has been mounted through the vfat driver. It is extremely important that the packager understand the importance of WINDOWSDIR and convey this information and choice to the end user. This document attempts to establish guidelines for people making binary packages of Wine. It expresses the basic principles that the Wine developers have agreed should be used when building Wine. It also attempts to highlight the areas where there are different approaches to packaging Wine, so that the packager can understand the different alternatives that have been considered and their rationales. An installation from a Wine package should: Install quickly and simply. The initial installation should require no user input. An rpm -i wine.rpm or apt-get install wine should suffice for initial installation. Work quickly and simply The user should be able to launch Solitaire within minutes of downloading the Wine package. Comply with Filesystem Hierarchy Standard A Wine installation should, as much as possible, comply with the FHS standard. Preserve flexibility None of the flexibility built into Wine should be hidden from the end user. Come as preconfigured as possible, so the user does not need to change any configuration files. Use only as much diskspace as needed per user. Reduce support requirements. A packaged version of Wine should be sufficiently easy to use and have quick and easy access to FAQs and documentation such that requests to the newsgroup and development group go down. Further, it should be easy for users to capture good bug reports. Successfully installing Wine requires: Much thought and work from the packager (1x) A configuration file Wine will not run without a configuration file. Further, no default is currently provided by Wine. Some packagers may attempt to provide (or dynamically generate) a default configuration file. Some packagers may wish to rely on winesetup to generate the configuration file. A writeable C:\ directory structure on a per-user basis. Applications do dump .ini files into c:\windows, installers dump .exe, .dll and more into c:\windows and subdirectories or into C:\Program Files. An initial set of registry entries. The current Wine standard is to use the regapi tool against the 'winedefault.reg' file to generate a default registry. There are several other choices that could be made; registries can be imported from a Windows partition. At this time, Wine does not completely support a complex multi-user installation ala Windows NT, but it could fairly readily. Some special .dll and .exe files in the windows\system directory, since applications directly check for their presence. This section lists all files that pertain to Wine. At the time of this writing, almost all of the following components are installed through a standard 'make install' of Wine. Exceptions from the rule are noted. It is vital that a packager check for changes in Wine. This list will likely be out of date by the time this document is committed to CVS. wine The main Wine executable. This program will load a Windows binary and run it, relying upon the Wine shared object libraries. wineserver The Wine server is critical to Wine; it is the process that coordinates all shared Windows resources. winebootup Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. wineclipsrv The Wine Clipboard Server is a standalone XLib application whose purpose is to manage the X selection when Wine exits. winedbg Winedbg is the Wine built in debugger. winelauncher (not getting installed via make install) A wine wrapper shell script that intelligently handles wine invocation by informing the user about what's going on, among other things. To be found in tools/ directory. Use of this wrapper script instead of directly using wine is strongly encouraged, as it not only improves the user interface, but also adds important functionality to wine, such as session bootup/startup actions. If you intend to use this script, then you might want to rename the wine executable to e.g. wine.bin and winelauncher to wine. the /config file. winesetup This is a Tcl/Tk based front end that provides a user friendly tool to edit and configure the /config file. wineshelllink This shell script can be called by Wine in order to propagate Desktop icon and menu creation requests out to a GNOME or KDE (or other Window Managers). winebuild Winebuild is a tool used for Winelib applications (and by Wine itself) to allow a developer to compile a .spec file into a .spec.c file. wmc The wmc tools is the Wine Message Compiler. It allows Windows message files to be compiled into a format usable by Wine. wrc The wrc tool is the Wine Resource Compiler. It allows Winelib programmers (and Wine itself) to compile Windows style resource files into a form usable by Wine. fnt2bdf The fnt2bdf utility extracts fonts from .fnt or .dll files and stores them in .bdf format files. dosmod DOS Virtual Machine. uninstaller (not getting installed via make install) A Winelib program to uninstall installed Windows programs. To be found in the programs/ source directory. This program can be used to uninstall most Windows programs (just like the Add/Remove Programs item in Windows) by taking the registry uninstall strings that get created by installers such as InstallShield or WISE. In binary packages, it should probably be renamed to something like wine-uninstaller for consistency's sake. Shared Object Library Files This list is NOT necessarily current ! advapi32.dll.so avicap32.dll.so avifil32.dll.so avifile.dll.so comctl32.dll.so comdlg32.dll.so comm.dll.so commdlg.dll.so compobj.dll.so crtdll.dll.so crypt32.dll.so dciman32.dll.so ddeml.dll.so ddraw.dll.so devenum.dll.so dinput.dll.so dispdib.dll.so display.dll.so dplay.dll.so dplayx.dll.so dsound.dll.so gdi.exe.so gdi32.dll.so glu32.dll.so icmp.dll.so imaadp32.acm.so imagehlp.dll.so imm.dll.so imm32.dll.so joystick.drv.so kernel32.dll.so keyboard.dll.so krnl386.exe.so libgdi32.dll.so libkernel32.dll.so libntdll.dll.so libuser32.dll.so libwine.so libwine_tsx11.so libwine_unicode.so libwinspool.drv.so lz32.dll.so lzexpand.dll.so mapi32.dll.so mcianim.drv.so mciavi.drv.so mcicda.drv.so mciseq.drv.so mciwave.drv.so midimap.drv.so mmsystem.dll.so mouse.dll.so mpr.dll.so msacm.dll.so msacm.drv.so msacm32.dll.so msdmo.dll.so msg711.drv.so msimg32.dll.so msnet32.dll.so msrle32.dll.so msvcrt.dll.so msvcrt20.dll.so msvfw32.dll.so msvideo.dll.so netapi32.dll.so ntdll.dll.so odbc32.dll.so ole2.dll.so ole2conv.dll.so ole2disp.dll.so ole2nls.dll.so ole2prox.dll.so ole2thk.dll.so ole32.dll.so oleaut32.dll.so olecli.dll.so olecli32.dll.so oledlg.dll.so olepro32.dll.so olesvr.dll.so olesvr32.dll.so opengl32.dll.so psapi.dll.so qcap.dll.so quartz.dll.so rasapi16.dll.so rasapi32.dll.so riched32.dll.so rpcrt4.dll.so serialui.dll.so setupapi.dll.so setupx.dll.so shdocvw.dll.so shell.dll.so shell32.dll.so shfolder.dll.so shlwapi.dll.so sound.dll.so sti.dll.so storage.dll.so stress.dll.so system.dll.so tapi32.dll.so toolhelp.dll.so ttydrv.dll.so twain_32.dll.so typelib.dll.so url.dll.so urlmon.dll.so user.exe.so user32.dll.so ver.dll.so version.dll.so w32skrnl.dll.so w32sys.dll.so win32s16.dll.so win87em.dll.so winaspi.dll.so windebug.dll.so winearts.drv.so winedos.dll.so wineoss.drv.so wineps.dll.so wineps16.dll.so wing.dll.so wininet.dll.so winmm.dll.so winnls.dll.so winnls32.dll.so winsock.dll.so winspool.drv.so wintrust.dll.so wnaspi32.dll.so wow32.dll.so wprocs.dll.so ws2_32.dll.so wsock32.dll.so x11drv.dll.so Man Pages wine.man wine.conf.man wmc.man wrc.man Include Files This list is NOT necessarily current ! basetsd.h cderr.h cguid.h commctrl.h commdlg.h compobj.h d3d.h d3dcaps.h d3dtypes.h d3dvec.inl dde.h ddeml.h ddraw.h digitalv.h dinput.h dispdib.h dlgs.h docobj.h dplay.h dplobby.h dsound.h guiddef.h imagehlp.h imm.h initguid.h instance.h lmcons.h lzexpand.h mapidefs.h mcx.h mmreg.h mmsystem.h msacm.h ntsecapi.h oaidl.h objbase.h objidl.h ocidl.h ole2.h ole2ver.h oleauto.h olectl.h oledlg.h oleidl.h poppack.h prsht.h psapi.h pshpack1.h pshpack2.h pshpack4.h pshpack8.h ras.h regstr.h richedit.h rpc.h servprov.h shellapi.h shlguid.h shlobj.h shlwapi.h sql.h sqlext.h sqltypes.h storage.h tapi.h tlhelp32.h unknwn.h urlmon.h ver.h vfw.h winbase.h wincon.h wincrypt.h windef.h windows.h windowsx.h wine/exception.h wine/icmpapi.h wine/ipexport.h wine/obj_base.h wine/obj_cache.h wine/obj_channel.h wine/obj_clientserver.h wine/obj_commdlgbrowser.h wine/obj_connection.h wine/obj_contextmenu.h wine/obj_control.h wine/obj_dataobject.h wine/obj_dockingwindowframe.h wine/obj_dragdrop.h wine/obj_enumidlist.h wine/obj_errorinfo.h wine/obj_extracticon.h wine/obj_inplace.h wine/obj_marshal.h wine/obj_misc.h wine/obj_moniker.h wine/obj_oleaut.h wine/obj_olefont.h wine/obj_oleobj.h wine/obj_oleundo.h wine/obj_oleview.h wine/obj_picture.h wine/obj_property.h wine/obj_propertystorage.h wine/obj_queryassociations.h wine/obj_shellbrowser.h wine/obj_shellextinit.h wine/obj_shellfolder.h wine/obj_shelllink.h wine/obj_shellview.h wine/obj_storage.h wine/unicode.h winerror.h wingdi.h wininet.h winioctl.h winnetwk.h winnls.h winnt.h winreg.h winresrc.h winsock.h winsock2.h winspool.h winsvc.h winuser.h winver.h wnaspi32.h wownt32.h wtypes.h zmouse.h Documentation files. At the time of this writing, I do not have a definitive list of documentation files to be installed. However, they do include the HTML files generated from the SGML in the Wine CVS tree. Wine also generates and depends on a number of dynamic files, including user configuration files and registry files. At the time of this writing, there was not a clear consensus of where these files should be located, and how they should be handled. This section attempts to explain the alternatives clearly. /config This file is the user local Wine configuration file. At the time of this writing, if this file exists, then no other configuration file is loaded. /wine.conf This is the global Wine configuration file. It is only used if the user running Wine has no local configuration file. Some packagers feel that this file should not be supplied, and that only a wine.conf.default should be given here. Other packagers feel that this file should be the predominant file used, and that users should only shift to a local configuration file if they need to. An argument has been made that the local configuration file should inherit the global configuration file. At this time, Wine does not do this; please refer to the WineHQ discussion archives for the debate concerning this. This debate is addressed more completely below, in . Registry Files In order to replicate the Windows registry system, Wine stores registry entries in a series of files. For an excellent overview of this issue, read this Wine Weekly News feature. The bottom line is that, at Wine server startup, Wine loads all registry entries into memory to create an in memory image of the registry. The order of files which Wine uses to load registry entries is extremely important, as it affects what registry entries are actually present. The order is roughly that .dat files from a Windows partion are loaded, then global registry settings from , and then finally local registry settings are loaded from . As each set are loaded, they can override the prior entries. Thus, the local registry files take precedence. Then, at exit (or at periodic intervals), Wine will write either all registry entries (or, with the default setting) changed registry entries to files in the . /system.reg This file contains the user's local copy of the HKEY_LOCAL_MACHINE registry hive. In general use, it will contain only changes made to the default registry values. /user.reg This file contains the user's local copy of the HKEY_CURRENT_USER registry hive. In general use, it will contain only changes made to the default registry values. /userdef.reg This file contains the user's local copy of the HKEY_USERS\.Default registry hive. In general use, it will contain only changes made to the default registry values. /wine.userreg This file is being deprecated. It is only read if there is no user.reg or wine.userreg, and it supplied the contents of HKEY_USERS. /wine.systemreg This file contains the global values for HKEY_LOCAL_MACHINE. The values in this file can be overridden by the user's local settings. The location of this directory is hardcoded within wine, generally to /etc. This will hopefully be fixed at some point in the future. /wine.userreg This file contains the global values for HKEY_USERS. The values in this file can be overridden by the user's local settings. This file is likely to be deprecated in favor of a global wine.userdef.reg that will only contain HKEY_USERS/.Default. /wineserver-[hostname] This directory contains files used by Wine and the Wineserver to communicate. A packager may want to have a facility for the user to erase files in this directory, as a crash in the wineserver resulting in a bogus lock file can render wine unusable. /cachedmetrics.[display] This file contains font metrics for the given X display. Generally, this cache is generated once at Wine start time. Wine has the ability to use files from an installation of the actual Microsoft Windows operating system. Generally these files are loaded on a VFAT partition that is mounted under Linux. This is probably the most important configuration detail. The use of Windows registry and DLL files dramatically alters the behaviour of Wine. If nothing else, pacakager have to make this distinction clear to the end user, so that they can intelligently choose their configuration. [WINDOWSDIR]/system32/system.dat [WINDOWSDIR]/system32/user.dat [WINDOWSDIR]/win.ini Windows Dynamic Link Libraries ([WINDOWSDIR]/system32/*.dll) Wine has the ability to use the actual Windows DLL files when running an application. An end user can configure Wine so that Wine uses some or all of these DLL files when running a given application. There has recently been a lot of discussion on the Wine development mailing list about the best way to build Wine packages. There was a lot of discussion, and several diverging points of view. This section of the document attempts to present the areas of common agreement, and also to present the different approaches advocated on the mailing list. The most basic question to ask is given the Wine CVS tree, what physical files are you, the packager, going to produce? Are you going to produce only a wine.rpm (as Marcus has done), or are you going to produce 6 Debian files (libwine, libwine-dev, wine, wine-doc, wine-utils and winesetuptk) as Ove has done? At this point, there is no consensus amongst the wine-devel community on this subject. This question is not really contested. It will vary by distribution, and is really up to the packager. As a guideline, the current 'make install' process seems to behave such that if we pick a single , then : all binary files go into /bin, all library files go into /lib, all include files go into /include, all documentation files go into /doc/wine, and man pages go into /man, Refer to the specific information on the Debian package and the OpenLinux package for specific details on how those packages are built. You might also want to use the wine wrapper script winelauncher that can be found in tools/ directory, as it has several important advantages over directly invoking the wine binary. See the Executable Files section for details. The FHS 2.1 specification suggests that Wine as a package should be installed to /opt/wine. None of the existing packages follow this guideline (today; check again tomorrow). After installing the static and shareable files, the next question the packager needs to ask is how much dynamic configuration will be done, and what configuration files should be created. There are several approaches to this: Rely completely on user file space - install nothing This approach relies upon the new winesetup utility and the new ability of Wine to launch winesetup if no configuration file is found. The basic concept is that no global configuration files are created at install time. Instead, Wine configuration files are created on the fly by the winesetup program when Wine is invoked. Further, winesetup creates default Windows directories and paths that are stored completely in the user's . This approach has the benefit of simplicity in that all Wine files are either stored under /opt/wine or under ~/.wine. Further, there is only ever one Wine configuration file. This approach, however, adds another level of complexity. It does not allow Wine to run Solitaire 'out of the box'; the user must run the configuration program first. Further, winesetup requires Tcl/Tk, a requirement not beloved by some. Additionally, this approach closes the door on multi user configurations and presumes a single user approach. Build a reasonable set of defaults for the global wine.conf, facilitate creation of a user's local Wine configuration. This approach, best shown by Marcus, causes the installation process to auto scan the system, and generate a global wine.conf file with best guess defaults. The OpenLinux packages follow this behaviour. The keys to this approach are always putting an existing Windows partition into the path, and being able to run Solitaire right out of the box. Another good thing that Marcus does is he detects a first time installation and does some clever things to improve the user's Wine experience. A flaw with this approach, however, is it doesn't give the user an obvious way to choose not to use a Windows partition. Build a reasonable set of defaults for the global wine.conf, and ask the user if possible This approach, demonstrated by Ove, causes the installation process to auto scan the system, and generate a global wine.conf file with best guess defaults. Because Ove built a Debian package, he was able to further query debconf and get permission to ask the user some questions, allowing the user to decide whether or not to use a Windows partition. The next hard question is what the Wine config should look like. The current best practices seems to involve using drives from M to Z. This isn't done yet! Fix it, Jer! Building the package WINE is configured the usual way (depending on your build environment). The "prefix" is chosen using your application placement policy (/usr/, /usr/X11R6/, /opt/wine/ or similar). The configuration files (wine.conf, wine.userreg, wine.systemreg) are targeted for /etc/wine/ (rationale: FHS 2.0, multiple readonly configuration files of a package). Example (split this into %build and %install section for rpm): CFLAGS=$RPM_OPT_FLAGS \ ./configure --prefix=/usr/X11R6 --sysconfdir=/etc/wine/ --enable-dll make BR=$RPM_BUILD_ROOT make install prefix=$BR/usr/X11R6/ sysconfdir=$BR/etc/wine/ install -d $BR/etc/wine/ install -m 644 wine.ini $BR/etc/wine/wine.conf # Put all our dlls in a seperate directory. (this works only if # you have a buildroot) install -d $BR/usr/X11R6/lib/wine mv $BR/usr/X11R6/lib/lib* $BR/usr/X11R6/lib/wine/ # the clipboard server is started on demand. install -m 755 windows/x11drv/wineclipsrv $BR/usr/X11R6/bin/ # The WINE server is needed. install -m 755 server/wineserver $BR/usr/X11R6/bin/ Here we unfortunately do need to create wineuser.reg and winesystem.reg from the WINE distributed winedefault.reg. This can be done using ./regapi once for one example user and then reusing his /user.reg and /system.reg files. this needs to be done better install -m 644 wine.sytemreg $BR/etc/wine/ install -m 644 wine.userreg $BR/etc/wine/ There are now a lot of libraries generated by the build process, so a seperate library directory should be used. install -d 755 $BR/usr/X11R6/lib/ mv $BR/ You will need to package the files: $prefix/bin/wine, $prefix/bin/dosmod, $prefix/lib/wine/* $prefix/man/man1/wine.1, $prefix/include/wine/*, $prefix/bin/wineserver, $prefix/bin/wineclipsrv %config /etc/wine/* %doc ... choose from the toplevel directory and documentation/ The post-install script: if ! grep -q /usr/X11R6/lib/wine /etc/ld.so.conf; then echo "/usr/X11R6/lib/wine" >> /etc/ld.so.conf fi /sbin/ldconfig The post-uninstall script: if [ "$1" = 0 ]; then perl -ni -e 'print unless m:/usr/X11R6/lib/wine:;' /etc/ld.so.conf fi /sbin/ldconfig Creating a good default configuration file For the rationales of needing as less input from the user as possible arises the need for a very good configuration file. The one supplied with WINE is currently lacking. We need: [Drive X]: A for the floppy. Specify your distribution's default floppy mountpoint here. Path=/auto/floppy C for the C:\ directory. Here we use the user's home directory, for most applications do see C:\ as root-writeable directory of every windows installation and this basically is it in the UNIX-user context. Path=${HOME} R for the CD-Rom drive. Specify your distribution's default CD-ROM drives mountpoint here. Path=/auto/cdrom T for temporary storage. We do use /tmp/ (rationale: between process temporary data belongs to /tmp/, FHS 2.0) W for the original Windows installation. This drive points to the windows\ subdirectory of the original windows installation. This avoids problems with renamed windows directories (as for instance lose95, win or sys\win95). During compile/package/install we leave this to be /, it has to be configured after the package install. Z for the UNIX Root directory. This avoids any problems with "could not find drive for current directory" users occasionally complain about in the newsgroup and the irc channel. It also makes the whole directory structure browseable. The type of Z should be network, so applications expect it to be readonly. Path=/ [wine]: Windows=c:\windows\ (the windows/ subdirectory in the user's home directory) System=c:\windows\system\ (the windows/system subdirectory in the user's home directory) Path=c:\windows;c:\windows\system;c:\windows\system32;w:\;w:\system;w:\system32; ; Using this trick we have in fact two windows installations in one, we ; get the stuff from the readonly installation and can write to our own. Temp=t:\ (the TEMP directory) [Tweak.Layout] WineLook=win95 (just the coolest look ;) Possibly modify the [spooler], [serialports] and [parallelports] sections. possibly more, including printer stuff. Add this prepared configuration file to the package. Installing WINE for the system administrator Install the package using the usual packager rpm -i wine.rpm. You may edit /etc/wine/wine.conf, [Drive W], to point to a possible windows installation right after the install. That's it. Note that on Linux you should somehow try to add the unhide mount option (see man mount) to the CD-ROM entry in /etc/fstab during package install, as several stupid Windows programs mark some setup (!) files as hidden (ISO9660) on CD-ROMs, which will greatly confuse users as they won't find their setup files on the CD-ROMs as they were used on Windows systems when unhide is not set ;-\ And of course the setup program will complain that setup.ins or some other mess is missing... If you choose to do so, then please make this change verbose to the admin. Also make sure that the kernel you use includes the Joliet CD-ROM support, for the very same reasons as given above (no long filenames due to missing Joliet, files not found). Installing WINE for the user The user will need to run a setup script before the first invocation of WINE. This script should: Copy /etc/wine/wine.conf for user modification. Allow specification of the original windows installation to use (which modifies the copied wine.conf file). Create the windows directory structure (c:\windows, c:\windows\system, c:\windows\Start Menu\Programs, c:\Program Files, c:\Desktop, etc.) Symlink all .dll and .exe files from the original windows installation to the windows directory. Why? Some programs reference "%windowsdir%/file.dll" or "%systemdir%/file.dll" directly and fail if they are not present. This will give a huge number of symlinks, yes. However, if an installer later overwrites one of those files, it will overwrite the symlink (so that the file now lies in the windows/ subdirectory). Not sure this is needed for all files. On later invocation the script might want to compare regular files in the user's windows directories and in the global windows directories and replace same files by symlinks (to avoid diskspace problems). ;; ;; MS-DOS drives configuration ;; ;; Each section has the following format: ;; [Drive X] ;; Path=xxx (Unix path for drive root) ;; Type=xxx (supported types are 'floppy', 'hd', 'cdrom' and 'network') ;; Label=xxx (drive label, at most 11 characters) ;; Serial=xxx (serial number, 8 characters hexadecimal number) ;; Filesystem=xxx (supported types are 'msdos'/'dos'/'fat', 'win95'/'vfat', 'unix') ;; This is the FS Wine is supposed to emulate on a certain ;; directory structure. ;; Recommended: ;; - "win95" for ext2fs, VFAT and FAT32 ;; - "msdos" for FAT16 (ugly, upgrading to VFAT driver strongly recommended) ;; DON'T use "unix" unless you intend to port programs using Winelib ! ;; Device=/dev/xx (only if you want to allow raw device access) ;; ; ; ; Floppy 'A' and 'B' ; ; OpenLinux uses an automounter under /auto/, so we use that too. ; [Drive A] Path=/auto/floppy/ Type=floppy Label=Floppy Serial=87654321 Device=/dev/fd0 Filesystem=win95 ; ; Comment in ONLY if you have a second floppy or the automounter hangs ; for 5 minutes. ; ;[Drive B] ;Path=/auto/floppy2/ ;Type=floppy ;Label=Floppy ;Serial=87654321 ;Device=/dev/fd1 ;Filesystem=win95 ; ; Drive 'C' links to the user's homedirectory. ; ; This must point to a writeable directory structure (not your readonly ; mounted DOS partitions!) since programs want to dump stuff into ; "Program Files/" "Programme/", "windows/", "windows/system/" etc. ; ; The basic structure is set up using the config script. ; [Drive C] Path=${HOME} Type=hd Label=MS-DOS Filesystem=win95 ; ; /tmp/ directory ; ; The temp drive (and directory) points to /tmp/. Windows programs fill it ; with junk, so it is approbiate. ; [Drive T] Path=/tmp Type=hd Label=Tmp Drive Filesystem=win95 ; ; 'U'ser homedirectory ; ; Just in case you want C:\ elsewhere. ; [Drive U] Path=${HOME} Type=hd Label=Home Filesystem=win95 ; ; CD-'R'OM drive (automounted) ; ; The default cdrom drive. ; ; If an application (or game) wants a specific CD-ROM you might have to ; temporary change the Label to the one of the CD itself. ; ; How to read them is described in /usr/doc/wine-cvs-xxxxx/cdrom-labels. ; [Drive R] Path=/auto/cdrom Type=cdrom Label=CD-Rom Filesystem=win95 ; ; The drive where the old windows installation resides (it points to the ; windows/ subdirectory). ; ; The Path is modified by the winesetup script. ; [Drive W] Path=/ Type=network Label=Windows Filesystem=win95 ; ; The UNIX Root directory, so all other programs and directories are reachable. ; ; type network is used to tell programs to not write here. ; [Drive Z] Path=/ Type=network Label=ROOT Filesystem=win95 ; ; Standard Windows path entries. WINE will not work if they are incorrect. ; [wine] ; ; The windows/ directory. It must be writeable, for programs write into it. ; Windows=c:\windows ; ; The windows/system/ directory. It must be writeable, for especially setup ; programs install dlls in there. ; System=c:\windows\system ; ; The temp directory. Should be cleaned regulary, since install programs leave ; junk without end in there. ; Temp=t:\ ; ; The dll search path. It should contain at least: ; - the windows and the windows/system directory of the user. ; - the global windows and windows/system directory (from a possible readonly ; windows installation either on msdos filesystems or somewhere in the UNIX ; directory tree) ; - any other windows style directories you want to add. ; Path=c:\windows;c:\windows\system;c:\windows\system32;t:\;w:\;w:\system;w:\system32 ; ; Outdated and no longer used. (but needs to be present). ; SymbolTableFile=./wine.sym # <wineconf> ; ; Dll loadorder defaults. No need to modify. ; [DllDefaults] EXTRA_LD_LIBRARY_PATH=${HOME}/wine/cvs/lib DefaultLoadOrder = native, elfdll, so, builtin ; ; What 32/16 dlls belong to each other (context wise). No need to modify. ; [DllPairs] kernel = kernel32 gdi = gdi32 user = user32 commdlg = comdlg32 commctrl= comctl32 ver = version shell = shell32 lzexpand= lz32 mmsystem= winmm msvideo = msvfw32 winsock = wsock32 ; ; What type of dll to use in their respective loadorder. ; [DllOverrides] kernel32, gdi32, user32 = builtin kernel, gdi, user = builtin toolhelp = builtin comdlg32, commdlg = elfdll, builtin, native version, ver = elfdll, builtin, native shell32, shell = builtin, native lz32, lzexpand = builtin, native commctrl, comctl32 = builtin, native wsock32, winsock = builtin advapi32, crtdll, ntdll = builtin, native mpr, winspool = builtin, native ddraw, dinput, dsound = builtin, native winmm, mmsystem = builtin msvideo, msvfw32 = builtin, native mcicda.drv, mciseq.drv = builtin, native mciwave.drv = builtin, native mciavi.drv, mcianim.drv = native, builtin w32skrnl = builtin wnaspi32, wow32 = builtin system, display, wprocs = builtin wineps = builtin ; ; Options section. Does not need to be edited. ; [options] ; allocate how much system colors on startup. No need to modify. AllocSystemColors=100 ;; ; Font specification. You usually do not need to edit this section. ; ; Read documentation/fonts before adding aliases ; [fonts] ; The resolution defines what fonts to use (usually either 75 or 100 dpi fonts, ; or nearest match). Resolution = 96 ; Default font Default = -adobe-times- ; ; serial ports used by "COM1" "COM2" "COM3" "COM4". Useful for applications ; that try to access serial ports. ; [serialports] Com1=/dev/ttyS0 Com2=/dev/ttyS1 Com3=/dev/modem,38400 Com4=/dev/modem ; ; parallel port(s) used by "LPT1" etc. Useful for applications that try to ; access these ports. ; [parallelports] Lpt1=/dev/lp0 ; ; What spooling program to use on printing. ; Use "|program" or "filename", where the output will be dumped into. ; [spooler] LPT1:=|lpr LPT2:=|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q - LPT3:=/dev/lp3 ; ; Allow port access to WINE started by the root user. Useful for some ; supported devices, but it can make the system unstable. ; Read /usr/doc/wine-cvs-xxxxx/ioport-trace-hints. ; [ports] ;read=0x779,0x379,0x280-0x2a0 ;write=0x779,0x379,0x280-0x2a0 ; debugging, not need to be modified. [spy] Exclude=WM_SIZE;WM_TIMER; ; ; What names for the registry datafiles, no need to modify. ; [Registry] ; Paths must be given in /dir/dir/file.reg format. ; Wine will not understand dos file names here... ;UserFileName=xxx ; alternate registry file name (user.reg) ;LocalMachineFileName=xxx ; (system.reg) ; ; Layout/Look modifications. Here you can switch with a single line between ; windows 3.1 and windows 95 style. ; This does not change WINE behaviour or reported versions, just the look! ; [Tweak.Layout] ;; WineLook=xxx (supported styles are 'Win31'(default), 'Win95', 'Win98') WineLook=Win95 ; ; What programs to start on WINE startup. (you should probably leave it empty) ; [programs] Default= Startup= ; defunct section. [Console] ;XtermProg=nxterm ;InitialRows=25 ;InitialColumns=80 ;TerminalType=nxterm # </wineconf> In preparing this document, it became clear that there were still a range of action items to be done in Wine that would improve this packaging process. For lack of a better place, I record them here. This list is almost certain to be obsolete; check bugzilla for a better list. Remove duplication of code between winesetup and wineconf/wineinstall. Currently, winesetup duplicates all of the code contained in wineconf. Instead, wineconf should be improved to generate the new style config file, and then winesetup should rely on wineconf to generate the default configuration file. Similarly, there is functionality such as creating the default registry files that is now done by both winesetup and wineinstall. At this time, it seems like the right thing to do is to break up or parameterize wineinstall, so that it can be used for single function actions, and then have winesetup call those functions. Enhance winesetup to support W: drive generation. The best practices convention now seems to be to generate a set of drives from M: through W:. At this point, winesetup does not generate a default wine config file that follows these conventions. It should. Enhance Wine to allow more dynamic switching between the use of a real Windows partition and an empty one. Write a winelauncher utility application. Currently, Wine really requires a user to launch it from a command line, so that the user can look for error messages and warnings. However, eventually, we will want users to be able to launch Wine from a more friendly GUI launcher. The launcher should have the ability to allow the end user to turn on debugging messages and capture those traces for bug reporting purposes. Also, if we make it possible to switch between use of a Windows partition or not automatically, that option should be controlled here. Get Marcus's winesetup facilities into CVS Along the lines of the changes to winesetup, and the consolidation of wineconf and wineinstall, we should extract the good stuff from Marcus's winesetup script, and get it into CVS. Again, perhaps we should have a set of scripts that perform discrete functions, or maybe one script with parameters. Finish this document This document is pretty rough itself. Many hard things aren't addressed, and lots of stuff was missed.