| <!-- Wine Packaging guidelines. This is a rough outline only, |
| and much of this was up for open debate on wine-devel. --> |
| |
| <chapter id="pkg-preface"> <title>Preface</title> |
| |
| <sect1 id="pkg-authors"> <title>Authors</title> |
| |
| <para> |
| Written by &name-marcus-meissner; <email>&email-marcus-meissner;</email> |
| Updated by &name-jeremy-white; <email>&email-jeremy-white;</email> |
| </para> |
| </sect1> |
| |
| <sect1 id="pkg-date"> <title>Document Revision Date</title> |
| |
| |
| <para> |
| The information contained in this document is extremely |
| time sensitive. <emphasis>It is vital that a packager |
| stay current with changes in Wine. </> |
| </para> |
| <para> |
| This document was last revised on November 2, 2000.</para> |
| |
| </sect1> |
| |
| <sect1 id="pkg-terms"> <title>Terms used in this document</title> |
| |
| <para>There are several terms and paths used in this |
| document as place holders for configurable values. |
| Those terms are described here. |
| </para> |
| |
| <orderedlist> |
| <listitem id=WINECONFDIR><para id=wineconfdir.id><EnVar>WINECONFDIR</EnVar></para> |
| <para> |
| <envar>WINECONFDIR</envar> is the users Wine configuration directory. |
| This is almost always ~/.wine, but can be overridden |
| by the user by setting the <EnVar>WINECONFDIR</EnVar> environment |
| variable. |
| </para> |
| </listitem> |
| |
| <listitem id=PREFIX><para id=prefix.id><EnVar>PREFIX</EnVar></para> |
| <para> |
| <envar>PREFIX</envar> 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, <ulink url="http://www.pathname.com/fhs/">FHS 2.1</ulink> |
| specifications suggest that a better |
| prefix is /opt/wine. Ideally, a packager would also |
| allow the installer to override this value. |
| </para> |
| </listitem> |
| |
| <listitem id=ETCDIR><para id=etcdir.id><EnVar>ETCDIR</EnVar></para> |
| <para> |
| <envar>ETCDIR</envar> 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. |
| </para> |
| </listitem> |
| |
| <listitem id=WINDOWSDIR><para id=windowsdir.id><EnVar>WINDOWSDIR</EnVar></para> |
| <para> |
| <envar>WINDOWSDIR</envar> is an important concept |
| to Wine. This directory specifies what directory |
| corresponds to the root Windows directory |
| (e.g. C:\WINDOWS). |
| </para> |
| <para> |
| This directory is specified by the user, in |
| the users <link linkend=winerc>configuration file</link>. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| <emphasis>It is extremely important that the packager |
| understand the importance of <envar>WINDOWSDIR</envar> |
| and convey this information and choice to the end |
| user</emphasis>. |
| </para> |
| </listitem> |
| |
| </orderedlist> |
| |
| |
| </sect1> |
| |
| </chapter> |
| |
| |
| |
| <chapter id="pkg-introduction"> <title>Introduction</title> |
| |
| <para> |
| This document attempts to establish guidelines |
| for people making binary packages of Wine. |
| </para> |
| |
| <para> |
| 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. |
| </para> |
| |
| <sect1 id="pkg-goals"> <title>Goals</title> |
| <para> |
| An installation from a Wine pacakage should: |
| </para> |
| <itemizedlist> |
| |
| <listitem> |
| <para> |
| Install quickly and simply. |
| </para> |
| <para> |
| The initial installation should require no user |
| input. An rpm -i wine.rpm or apt get wine |
| should suffice for initial installation. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Work quickly and simply |
| </para> |
| <para> |
| The user should be able to launch Solitaire |
| within minutes of downloading the Wine package. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Comply with Filesystem Hierarchy Standard |
| </para> |
| <para> |
| A Wine installation should, as much as possible, comply |
| with the |
| <ulink url="http://www.pathname.com/fhs/">FHS standard</ulink>. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Preserve flexibility |
| </para> |
| <para> |
| None of the flexibility built into Wine should |
| be hidden from the end user. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Come as preconfigured as possible, so the user does |
| not need to change any configuration files. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para>Use only as much diskspace as needed per user.</para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Reduce support requirements. |
| </para> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| |
| </itemizedlist> |
| |
| |
| </sect1> |
| |
| <sect1 id="pkg-requirements"> <title>Requirements</title> |
| <para> |
| Successfully installing Wine requires: |
| </para> |
| |
| <itemizedlist> |
| <listitem> |
| <para>Much thought and work from the packager (1x)</para> |
| </listitem> |
| <listitem> |
| <para> |
| A configuration file |
| </para> |
| <para> |
| Wine will not run with out 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 winecfg to generate the configuration file. |
| </para> |
| </listitem> |
| |
| |
| <listitem> |
| <para> |
| A writeable <filename>C:\</filename> directory |
| structure on a per user basis. Applications do dump |
| <filename>.ini</filename> files into |
| <filename>c:\windows</filename>, installers dump |
| <filename>.exe</filename>, <filename>.dll</filename> |
| and more into <filename>c:\windows\</filename> and |
| subdirectories or into <filename>C:\Program |
| Files\</filename>. |
| </para> |
| </listitem> |
| |
| |
| <listitem> |
| <para> |
| An initial set of registry entries. |
| </para> |
| <para> |
| The current Wine standard is to use the regapi tool |
| against the 'winedefault.reg' file to generate |
| a default registry. |
| </para> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| |
| |
| <listitem> |
| <para> |
| Some special <filename>.dll</filename> and |
| <filename>.exe</filename> files in the |
| <filename>windows\system</filename> directory, since |
| applications directly check for their presence. |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| </sect1> |
| |
| |
| </chapter> |
| |
| |
| |
| |
| <chapter id="pkg-components"><title>Wine Components</title> |
| |
| <para> |
| This section lists all files that pertain to Wine. |
| </para> |
| |
| <sect1 id="pkg-static"><title>Wine Static and Shareable Files</title> |
| |
| <para> |
| At the time of this writing, the following components |
| are installed through a standard 'make install' |
| of Wine. |
| |
| <caution> |
| <para> |
| 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. |
| </para> |
| </caution> |
| |
| </para> |
| |
| <orderedlist> |
| |
| <listitem id=binfiles> |
| <variablelist><title>Executable Files</title> |
| |
| <varlistentry><term><filename>wine</filename></term> |
| <listitem> |
| <para> |
| The main Wine executable. This program will load |
| a Windows binary and run it, relying upon |
| the Wine shared object libraries. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>wineserver</filename></term> |
| <listitem> |
| <para> |
| The Wine server is critical to Wine; it is the |
| process that coordinates all shared Windows |
| resources. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>wineclipsrv</filename></term> |
| <listitem> |
| <para> |
| The Wine Clipboard Server is a standalone XLib |
| application whose purpose is to manage the X selection |
| when Wine exits. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>winedbg</filename></term> |
| <listitem> |
| <para> |
| Winedbg is the Wine built in debugger. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>winecfg</filename></term> |
| <listitem> |
| <para> |
| This is a Tcl/Tk based front end that provides |
| a user friendly tool to edit and configure |
| the <link linkend=WINECONFDIR endterm=wineconfdir.id></link>/config file. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>wineshelllink</filename></term> |
| <listitem> |
| <para> |
| This shell script can be called by Wine in order |
| to propogate Desktop icon and menu creation |
| requests out to a GNOME or KDE (or other |
| Window Managers). |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>winebuild</filename></term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| </varlistentry> |
| <varlistentry><term><filename>wmc</filename></term> |
| <listitem> |
| <para> |
| The wmc tools is the Wine Message Compiler. It |
| allows Windows message files to be compiled |
| into a format usable by Wine. |
| </para> |
| </listitem> |
| </varlistentry> |
| <varlistentry><term><filename>wrc</filename></term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| </varlistentry> |
| <varlistentry><term><filename>fnt2bdf</filename></term> |
| <listitem> |
| <para> |
| The fnt2bdf utility extracts fonts from .fnt or |
| .dll files and stores then in .dbf format files. |
| </para> |
| </listitem> |
| </varlistentry> |
| <varlistentry><term><filename>dosmod</filename></term> |
| <listitem> |
| <para> |
| DOS Virtual Machine. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| </variablelist> |
| </listitem> |
| |
| <listitem id=libfiles> |
| <para> Shared Object Library Files </para> |
| |
| <simplelist columns=5> |
| |
| <member>libwine.so.1.0</> |
| <member>libddraw.so.1.0</> |
| <member>libopengl32.so.1.0</> |
| <member>libx11drv.so.1.0</> |
| <member>libadvapi32.so.1.0</> |
| <member>libavifil32.so.1.0</> |
| <member>libcomctl32.so.1.0</> |
| <member>libcomdlg32.so.1.0</> |
| <member>libcrtdll.so.1.0</> |
| <member>libdciman32.so.1.0</> |
| <member>libdinput.so.1.0</> |
| <member>libdplay.so.1.0</> |
| <member>libdplayx.so.1.0</> |
| <member>libdsound.so.1.0</> |
| <member>libgdi32.so.1.0</> |
| <member>libicmp.so.1.0</> |
| <member>libimagehlp.so.1.0</> |
| <member>libimm32.so.1.0</> |
| <member>libkernel32.so.1.0</> |
| <member>liblz32.so.1.0</> |
| <member>libmpr.so.1.0</> |
| <member>libmsacm32.so.1.0</> |
| <member>libmsnet32.so.1.0</> |
| <member>libmsvfw32.so.1.0</> |
| <member>libodbc32.so.1.0</> |
| <member>libole32.so.1.0</> |
| <member>liboleaut32.so.1.0</> |
| <member>libolecli32.so.1.0</> |
| <member>liboledlg.so.1.0</> |
| <member>libolepro32.so.1.0</> |
| <member>libolesvr32.so.1.0</> |
| <member>libpsapi.so.1.0</> |
| <member>librasapi32.so.1.0</> |
| <member>libriched32.so.1.0</> |
| <member>librpcrt4.so.1.0</> |
| <member>libserialui.so.1.0</> |
| <member>libsetupapi.so.1.0</> |
| <member>libshell32.so.1.0</> |
| <member>libshfolder.so.1.0</> |
| <member>libshlwapi.so.1.0</> |
| <member>libtapi32.so.1.0</> |
| <member>libttydrv.so.1.0</> |
| <member>liburlmon.so.1.0</> |
| <member>libuser32.so.1.0</> |
| <member>libversion.so.1.0</> |
| <member>libw32skrnl.so.1.0</> |
| <member>libwnaspi32.so.1.0</> |
| <member>libwineps.so.1.0</> |
| <member>libwininet.so.1.0</> |
| <member>libjoystick.drv.so.1.0</> |
| <member>libwinmm.so.1.0</> |
| <member>libmcianim.drv.so.1.0</> |
| <member>libmciavi.drv.so.1.0</> |
| <member>libmcicda.drv.so.1.0</> |
| <member>libmciseq.drv.so.1.0</> |
| <member>libmciwave.drv.so.1.0</> |
| <member>libmidimap.drv.so.1.0</> |
| <member>libmsacm.drv.so.1.0</> |
| <member>libwineoss.drv.so.1.0</> |
| <member>libws2_32.so.1.0</> |
| <member>libwinspool.drv.so.1.0</> |
| <member>libwow32.so.1.0</> |
| <member>libwsock32.so.1.0</> |
| <member>libwine_unicode.so.1.0</> |
| </simplelist> |
| |
| </listitem> |
| |
| |
| <listitem id=manfiles> |
| <para> Man Pages</para> |
| <simplelist columns=1> |
| <member>wine.man</> |
| <member>wine.conf.man</> |
| <member>wmc.man</> |
| <member>wrc.man</> |
| </simplelist> |
| |
| </listitem> |
| |
| |
| <listitem id=includefiles> |
| <para> Include Files</para> |
| <simplelist columns=5> |
| |
| <member>basetsd.h</> |
| <member>cderr.h</> |
| <member>cguid.h</> |
| <member>commctrl.h</> |
| <member>commdlg.h</> |
| <member>compobj.h</> |
| <member>d3d.h</> |
| <member>d3dcaps.h</> |
| <member>d3dtypes.h</> |
| <member>d3dvec.inl</> |
| <member>dde.h</> |
| <member>ddeml.h</> |
| <member>ddraw.h</> |
| <member>digitalv.h</> |
| <member>dinput.h</> |
| <member>dispdib.h</> |
| <member>dlgs.h</> |
| <member>docobj.h</> |
| <member>dplay.h</> |
| <member>dplobby.h</> |
| <member>dsound.h</> |
| <member>guiddef.h</> |
| <member>imagehlp.h</> |
| <member>imm.h</> |
| <member>initguid.h</> |
| <member>instance.h</> |
| <member>lmcons.h</> |
| <member>lzexpand.h</> |
| <member>mapidefs.h</> |
| <member>mcx.h</> |
| <member>mmreg.h</> |
| <member>mmsystem.h</> |
| <member>msacm.h</> |
| <member>ntsecapi.h</> |
| <member>oaidl.h</> |
| <member>objbase.h</> |
| <member>objidl.h</> |
| <member>ocidl.h</> |
| <member>ole2.h</> |
| <member>ole2ver.h</> |
| <member>oleauto.h</> |
| <member>olectl.h</> |
| <member>oledlg.h</> |
| <member>oleidl.h</> |
| <member>poppack.h</> |
| <member>prsht.h</> |
| <member>psapi.h</> |
| <member>pshpack1.h</> |
| <member>pshpack2.h</> |
| <member>pshpack4.h</> |
| <member>pshpack8.h</> |
| <member>ras.h</> |
| <member>regstr.h</> |
| <member>richedit.h</> |
| <member>rpc.h</> |
| <member>servprov.h</> |
| <member>shellapi.h</> |
| <member>shlguid.h</> |
| <member>shlobj.h</> |
| <member>shlwapi.h</> |
| <member>sql.h</> |
| <member>sqlext.h</> |
| <member>sqltypes.h</> |
| <member>storage.h</> |
| <member>tapi.h</> |
| <member>tlhelp32.h</> |
| <member>unknwn.h</> |
| <member>urlmon.h</> |
| <member>ver.h</> |
| <member>vfw.h</> |
| <member>winbase.h</> |
| <member>wincon.h</> |
| <member>wincrypt.h</> |
| <member>windef.h</> |
| <member>windows.h</> |
| <member>windowsx.h</> |
| <member>wine/exception.h</> |
| <member>wine/icmpapi.h</> |
| <member>wine/ipexport.h</> |
| <member>wine/obj_base.h</> |
| <member>wine/obj_cache.h</> |
| <member>wine/obj_channel.h</> |
| <member>wine/obj_clientserver.h</> |
| <member>wine/obj_commdlgbrowser.h</> |
| <member>wine/obj_connection.h</> |
| <member>wine/obj_contextmenu.h</> |
| <member>wine/obj_control.h</> |
| <member>wine/obj_dataobject.h</> |
| <member>wine/obj_dockingwindowframe.h</> |
| <member>wine/obj_dragdrop.h</> |
| <member>wine/obj_enumidlist.h</> |
| <member>wine/obj_errorinfo.h</> |
| <member>wine/obj_extracticon.h</> |
| <member>wine/obj_inplace.h</> |
| <member>wine/obj_marshal.h</> |
| <member>wine/obj_misc.h</> |
| <member>wine/obj_moniker.h</> |
| <member>wine/obj_oleaut.h</> |
| <member>wine/obj_olefont.h</> |
| <member>wine/obj_oleobj.h</> |
| <member>wine/obj_oleundo.h</> |
| <member>wine/obj_oleview.h</> |
| <member>wine/obj_picture.h</> |
| <member>wine/obj_property.h</> |
| <member>wine/obj_propertystorage.h</> |
| <member>wine/obj_queryassociations.h</> |
| <member>wine/obj_shellbrowser.h</> |
| <member>wine/obj_shellextinit.h</> |
| <member>wine/obj_shellfolder.h</> |
| <member>wine/obj_shelllink.h</> |
| <member>wine/obj_shellview.h</> |
| <member>wine/obj_storage.h</> |
| <member>wine/unicode.h</> |
| <member>winerror.h</> |
| <member>wingdi.h</> |
| <member>wininet.h</> |
| <member>winioctl.h</> |
| <member>winnetwk.h</> |
| <member>winnls.h</> |
| <member>winnt.h</> |
| <member>winreg.h</> |
| <member>winresrc.h</> |
| <member>winsock.h</> |
| <member>winsock2.h</> |
| <member>winspool.h</> |
| <member>winsvc.h</> |
| <member>winuser.h</> |
| <member>winver.h</> |
| <member>wnaspi32.h</> |
| <member>wownt32.h</> |
| <member>wtypes.h</> |
| <member>zmouse.h</> |
| </simplelist> |
| |
| </listitem> |
| |
| <listitem id=docfiles> |
| <para> |
| Documentation files. |
| </para> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| |
| |
| </orderedlist> |
| |
| </sect1> |
| |
| |
| <sect1 id="pkg-nonstatic"><title>Dynamic Wine Files</title> |
| |
| <para> |
| Wine also generates and depends on a number of dynamic |
| files, including user configuration files and registry files. |
| </para> |
| |
| <para> |
| 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. |
| </para> |
| |
| <orderedlist> |
| |
| <listitem> |
| <variablelist><title>Configuration File</title> |
| <varlistentry id=winerc><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/config</filename></term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term> |
| <filename><link linkend=ETCDIR endterm=etcdir.id></link>/wine.conf</filename></term> |
| <listitem> |
| <para> |
| This is the global Wine configuration file. It |
| is only used if the user running Wine has |
| no local configuration file. |
| </para> |
| <para> |
| Some packagers feel that this file should not |
| be supplied, and that only a wine.conf.default |
| should be given here. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| This debate is addressed more completely |
| below, in <link linkend=pkg-strategy endterm=strategy.id></link>. |
| </para> |
| </listitem> |
| </varlistentry> |
| </variablelist> |
| |
| </listitem> |
| |
| <listitem> |
| |
| <para>Registry Files</para> |
| |
| <para> |
| 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 |
| <ulink url="http://www.winehq.com/News/2000-25.html#FTR"> |
| Wine Weekly News feature.</ulink> |
| |
| </para> |
| |
| <para> |
| 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 <link linkend=ETCDIR endterm=etcdir.id></link>, |
| and then finally local registry settings are |
| loaded from <link linkend=WINECONFDIR endterm=wineconfdir.id></link> |
| . As each set are loaded, |
| they can override the prior entries. Thus, |
| the local registry files take precedence. |
| </para> |
| |
| <para> |
| 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 |
| <link linkend=WINECONFDIR endterm=wineconfdir.id></link>. |
| </para> |
| |
| <variablelist> |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/system.reg</filename></term> |
| <listitem> |
| <para> |
| This file contains the users local copy of |
| the HKEY_LOCAL_MACHINE registry hive. In general |
| use, it will contain only changes made to the |
| default registry values. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/user.reg</filename></term> |
| <listitem> |
| <para> |
| This file contains the users local copy of |
| the HKEY_CURRENT_USER registry hive. In |
| general use, it will contain only changes made to the |
| default registry values. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/userdef.reg</filename></term> |
| <listitem> |
| <para> |
| This file contains the users local copy of |
| the HKEY_USERS\.Default registry hive. In |
| general use, it will contain only changes made to the |
| default registry values. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/wine.userreg</filename></term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename><link linkend=ETCDIR endterm=etcdir.id></link>/wine.systemreg</filename></term> |
| <listitem> |
| <para> |
| This file contains the global values for |
| HKEY_LOCAL_MACHINE. The values in this file |
| can be overriden by the users local settings. |
| </para> |
| <note> |
| <para> |
| The location of this directory is hard coded within |
| wine, generally to /etc. This will hopefully be |
| fixed at some point in the future. |
| </para> |
| </note> |
| </listitem> |
| </varlistentry> |
| |
| |
| <varlistentry><term><filename><link linkend=ETCDIR endterm=etcdir.id></link>/wine.userreg</filename></term> |
| <listitem> |
| <para> |
| This file contains the global values for |
| HKEY_USERS. The values in this file |
| can be overriden by the users local settings. |
| This file is likely to be deprecated in |
| favor of a global wine.userdef.reg that will |
| only contain HKEY_USERS/.Default. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| </variablelist> |
| |
| |
| </listitem> |
| |
| <listitem> |
| <variablelist><title>Other files in <link linkend=WINECONFDIR endterm=wineconfdir.id></link></title> |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/wineserver-[username]</filename></term> |
| <listitem> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/cachedmetrics.[display]</filename></term> |
| <listitem> |
| <para> |
| This file contains font metrics for the given X display. |
| Generally, this cache is generated once at Wine start time. |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| </variablelist> |
| </listitem> |
| |
| |
| </orderedlist> |
| |
| |
| </sect1> |
| |
| <sect1 id="pkg-winpartition"><title>Important Files from a Windows Partition</title> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| |
| |
| <orderedlist> |
| |
| <listitem> |
| <variablelist><title>Registry Files</title> |
| <varlistentry><term><filename>[WINDOWSDIR]/system32/system.dat</filename></term> |
| <listitem> |
| <para> |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>[WINDOWSDIR]/system32/user.dat</filename></term> |
| <listitem> |
| <para> |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry><term><filename>[WINDOWSDIR]/win.ini</filename></term> |
| <listitem> |
| <para> |
| </para> |
| </listitem> |
| </varlistentry> |
| |
| </variablelist> |
| |
| </listitem> |
| |
| <listitem> |
| <para> |
| Windows Dynamic Link Libraries ([WINDOWSDIR]/system32/*.dll) |
| </para> |
| <para> |
| Wine has the ability to use the actuall 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. |
| </para> |
| </listitem> |
| |
| </orderedlist> |
| |
| </sect1> |
| |
| </chapter> |
| |
| <chapter id="pkg-strategy"><title id=strategy.id>Packaging Strategies</title> |
| |
| <para> |
| There has recently been a lot of discussion on the Wine |
| development mailing list about the best way to |
| build Wine packages. |
| </para> |
| <para> |
| 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. |
| </para> |
| |
| <sect1 id="pkg-whatfiles"><title>Distribution of Wine into packages</title> |
| <para> |
| 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 5 debian files |
| (libwine-dev, libwine, wine-doc, wine-utils, and wine) as |
| Ove has done? |
| </para> |
| <para> |
| At this point, there is no consensus |
| amongst the wine-devel community on this subject. |
| </para> |
| </sect1> |
| |
| <sect1 id="pkg-wherefiles"><title>Where to install files</title> |
| <para> |
| 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 <link linkend=PREFIX endterm=prefix.id></link>, |
| then : |
| </para> |
| <orderedlist> |
| |
| <listitem> |
| <para> |
| all <link linkend=binfiles>binary files</link> go into |
| <link linkend=PREFIX endterm=prefix.id></link>/bin, |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| all <link linkend=libfiles>library files</link> go into |
| <link linkend=PREFIX endterm=prefix.id></link>/lib, |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| all <link linkend=includefiles>include files</link> go into |
| <link linkend=PREFIX endterm=prefix.id></link>/include, |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| all <link linkend=docfiles>documentation files</link> go into |
| <link linkend=PREFIX endterm=prefix.id></link>/doc/wine, |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| and <link linkend=manfiles>man pages</link> go into |
| <link linkend=PREFIX endterm=prefix.id></link>/man, |
| </para> |
| </listitem> |
| |
| </orderedlist> |
| |
| <para> |
| Refer to the specific information on the Debian package |
| and the OpenLinux package for specific details on how |
| those packages are built. |
| </para> |
| |
| <sect2 id=opt><title>The question of /opt/wine</title> |
| <para> |
| 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). |
| </para> |
| </sect2> |
| |
| </sect1> |
| |
| <sect1 id="pkg-whattomake"><title>What files to create</title> |
| <para> |
| 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. |
| </para> |
| <para> |
| There are several approaches to this: |
| <orderedlist> |
| <listitem> |
| <para> |
| Rely completely on user file space - install nothing |
| </para> |
| <para> |
| This approach relies upon the new winecfg utility and |
| the new ability of Wine to launch winecfg 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 winecfg program when Wine is invoked. |
| Further, winecfg creates default Windows directories |
| and paths that are stored completely in |
| the users <link linkend=WINECONFDIR endterm=wineconfdir.id></link>. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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, |
| winecfg 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. |
| </para> |
| </listitem> |
| |
| |
| <listitem> |
| <para> |
| Build a reasonable set of defaults for the global wine.conf, |
| facilitate creation of a user's local Wine configuration. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| A flaw with this approach, however, is it doesn't |
| give the user an obvious way to choose not to |
| use a Windows partition. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Build a reasonable set of defaults for the global wine.conf, |
| and ask the user if possible |
| </para> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| |
| |
| </orderedlist> |
| </para> |
| |
| </sect1> |
| |
| |
| <sect1 id="pkg-wineconf"><title>What to put into the wine config file</title> |
| <para> |
| 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. |
| </para> |
| <caution><para>This isn't done yet! Fix it, Jer!</para></caution> |
| </sect1> |
| |
| |
| </chapter> |
| |
| |
| |
| |
| <chapter id="pkg-implementation"> <title>Implementation</title> |
| |
| <sect1 id="pkg-openlinux"><title>OpenLinux Sample</title> |
| |
| <orderedlist inheritnum="inherit"> |
| <listitem> |
| <para>Building the package</para> |
| <para> |
| WINE is configured the usual way (depending on your |
| build environment). The "prefix" is chosen using your |
| application placement policy |
| (<filename>/usr/</filename>, |
| <filename>/usr/X11R6/</filename>, |
| <filename>/opt/wine/</filename> or similar). The |
| configuration files (<filename>wine.conf</filename>, |
| <filename>wine.userreg</filename>, |
| <filename>wine.systemreg</filename>) are targeted for |
| <filename>/etc/wine/</filename> (rationale: FHS 2.0, |
| multiple readonly configuration files of a package). |
| </para> |
| <para> |
| Example (split this into <literal>%build</literal> and |
| <literal>%install</literal> section for |
| <command>rpm</command>): |
| </para> |
| <screen> |
| 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/ |
| </screen> |
| <para> |
| Here we unfortunately do need to create |
| <filename>wineuser.reg</filename> and |
| <filename>winesystem.reg</filename> from the WINE |
| distributed <filename>winedefault.reg</filename>. This |
| can be done using <command>./regapi</command> once for |
| one example user and then reusing his |
| <filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/user.reg</filename> and |
| <filename><link linkend=WINECONFDIR endterm=wineconfdir.id></link>/system.reg</filename> files. |
| <note> |
| <title>FIXME</title> |
| <para>this needs to be done better</para> |
| </note> |
| </para> |
| <screen> |
| install -m 644 wine.sytemreg $BR/etc/wine/ |
| install -m 644 wine.userreg $BR/etc/wine/ |
| </screen> |
| <para> |
| There are now a lot of libraries generated by the |
| build process, so a seperate library directory should |
| be used. |
| </para> |
| <screen> |
| install -d 755 $BR/usr/X11R6/lib/ |
| mv $BR/ |
| </screen> |
| <para> |
| You will need to package the files: |
| </para> |
| <screen> |
| $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/ |
| </screen> |
| <para> |
| The post-install script: |
| </para> |
| <screen> |
| if ! grep -q /usr/X11R6/lib/wine /etc/ld.so.conf; then |
| echo "/usr/X11R6/lib/wine" >> /etc/ld.so.conf |
| fi |
| /sbin/ldconfig |
| </screen> |
| <para> |
| The post-uninstall script: |
| </para> |
| <screen> |
| if [ "$1" = 0 ]; then |
| perl -ni -e 'print unless m:/usr/X11R6/lib/wine:;' /etc/ld.so.conf |
| fi |
| /sbin/ldconfig |
| </screen> |
| </listitem> |
| <listitem> |
| <para>Creating a good default configuration file</para> |
| <para> |
| 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: |
| </para> |
| <itemizedlist> |
| <listitem> |
| <para> |
| [Drive X]: |
| </para> |
| <itemizedlist> |
| <listitem> |
| <para> |
| A for the floppy. Specify your distributions |
| default floppy mountpoint here. |
| </para> |
| <programlisting> |
| Path=/auto/floppy |
| </programlisting> |
| </listitem> |
| <listitem> |
| <para> |
| C for the <filename>C:\</filename> directory. |
| Here we use the users homedirectory, for most |
| applications do see <filename>C:\</filename> |
| as root-writeable directory of every windows |
| installation and this basically is it in the |
| UNIX-user context. |
| </para> |
| <programlisting> |
| Path=${HOME} |
| </programlisting> |
| </listitem> |
| <listitem> |
| <para> |
| R for the CD-Rom drive. Specify your |
| distributions default CD-ROM drives mountpoint |
| here. |
| </para> |
| <programlisting> |
| Path=/auto/cdrom |
| </programlisting> |
| </listitem> |
| <listitem> |
| <para> |
| T for temporary storage. We do use |
| <filename>/tmp/</filename> (rationale: between |
| process temporary data belongs to |
| <filename>/tmp/</filename>, FHS 2.0) |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| W for the original Windows installation. This |
| drive points to the |
| <filename>windows\</filename> subdirectory of |
| the original windows installation. This avoids |
| problems with renamed |
| <filename>windows</filename> directories (as |
| for instance <filename>lose95</filename>, |
| <filename>win</filename> or |
| <filename>sys\win95</filename>). During |
| compile/package/install we leave this to be |
| <filename>/</filename>, it has to be |
| configured after the package install. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Z for the UNIX Root directory. This avoids any |
| problems with "could not find drive for |
| current directory" users occasionaly complain |
| about in the newsgroup and the ircchannel. It |
| also makes the whole directory structure |
| browseable. The type of Z should be network, |
| so applications expect it to be readonly. |
| </para> |
| <programlisting> |
| Path=/ |
| </programlisting> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| <listitem> |
| <para> |
| [wine]: |
| </para> |
| <screen> |
| Windows=c:\windows\ (the windows/ subdirectory in the users |
| homedirectory) |
| System=c:\windows\system\ (the windows/system subdirectory in the users |
| homedirectory) |
| 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) |
| </screen> |
| </listitem> |
| <listitem> |
| <para>[Tweak.Layout]</para> |
| <screen> |
| WineLook=win95 (just the coolest look ;) |
| </screen> |
| </listitem> |
| <listitem> |
| <para> |
| Possibly modify the [spooler], [serialports] and |
| [parallelports] sections. |
| </para> |
| <note> |
| <title>FIXME</title> |
| <para>possibly more, including printer stuff.</para> |
| </note> |
| </listitem> |
| </itemizedlist> |
| |
| <para>Add this prepared configuration file to the package.</para> |
| </listitem> |
| <listitem> |
| <para>Installing WINE for the system administrator</para> |
| <para> |
| Install the package using the usual packager |
| <command>rpm -i wine.rpm</command>. You may edit |
| <filename>/etc/wine/wine.conf</filename>, [Drive W], |
| to point to a possible windows installation right |
| after the install. That's it. |
| </para> |
| <para> |
| Note that on Linux you should somehow try to add the |
| <option>unhide</option> mount option (see <command>man |
| mount</command>) to the CD-ROM entry in |
| <filename>/etc/fstab</filename> 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 <option>unhide</option> is not |
| set ;-\ And of course the setup program will complain |
| that <filename>setup.ins</filename> or some other mess |
| is missing... If you choose to do so, then please make |
| this change verbose to the admin. |
| </para> |
| </listitem> |
| <listitem> |
| <para>Installing WINE for the user</para> |
| <para> |
| The user will need to run a setup script before the |
| first invocation of WINE. This script should: |
| </para> |
| |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| Copy <filename>/etc/wine/wine.conf</filename> for |
| user modification. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Allow specification of the original windows |
| installation to use (which modifies the copied |
| <filename>wine.conf</filename> file). |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Create the windows directory structure |
| (<filename>c:\windows</filename>, |
| <filename>c:\windows\system</filename>, |
| <filename>c:\windows\Start Menu\Programs</filename>, |
| <filename>c:\Program Files</filename>, |
| <filename>c:\Desktop</filename>, etc.) |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Symlink all <filename>.dll</filename> and |
| <filename>.exe</filename> files from the original |
| windows installation to the |
| <filename>windows</filename> directory. Why? Some |
| programs reference "%windowsdir%/file.dll" or |
| "%systemdir%/file.dll" directly and fail if they |
| are not present. |
| </para> |
| <para> |
| This will give a huge number of symlinks, yes. |
| However, if an installer later overwrites on of |
| those files, it will overwrite the symlink (so |
| that the file now lies in the |
| <filename>windows/</filename> subdirectory). |
| </para> |
| <note> |
| <title>FIXME</title> |
| <para>Not sure this is needed for all files.</para> |
| </note> |
| </listitem> |
| <listitem> |
| <para> |
| On later invocation the script might want to |
| compare regular files in the users windows |
| directories and in the global windows directories |
| and replace same files by symlinks (to avoid |
| diskspace problems). |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| |
| </listitem> |
| </orderedlist> |
| |
| |
| <sect2 id=sample><title>Sample <filename>wine.ini</filename> for OpenLinux 2.x:</title> |
| |
| <programlisting> |
| |
| |
| ;; |
| ;; 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 users 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> |
| </programlisting> |
| |
| </sect2> |
| </sect1> |
| |
| </chapter> |
| |
| <chapter id="pkg-todo"><Title>Work to be done</title> |
| |
| <para> |
| 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. |
| <emphasis>This list is almost certain to be obsolete; |
| check bugzilla for a better list.</emphasis> |
| </para> |
| |
| <orderedlist> |
| <listitem> |
| <para> |
| Remove duplication of code between winecfg and |
| wineconf/wineinstall. |
| </para> |
| <para> |
| Currently, winecfg duplicates all of the code contained |
| in wineconf. |
| </para> |
| <para> |
| Instead, wineconf should be improved to generate |
| the new style config file, and then winecfg should |
| rely on wineconf to generate the default |
| configuration file. |
| </para> |
| <para> |
| Similarly, there is functionality such as creating |
| the default registry files that is now done by |
| both winecfg and wineinstall. |
| </para> |
| <para> |
| 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 winecfg call those functions. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Enhance winecfg to support W: drive generation. |
| </para> |
| <para> |
| The best practices convention now seems to be |
| to generate a set of drives from M: through W:. |
| At this point, winecfg does not generate |
| a default wine config file that follows |
| these conventions. It should. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Enhance Wine to allow more dynamic switching |
| between the use of a real Windows partition |
| and an empty one. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Write a winelauncher utility application. |
| </para> |
| <para> |
| 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. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Get Marcus's winesetup facilities into CVS |
| </para> |
| <para> |
| Along the lines of the changes to winecfg, |
| 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. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| Finish this document |
| </para> |
| <para> |
| This document is pretty rough itself. Many hard |
| things aren't addressed, and lots of stuff was missed. |
| </para> |
| </listitem> |
| </orderedlist> |
| </chapter> |
| |
| |
| <!-- Keep this comment at the end of the file |
| Local variables: |
| mode: sgml |
| sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "") |
| End: |
| --> |
