Removed "elfdll" load order option and updated documentation.
diff --git a/documentation/wine.conf.man.in b/documentation/wine.conf.man.in
index 456e761..fbdfb26 100644
--- a/documentation/wine.conf.man.in
+++ b/documentation/wine.conf.man.in
@@ -150,47 +150,43 @@
.I format: EXTRA_LD_LIBRARY_PATH=@prefix@/lib/wine[:/more/path/to/search[:...]]
.br
The path will be appended to any existing LD_LIBRARY_PATH from the
-environment for the search of elfdlls and .so libraries.
+environment for the search of .so libraries.
.PP
-.I format: DefaultLoadOrder=native,elfdll,so,builtin
+.I format: DefaultLoadOrder=native,so,builtin
.br
A comma separated list of module-types to try to load in that specific
order. The DefaultLoadOrder key is used as a fallback when a module is
not specified explicitely. If the DefaultLoadOrder key is not found,
-then the order "native,elfdll,so,builtin" is used.
+then the order "native,builtin,so" is used.
.br
-Case is not (yet) important and only the first letter of each type is enough
-to identify the type n[ative], e[lfdll], s[o], b[uiltin]. Also whitespace is
-ignored. Keep everything in lower case to be sure that your entries keep the
-same meaning. See also commandline option
+Case is not (yet) important and only the first letter of each type is
+enough to identify the type n[ative], s[o], b[uiltin]. Also whitespace
+is ignored. Keep everything in lower case to be sure that your entries
+keep the same meaning. See also commandline option
.I --dll
for details about the allowable types.
.PP
.B [DllOverrides]
.br
-There are no explicit keys defined other than module/library names. A comma
-separated list of modules is followed by an assignment of the load order
-for these specific modules. See above for possible types. You should not
-specify an extension.
+There are no explicit keys defined other than module/library names. A
+module namd is followed by an assignment of the load order for this
+specific module. See above for possible types. You should not specify
+an extension.
.br
Examples:
.br
-.I kernel32, gdi32, user32 = builtin
+.I kernel32 = builtin
.br
-.I kernel, gdi, user = builtin
+.I kernel = builtin
.br
-.I comdlg32 = elfdll, native, builtin
+.I comdlg32 = native, builtin
.br
.I commdlg = native, builtin
.br
-.I version, ver = elfdll, native, builtin
-.br
Changing the load order of kernel/kernel32 and gdi/gdi32 to
anything other than builtin will cause wine to fail because wine cannot
use native versions for these libraries (gdi[32] might work native someday,
-but kernel[32] will never work native). These libraries are also the last
-to be converted to elfdlls and will live as builtins for quite some time
-to come.
+but kernel[32] will never work native).
Note that using the native versions of user[32] isn't recommended right now,
as these modules face nearly the same problems as kernel/gdi and we only
just managed to make them work partially. But trying to use it might get
@@ -200,30 +196,6 @@
fiddling with the current defaults and needless to say that you must know
what you are doing.
.PP
-.B [DllPairs]
-.br
-This is a simple pairing in the form 'name1 = name2'. It is supposed to
-identify the dlls that cannot live without eachother unless they are
-loaded in the same format. Examples are common dialogs and controls,
-shell, kernel, gdi, user, etc...
-.br
-The code will issue a warning if the loadorder of these pairs are different
-and might cause hard-to-find bugs due to incompatible pairs loaded at
-run-time. Note that this pairing gives
-.B no
-guarantee that the pairs
-actually get loaded as the same type, nor that the correct versions are
-loaded (might be implemented later). It merely notes obvious trouble.
-.br
-Examples:
-.br
-.I kernel = kernel32
-.br
-.I commdlg = comdlg32
-.br
-The implementation will probably change in a later stage to force pairs to
-be loaded correctly, but there are also drawbacks with such an approach.
-.PP
.B [serialports]
.br
.I format: com[12345678] = <devicename>
diff --git a/documentation/wine.man.in b/documentation/wine.man.in
index 2265d7f..505e4fa 100644
--- a/documentation/wine.man.in
+++ b/documentation/wine.man.in
@@ -180,14 +180,12 @@
.I --display name
Use the specified X display
.TP
-.I --dll name[,name[,...]]={native|elfdll|so|builtin}[,{n|e|s|b}[,...]][+...]
+.I --dll name[,name[,...]]={native|so|builtin}[,{n|s|b}[,...]][+...]
Selects the override type and load order of dll used in the loading process
for any dll. The default is set in @sysconfdir@/wine.conf or ~/.winerc. There
-are currently four types of libraries that can be loaded into a process' address
+are currently three types of libraries that can be loaded into a process' address
space: Native windows dlls (
.I native
-), ELF encapsulated windows dlls (
-.I elfdll
), native ELF libraries (
.I so
)and
@@ -195,7 +193,7 @@
internal dlls (
.I builtin
). The type may be abbreviated with the first letter of the type (
-.I n, e, s, b
+.I n, s, b
). Each sequence of orders must be separated by commas.
.br
Each dll may have its own specific load order. The load order determines
@@ -218,10 +216,10 @@
Try to load the libraries shell and shell32 as native windows dlls. Furthermore, if
an application request to load c:\(rsfoo\(rsbar\(rsbaz.dll load the builtin library baz.
.br
-.I --dll comdlg32,commdlg=e,n:shell,shell32=b+comctl32,commctrl=n
+.I --dll comdlg32,commdlg=b,n:shell,shell32=b+comctl32,commctrl=n
.br
-Try to load comdlg32 and commdlg as elfdll first and try the native version
-if the elfdll load fails; load shell32/shell always as builtin and
+Try to load comdlg32 and commdlg as builtin first and try the native version
+if the builtin load fails; load shell32/shell always as builtin and
comctl32/commctrl always as native.
.br
Note: It is wise to keep dll pairs (comdlg32/commdlg, shell/shell32, etc.)
@@ -311,7 +309,7 @@
.I WINEPREFIX
If set, the content of this variable is taken as the name of the directory where
.B wine
-stores its data (usually
+stores its data (the default is
.I $HOME/.wine
). This directory contains also the socket, which is used to communicate with the
.I wineserver.
@@ -327,6 +325,27 @@
processes, it is possible to run a number of truly independent
.B wine
processes.
+.TP
+.I WINESERVER
+Specifies the path and name of the
+.B wineserver
+binary. If not set, a file named "wineserver" is searched in the
+path and in a few other likely locations.
+.TP
+.I WINELOADER
+Specifies the path and name of the
+.B wine
+binary to use to launch new Windows processes. If not set, a binary
+named "wine" is searched in the path and in a few other likely
+locations.
+.TP
+.I WINEDLLPATH
+Specifies the path(s) in which to search for builtin dll files. This
+is a list of directories separated by ":". Builtin dlls are also
+searched in the directories specified by the standard
+.I LD_LIBRARY_PATH
+if they are not found in the directories listed in
+.I WINEDLLPATH.
.SH CONFIGURATION FILE
.B wine
@@ -350,6 +369,12 @@
of the authors, please see the file
.B AUTHORS
in the top-level directory of the source distribution.
+.SH COPYRIGHT
+.B wine
+can be distributed under the terms of the X11 license. A copy of the
+license is in the file
+.B LICENSE
+in the top-level directory of the source distribution.
.SH BUGS
.PP
A status report on many applications is available from
@@ -415,6 +440,11 @@
.B wine
server
.TP
+.I @prefix@/bin/winedbg
+The
+.B wine
+debugger
+.TP
.I @prefix@/bin/wineclpsrv
The
.B wine
@@ -435,10 +465,6 @@
.I ~/.wine
Directory containing user specific data managed by
.B wine.
-.TP
-.I @prefix@/lib/wine.sym
-Global symbol table (used in debugger)
-.SH "SEE ALSO"
-.BR wine.conf (5),
-.BR clone (2)
+.SH "SEE ALSO"
+.BR wine.conf (5)
