PrefaceAuthors
Written by &name-marcus-meissner; &email-marcus-meissner;
Updated by &name-jeremy-white; &email-jeremy-white;
Updated by &name-andreas-mohr; &email-andreas-mohr;
Updated by &name-tom-wickline; &email-tom-wickline;Document Revision Date
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 January 16, 2003.Terms used in this documentThere are several terms and paths used in this
document as place holders for configurable values.
Those terms are described here.
WINECONFDIRWINECONFDIR 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.
PREFIXPREFIX is the prefix used when selecting
an installation target. The current default is /usr/local.
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.2
specifications suggest that a better
prefix is /opt/wine. Ideally, a packager would also
allow the installer to override this value.
ETCDIRETCDIR 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 $prefix/etc.
WINDOWSDIRWINDOWSDIR 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.
Introduction
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.
Goals
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.
Requirements
Successfully installing Wine requires:
Much thought and work from the packager (1x)
A configuration file
Wine will not run without a configuration file. Wine provides a
a sample config file and it can be found in /usr/share/doc/wine/samples.
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 regedit tool
against the 'winedefault.reg' file to generate
a default registry.
The current preferred method of configuring/installing
Wine is to run /toos/wineinstall.
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.
Wine Components
This section lists all files that pertain to Wine.
Wine Static and Shareable Files
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.
Executable Fileswine
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.
wineboot
Winelib app to be found in programs/.
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.
It'll be called by Wine automatically when an application
requests a restart of the system (presumeably - after
installation).
It should also be called once when a session starts to
run the various session start utilities (will not happen
automatically). To start a session, invoke "wineboot start".
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 FilesThis list may NOT necessarily current!advapi32.dll.so>
avicap32.dll.so>
avifil32.dll.so>
avifile.dll.so>
aviinfo.exe.so>
aviplay.exe.so>
clock.exe.so >
comcat.dll.so>
comctl32.dll.so>
comdlg32.dll.so>
comm.dll.so>
commdlg.dll.so>
compobj.dll.so>
control.exe.so>
crtdll.dll.so>
crypt32.dll.so>
dciman32.dll.so>
ddeml.dll.so>
ddraw.dll.so>
devenum.dll.so>
dinput.dll.so>
dinput8.dll.so>
dispdib.dll.so>
display.dll.so>
dplay.dll.so>
dplayx.dll.so>
dsound.dll.so>
expand.exe.so>
gdi.exe.so>
gdi32.dll.so>
glu32.dll.so>
icmp.dll.so>
imaadp32.acm.so>
imagehlp.dll.so>
icinfo.exe.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>
msacm.drv.so>
msnet32.dll.so>
msrle32.dll.so>
msdmo.dll.so>
msg711.acm.so>
msimg32.dll.so>
msisys.ocx.so>
msnet32.dll.so>
msrle32.dll.so>
msvcrt.dll.so>
msvcrt20.dll.so>
msvfw32.dll.so>
msvideo.dll.so>
netapi32.dll.so>
notepad.exe.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>
osversioncheck.exe.so>
progman.exe.so>
psapi.dll.so>
qcap.dll.so>
quartz.dll.so>
rasapi16.dll.so>
rasapi32.dll.so>
regapi.exe.so>
regedit.exe.so >
regsvr32.exe.so>
regtest.exe.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>
uninstaller.exe.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>
winealsa.drv.so>
winearts.drv.so>
wineconsole.exe.so>
winedbg.exe.so>
winedos.dll.so>
winefile.exe.so>
winemine.exe.so>
winemp3.acm.so>
wineoss.drv.so>
winepath.exe.so>
wineps.dll.so>
wineps16.dll.so>
wing.dll.so>
winhelp.exe.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 Pageswine.conf.man>
wine.man>
winemaker>
wmc.man>
wrc.man>
Include FilesThis list may NOT be current!audevcod.h>
basetsd.h>
cderr.h>
cguid.h>
comcat.h>
commctrl.h>
commdlg.h>
compobj.h>
cpl.h>
d3d.h>
d3dcaps.h>
d3dtypes.h>
d3dvec.inl>
dde.h>
ddeml.h>
ddraw.h>
digitalv.h>
dinput.h>
dispdib.h>
dlgs.h>
dmo.h>
dmoreg.h>
dmort.h>
docobj.h>
dplay.h>
dplobby.h>
dshow.h>
dsound.h>
guiddef.h>
imagehlp.h>
imm.h>
initguid.h>
instance.h>
lmcons.h>
lzexpand.h>
mapi.h>
mapicode.h>
mapidefs.h>
mciavi.h>
mcx.h>
mediaerr.h>
mediaobj.h>
minmax.h>
mmreg.h>
mmsystem.h>
msacm.h>
msacmdlg.h>
msvcrt/conio.h>
msvcrt/crtdbg.h>
msvcrt/ctype.h>
msvcrt/direct.h>
msvcrt/dos.h>
msvcrt/eh.h>
msvcrt/excpt.h>
msvcrt/fcntl.h>
msvcrt/io.h>
msvcrt/locale.h>
msvcrt/malloc.h>
msvcrt/mbctype.h>
msvcrt/mbstring.h>
msvcrt/process.h>
msvcrt/search.h>
msvcrt/setjmp.h>
msvcrt/share.h>
msvcrt/stddef.h>
msvcrt/stdio.h>
msvcrt/stdlib.h>
msvcrt/string.h>
msvcrt/sys/locking.h>
msvcrt/sys/stat.h>
msvcrt/sys/timeb.h>
msvcrt/sys/types.h>
msvcrt/sys/utime.h>
msvcrt/time.h>
msvcrt/wchar.h>
msvcrt/wctype.h>
mswsock.h>
nb30.h>
nspapi.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>
rpcdce.h>
rpcdcep.h>
rpcndr.h>
rpcnterr.h>
rpcproxy.h>
servprov.h>
setupapi.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>
uuids.h>
ver.h>
vfw.h>
vfwmsgs.h>
winbase.h>
wincon.h>
wincrypt.h>
windef.h>
windows.h>
windowsx.h>
wine/debug.h>
wine/exception.h>
wine/icmpapi.h>
wine/ipexport.h>
wine/library.h>
wine/obj_base.h>
wine/obj_cache.h>
wine/obj_channel.h>
wine/obj_clientserver.h>
wine/obj_comcat.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_enumguid.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_serviceprovider.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/obj_webbrowser.h>
wine/unicode.h>
winerror.h>
wingdi.h>
wininet.h>
winioctl.h>
winnetwk.h>
winnls.h>
winnt.h>
winreg.h>
winres.h>
winresrc.h>
winsock.h>
winsock2.h>
winspool.h>
winsvc.h>
winuser.h>
winver.h>
wnaspi32.h>
wownt32.h>
ws2spi.h>
ws2tcpip.h>
wshisotp.h>
wsipx.h>
wtypes.h>
zmouse.h>
libwine_uuid.a>
Documentation files.This list may NOT be current!HOWTO-winelib.gz>
wine-devel-20020710/wine-devel>
wine-devel/accel-impl.html>
wine-devel/arch-dlls.html>
wine-devel/architecture.html>
wine-devel/build.html>
wine-devel/com-writing.html>
wine-devel/compiling.html>
wine-devel/consoles.html>
wine-devel/cvs-regression.html>
wine-devel/dbg-channels.html>
wine-devel/dbg-checking.html>
wine-devel/dbg-commands.html>
wine-devel/dbg-compiling.html>
wine-devel/dbg-config.html>
wine-devel/dbg-in-memory.html>
wine-devel/dbg-limits.html>
wine-devel/dbg-modes.html>
wine-devel/dbg-notes.html>
wine-devel/dbg-others.html>
wine-devel/dbg-param.html>
wine-devel/dbg-resource-ids.html>
wine-devel/dbg-using.html>
wine-devel/debugger.html>
wine-devel/debugging.html>
wine-devel/dlls.html>
wine-devel/documentation.html>
wine-devel/file-handles.html>
wine-devel/hardware-trace.html>
wine-devel/i18n.html>
wine-devel/implementation.html>
wine-devel/index.html>
wine-devel/memory-addresses.html>
wine-devel/module-overview.html>
wine-devel/ole-binary.html>
wine-devel/ole.html>
wine-devel/opengl-configure.html>
wine-devel/opengl-problems.html>
wine-devel/opengl-works.html>
wine-devel/opengl.html>
wine-devel/os2-wine.html>
wine-devel/part-one.html>
wine-devel/part-three.html>
wine-devel/part-two.html>
wine-devel/patch-quality.html>
wine-devel/patches.html>
wine-devel/porting.html>
wine-devel/tools.html>
wine-devel/wine-debugger.html>
wine-devel/wine-docbook.html>
winelib-user/bindlls-building.html>
winelib-user/bindlls-cxx-apis.html>
winelib-user/bindlls-spec.html>
winelib-user/bindlls-wrapper.html>
winelib-user/bindlls.html>
winelib-user/c-library.html>
winelib-user/com-support.html>
winelib-user/index.html>
winelib-user/init-problems.html>
winelib-user/linking.html>
winelib-user/mfc-compiling.html>
winelib-user/mfc-legal-issues.html>
winelib-user/mfc-using.html>
winelib-user/mfc.html>
winelib-user/others.html>
winelib-user/packaging.html>
winelib-user/portability-issues.html>
winelib-user/porting-compiling.html>
winelib-user/seh.html>
winelib-user/spec-file.html>
winelib-user/unicode.html>
winelib-user/winelib-getting-started.html>
winelib-user/winelib-introduction.html>
winelib-user/winelib-requirements.html>
winelib-user/winelib-toolkit.html>
winelib-user/wmc.html>
winelib-user/wrc.html>
Dynamic Wine Files
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.
Configuration File/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.
Global wine configuration is currently not possible;
this might get reenabled at some time.
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.
Other files in /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.
cachedmetrics can be generated if absent.You should note this can be long.
Important Files from a Windows Partition
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.
Registry Files[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.
Packaging Strategies
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.
Distribution of Wine into packages
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.
Where to install files
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
$PREFIX/bin,
all library files go into
$PREFIX/lib/wine,
all include files go into
$PREFIX/include/wine,
all documentation files go into
$PREFIX/share/doc/wine-VERSION,
and man pages go into
$PREFIX/share/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 question of /opt/wine
The FHS 2.2 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).
What files to create
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.
What to put into the wine config file
This is the sample config file provided with wine 20030115. You can edit this file
to best suit the needs of your intended user.
WINE REGISTRY Version 2
;; All keys relative to \\Machine\\Software\\Wine\\Wine\\Config
;; If you think it is necessary to show others your complete config for a
;; bug report, filter out empty lines and comments with
;; grep -v "^;" ~/.wine/config | grep '.'
;;
;; 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)
;;
[Drive A]
"Path" = "/mnt/fd0"
"Type" = "floppy"
"Label" = "Floppy"
"Filesystem" = "win95"
"Serial" = "87654321"
"Device" = "/dev/fd0"
[Drive C]
"Path" = "/c"
"Type" = "hd"
"Label" = "MS-DOS"
"Filesystem" = "win95"
[Drive D]
"Path" = "/cdrom"
"Type" = "cdrom"
"Label" = "CD-Rom"
"Filesystem" = "win95"
; make sure that device is correct and has proper permissions !
"Device" = "/dev/cdrom"
[Drive E]
"Path" = "/tmp"
"Type" = "hd"
"Label" = "Tmp Drive"
"Filesystem" = "win95"
[Drive F]
"Path" = "${HOME}"
"Type" = "network"
"Label" = "Home"
"Filesystem" = "win95"
[wine]
"Windows" = "c:\\windows"
"System" = "c:\\windows\\system"
"Temp" = "e:\\"
"Path" = "c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\"
"Profile" = "c:\\windows\\Profiles\\Administrator"
"GraphicsDriver" = "x11drv"
;"ShowDirSymlinks" = "1"
;"ShowDotFiles" = "1"
"ShellLinker" = "wineshelllink"
# <wineconf>
[Version]
; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31)
;"Windows" = "win98"
; DOS version to imitate
;"DOS" = "6.22"
; Be careful here, wrong DllOverrides settings have the potential
; to pretty much kill your setup.
[DllOverrides]
; some dlls you may want to change
"oleaut32" = "builtin, native"
"ole32" = "builtin, native"
"commdlg" = "builtin, native"
"comdlg32" = "builtin, native"
"shell" = "builtin, native"
"shell32" = "builtin, native"
"shfolder" = "builtin, native"
"shlwapi" = "builtin, native"
"shdocvw" = "builtin, native"
"advapi32" = "builtin, native"
"msvcrt" = "native, builtin"
"mciavi.drv" = "native, builtin"
"mcianim.drv" = "native, builtin"
; you can specify applications too
; this one will apply for all notepad.exe
;"*notepad.exe" = "native, builtin"
; this one will apply only for a particular file
;"C:\\windows\\regedit.exe" = "native, builtin"
; default for all other dlls
"*" = "builtin, native"
[x11drv]
; Number of colors to allocate from the system palette
"AllocSystemColors" = "100"
; Use a private color map
"PrivateColorMap" = "N"
; Favor correctness over speed in some graphics operations
"PerfectGraphics" = "N"
; Color depth to use on multi-depth screens
;;"ScreenDepth" = "16"
; Name of X11 display to use
;;"Display" = ":0.0"
; Allow the window manager to manage created windows
"Managed" = "Y"
; Use a desktop window of 640x480 for Wine
;"Desktop" = "640x480"
; Use XFree86 DGA extension if present
; (make sure /dev/mem is accessible by you !)
"UseDGA" = "Y"
; Use XShm extension if present
"UseXShm" = "Y"
; Use XVidMode extension if present
"UseXVidMode" = "Y"
; Use the take focus protocol
"UseTakeFocus" = "Y"
; Enable DirectX mouse grab
"DXGrab" = "N"
; Create the desktop window with a double-buffered visual
; (useful to play OpenGL games)
"DesktopDoubleBuffered" = "N"
; Code page used for captions in managed mode
; 0 means default ANSI code page (CP_ACP == 0)
"TextCP" = "0"
; Use this if you have more than one port for video on your setup
; (Wine uses for now the first 'input image' it finds).
;; "XVideoPort" = "43"
; Run in synchronous mode (useful for debugging X11 problems)
;;"Synchronous" = "Y"
;
; Use the Render extension to render client side fonts (default "Y")
;;"ClientSideWithRender" = "Y"
; Fallback on X core requests to render client side fonts (default "Y")
;;"ClientSideWithCore" = "Y"
; Set both of the previous two to "N" in order to force X11 server side fonts
;
; Anti-alias fonts if using the Render extension (default "Y")
;;"ClientSideAntiAliasWithRender" = "Y"
; Anti-alias fonts if using core requests fallback (default "Y")
;;"ClientSideAntiAliasWithCore" = "Y"
;
[fonts]
;Read the Fonts topic in the Wine User Guide before adding aliases
;See a couple of examples for russian users below
"Resolution" = "96"
"Default" = "-adobe-helvetica-"
"DefaultFixed" = "fixed"
"DefaultSerif" = "-adobe-times-"
"DefaultSansSerif" = "-adobe-helvetica-"
;; default TrueType fonts with russian koi8-r encoding
;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r"
;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r"
;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r"
;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r"
;; default cyrillic bitmap X fonts
;"Default" = "-cronyx-helvetica-"
;"DefaultFixed" = "fixed"
;"DefaultSerif" = "-cronyx-times-"
;"DefaultSansSerif" = "-cronyx-helvetica-"
; the TrueType font dirs you want to make accessible to wine
[FontDirs]
;"dir1" = "/usr/X11R6/lib/X11/fonts/TrueType"
;"dir2" = "/usr/share/fonts/truetype"
;"dir3" = "/usr/X11R6/lib/X11/fonts/TT"
;"dir4" = "/usr/share/fonts/TT"
[serialports]
"Com1" = "/dev/ttyS0"
"Com2" = "/dev/ttyS1"
"Com3" = "/dev/ttyS2"
"Com4" = "/dev/modem"
[parallelports]
"Lpt1" = "/dev/lp0"
[ppdev]
;; key: io-base of the emulated port
;; value : parport-device{,timeout}
;; timeout for auto closing an open device ( not yet implemented)
;"378" = "/dev/parport0"
;"278" = "/dev/parport1"
;"3bc" = "/dev/parport2"
[spooler]
"FILE:" = "tmp.ps"
"LPT1:" = "|lpr"
"LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -"
"LPT3:" = "/dev/lp3"
[ports]
;"read" = "0x779,0x379,0x280-0x2a0"
;"write" = "0x779,0x379,0x280-0x2a0"
[Debug]
;"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection"
;"RelayInclude" = "user32.CreateWindowA"
;"SnoopExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection"
;"SpyExclude" = "WM_SIZE;WM_TIMER;"
[registry]
;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false.
;Defaults are read all, write to Home
; Where to find the global registries
;"GlobalRegistryDir" = "/etc";
; Global registries (stored in /etc)
"LoadGlobalRegistryFiles" = "Y"
; Home registries (stored in ~user/.wine/)
"LoadHomeRegistryFiles" = "Y"
; Load Windows registries from the Windows directory
"LoadWindowsRegistryFiles" = "Y"
; TRY to write all changes to home registries
"WritetoHomeRegistryFiles" = "Y"
; Registry periodic save timeout in seconds
; "PeriodicSave" = "600"
; Save only modified keys
"SaveOnlyUpdatedKeys" = "Y"
[Tweak.Layout]
;; supported styles are 'Win31'(default), 'Win95', 'Win98'
;; this has *nothing* to do with the windows version Wine returns:
;; set the "Windows" value in the [Version] section if you want that.
"WineLook" = "Win95"
[Console]
;"Drivers" = "tty"
;"XtermProg" = "nxterm"
;"InitialRows" = "25"
;"InitialColumns" = "80"
;"TerminalType" = "nxterm"
[Clipboard]
"ClearAllSelections" = "0"
"PersistentSelection" = "1"
; List of all directories directly contain .AFM files
[afmdirs]
"1" = "/usr/share/ghostscript/fonts"
"2" = "/usr/share/a2ps/afm"
"3" = "/usr/share/enscript"
"4" = "/usr/X11R6/lib/X11/fonts/Type1"
[WinMM]
#"Drivers" = "winearts.drv"
#"Drivers" = "winejack.drv"
"Drivers" = "wineoss.drv"
"WaveMapper" = "msacm.drv"
"MidiMapper" = "midimap.drv"
[dsound]
;; HEL only: Number of waveOut fragments ahead to mix in new buffers.
;"HELmargin" = "5"
;; HEL only: Number of waveOut fragments ahead to queue to driver.
;"HELqueue" = "5"
;; Max number of fragments to prebuffer
;"SndQueueMax" = "28"
;; Min number of fragments to prebuffer
;"SndQueueMin" = "12"
[Network]
;; Use the DNS (Unix) host name always as NetBIOS "ComputerName" (boolean, default "Y").
;; Set to N if you need a persistent NetBIOS ComputerName that possibly differs
;; from the Unix host name. You'll need to set ComputerName in
;; HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName, too.
;"UseDnsComputerName" = "N"
;; sample AppDefaults entries
; 3 InstallShield versions who like to put their full screen window in front,
; without any chance to switch to another X11 application.
; So just catch them in a desktop window.
[AppDefaults\\_INS5576._MP\\x11drv]
"Desktop" = "640x480"
[AppDefaults\\_INS5176._MP\\x11drv]
"Desktop" = "640x480"
[AppDefaults\\_INS0466._MP\\x11drv]
"Desktop" = "640x480"
;[AppDefaults\\iexplore.exe\\DllOverrides]
;"shlwapi" = "native"
;"rpcrt4" = "native"
;"ole32" = "native"
;"shdocvw" = "native"
;"wininet" = "native"
;"shfolder" = "native"
;"shell32" = "native"
;"shell" = "native"
;"comctl32" = "native"
;
;[AppDefaults\\setup.exe\\x11drv]
;"Desktop" = "800x600"
;
;[AppDefaults\\sol.exe\\Version]
;"Windows" = "nt40"
;
;; Some games (Quake 2, UT) refuse to accept emulated dsound devices.
;; You can add an AppDefault entry like this for such cases.
;[AppDefaults\\pickygame.exe\\dsound]
;"EmulDriver" = "N"
# </wineconf>
ImplementationRedHat 8.0 SampleBuilding 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.2,
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 dlls/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 ./regedit once for
one example user and then reusing his
/user.reg and
/system.reg files.
FIXMEthis 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.
FIXMEpossibly 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
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 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).
FIXMENot 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).
Sample RedHat 8.0 .spec file for review purposes
%define DATE 20030115
Summary: A Windows 16/32 bit emulator.
Name: wine
Version: %{DATE}
Release: 1rh8winehq
Group: Applications/Emulators
License: LGPL
URL: http://www.winehq.com/
Source: ftp://metalab.unc.edu/pub/Linux/ALPHA/wine/development/Wine-%{version}.tar.bz2
Source1: wine.init
Patch: wine-%{version}-initial.patch
Patch1: wine-%{version}-kde2.patch
Patch2: wine-%{version}-winelauncher.patch
Patch3: wine-%{version}-defaultcfg.patch
Patch4: wine-%{version}-stabs+.patch
Buildroot: %{_tmppath}/%{name}-root
ExclusiveArch: %{ix86}
Prereq: shadow-utils
Conflicts: kdebase < 2.0
Requires: cups-libs >= 1.1.12
BuildRequires: docbook-utils, cups-devel >= 1.1.12, autoconf253, perl
%description
While Wine is usually thought of as a Windows(TM) emulator, the Wine
developers would prefer that users thought of Wine as a Windows
compatibility layer for UNIX. This package includes a program loader,
which allows unmodified Windows 3.1/95/NT binaries to run under Intel
Unixes. Wine does not require MS Windows, but it can use native system
.dll files if they are available.
%package devel
Summary: Wine development environment.
Group: System Environment/Libraries
Requires: wine = %{version}
%description devel
Header and include files for developing applications with the Wine
Windows(TM) emulation libraries.
%prep
%setup -q -n wine-%{version}
find . -type d -name CVS |xargs rm -rf
%patch -p1 -b .initial
%patch1 -p1 -b .kde2
%patch2 -p1 -b .wl
%patch3 -p1 -b .defcfg
%patch4 -p1 -b .stabs+
%build
export CFLAGS="$RPM_OPT_FLAGS"
autoconf || autoconf-2.53
%configure \
--with-x \
--libdir=%{_libdir}/wine \
--includedir=%{_includedir}/wine \
--sysconfdir=%{_sysconfdir}/wine
make depend
make
make -C documentation doc
%install
rm -rf $RPM_BUILD_ROOT
%makeinstall \
includedir=%{?buildroot:%{buildroot}}%{_includedir}/wine \
libdir=%{?buildroot:%{buildroot}}%{_libdir}/wine \
sysconfdir=%{?buildroot:%{buildroot}}%{_sysconfdir}/wine \
dlldir=%{?buildroot:%{buildroot}}%{_libdir}/wine/wine \
LDCONFIG=/bin/true
for i in system "Start Menu/Programs/Startup" Profiles/Administrator Fonts \
Desktop Favorites NetHood Recent SendTo ShellNew; do
mkdir -p "$RPM_BUILD_ROOT%{_datadir}/wine-c/windows/$i"
done
mkdir -p "$RPM_BUILD_ROOT%{_datadir}/wine-c/My Documents"
mkdir -p "$RPM_BUILD_ROOT%{_datadir}/wine-c/Program Files/Common Files"
# Take care of wine and windows configuration files...
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/wine
mv documentation/samples/config documentation/samples/config.orig
sed "s/\"GraphicsDriver\" = .*/\"GraphicsDriver\" = \"ttydrv\"/" documentation/samples/config.orig |\
sed "s|\"Path\" = \"/c\"\$|\"Path\" = \"$RPM_BUILD_ROOT%{_datadir}/wine-c\"|" |\
sed "s|\"Path\" = \"\${HOME}\"$|\"Path\" = \"%{_builddir}/%{buildsubdir}\"|" -> documentation/samples/config
WINEPREFIX=%{_builddir}/%{buildsubdir}/documentation/samples programs/regedit/regedit winedefault.reg > /dev/null
# Wait until wineserver finishes and closes those files
sleep 5
install -c -m 0644 documentation/samples/system.reg $RPM_BUILD_ROOT%{_sysconfdir}/wine/system.reg
install -c -m 0644 documentation/samples/user.reg $RPM_BUILD_ROOT%{_sysconfdir}/wine/user.reg
install -c -m 0644 documentation/samples/userdef.reg $RPM_BUILD_ROOT%{_sysconfdir}/wine/userdef.reg
rm -f documentation/samples/system.reg
rm -f documentation/samples/user.reg
rm -f documentation/samples/userdef.reg
sed "s|\"Path\" = \"/c\"\$|\"Path\" = \"%{_datadir}/wine-c\"|" documentation/samples/config.orig > documentation/samples/config.rh
install -c -m 0644 documentation/samples/config.rh $RPM_BUILD_ROOT%{_sysconfdir}/wine/wine.conf
rm -f documentation/samples/config
rm -f documentation/samples/config.rh
mv documentation/samples/config.orig documentation/samples/config
# Install link to windows applications replacements
ln -sf %{_libdir}/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/notepad.exe
ln -sf %{_libdir}/wine/regedit.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/regedit.exe
ln -sf %{_libdir}/wine/rundll32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/rundll32.exe
ln -sf %{_libdir}/wine/wcmd.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/cmd.exe
ln -sf %{_libdir}/wine/control.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/control.exe
ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/help.exe
ln -sf %{_libdir}/wine/notepad.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/notepad.exe
ln -sf %{_libdir}/wine/progman.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/progman.exe
ln -sf %{_libdir}/wine/regsvr32.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/regsvr32.exe
ln -sf %{_libdir}/wine/winemine.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winmine.exe
ln -sf %{_libdir}/wine/winver.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/winver.exe
ln -sf %{_libdir}/wine/uninstaller.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/uninstaller.exe
ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhelp.exe
ln -sf %{_libdir}/wine/winhelp.exe.so $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/winhlp32.exe
for i in shell.dll shell32.dll winsock.dll wnsock32.dll; do
touch $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system/$i
done
touch $RPM_BUILD_ROOT%{_datadir}/wine-c/autoexec.bat
touch $RPM_BUILD_ROOT%{_datadir}/wine-c/config.sys
touch $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/win.ini
install -c -m 0644 documentation/samples/system.ini $RPM_BUILD_ROOT%{_datadir}/wine-c/windows/system.ini
cat >RedHat <<EOF
Wine directory structure used in Red Hat Linux:
===============================================
%{_datadir}/wine-c is the root directory (aka C: drive) wine looks for
by default. It contains (empty) C:\windows and C:\windows\system
directories, needed to operate Wine without an existing Windows installation.
If you want to use Wine with an existing Windows installation that is mounted,
for example, in /mnt/windows-c, edit /etc/wine.conf to say
[Drive C]
Path=/mnt/windows-c
Type=hd
Label=Whatever
Filesystem=win95
instead of the defaults set by installation.
If you do this, you can safely remove %{_datadir}/wine-c.
(Alternatively, just mount your Windows partition to %{_datadir}/wine-c.)
EOF
# Allow users to launch Windows programs by just clicking on the .exe file...
mkdir -p $RPM_BUILD_ROOT%{_initrddir}
install -c -m 755 %SOURCE1 $RPM_BUILD_ROOT%{_initrddir}/wine
%clean
rm -rf $RPM_BUILD_ROOT
%pre
/usr/sbin/groupadd -g 66 -r wine &>/dev/null || :
%post
if ! grep -q "^/usr/lib/wine$" /etc/ld.so.conf; then
echo "/usr/lib/wine" >>/etc/ld.so.conf
fi
/sbin/ldconfig
/sbin/chkconfig --add wine
/sbin/chkconfig --level 2345 wine on
/sbin/service wine start &>/dev/null || :
%preun
if test "$1" = "0"; then
/sbin/chkconfig --del wine
fi
%postun
if test "$1" = "0"; then
perl -pi -e "s,^/usr/lib/wine$,,g" /etc/ld.so.conf
/usr/sbin/groupdel wine &>/dev/null || :
fi
/sbin/ldconfig
%files
%defattr(-,root,root)
%attr(0775, root, wine) %dir %{_datadir}/wine-c
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/system
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/windows/Start Menu"
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/windows/Start Menu/Programs"
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/windows/Start Menu/Programs/Startup"
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Profiles
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Profiles/Administrator
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Fonts
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Desktop
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Favorites
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/NetHood
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/Recent
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/SendTo
%attr(0775, root, wine) %dir %{_datadir}/wine-c/windows/ShellNew
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/My Documents"
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/Program Files"
%attr(0775, root, wine) %dir "%{_datadir}/wine-c/Program Files/Common Files"
%{_libdir}/wine
%{_bindir}/*
%{_mandir}/man?/*
%{_datadir}/wine-c/windows/system/*.dll
%{_datadir}/wine-c/windows/*.exe
%config %{_datadir}/wine-c/autoexec.bat
%config %{_datadir}/wine-c/config.sys
%attr(0664, root, wine) %config %{_datadir}/wine-c/windows/win.ini
%attr(0664, root, wine) %config %{_datadir}/wine-c/windows/system.ini
%config %{_sysconfdir}/wine/*
%config %{_initrddir}/*
%doc ANNOUNCE BUGS COPYING.LIB ChangeLog DEVELOPERS-HINTS LICENSE LICENSE.OLD README VERSION
%doc AUTHORS RedHat
%doc documentation/ChangeLog.OLD documentation/HOWTO-winelib documentation/README.fr
%doc documentation/wine-devel documentation/wine-user documentation/winelib-user documentation/samples
%files devel
%defattr(-,root,root)
%{_includedir}/*
Work to be done
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.