From 25947201953d17f213e4fa7990694db690d05038 Mon Sep 17 00:00:00 2001 From: Bertho Stultiens Date: Sun, 18 Apr 1999 12:11:29 +0000 Subject: [PATCH] Updated commandline changes of -dll option and wine.conf entries. --- documentation/wine.man | 127 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 113 insertions(+), 14 deletions(-) diff --git a/documentation/wine.man b/documentation/wine.man index 7c3a57a314f..e5af0f888c5 100644 --- a/documentation/wine.man +++ b/documentation/wine.man @@ -160,20 +160,44 @@ Use a desktop window of the given geometry .I -display name Use the specified display .TP -.I -dll name -Enables/disables built-in DLL's - starting wine with -.I -dll -commdlg -is probably a good idea. -The full list of DLLs modifiable by this is: -ADVAPI32, AVIFILE, COMCTL32, COMDLG32, COMM, COMMDLG, COMPOBJ, CRTDLL, -DCIMAN32, DDEML, DDRAW, DINPUT, DISPLAY, DPLAY, DPLAYX, DSOUND, GDI, GDI32, -IMAGEHLP, IMM32, KEYBOARD, LZ32, LZEXPAND, MMSYSTEM, MOUSE, MPR, MSACM, -MSACM32, MSNET32, MSVFW32, MSVIDEO, OLE2, OLE32, OLE2CONV, OLE2DISP, OLE2NLS, -OLE2PROX, OLE2THK, OLEAUT32, OLECLI, OLECLI32, OLEDLG, OLESVR, OLESVR32, -PSAPI, RASAPI16, RASAPI32, SHELL, SHELL32, SOUND, STORAGE, STRESS, SYSTEM, -TAPI32, TOOLHELP, TYPELIB, USER, USER32, VER, VERSION, W32SKRNL, W32SYS, -WIN32S16, WIN87EM, WINASPI, WINDEBUG, WINEPS, WINMM, WING, WINSOCK, WINSPOOL, -WNASPI32, WOW32, WPROCS, WSOCK32 +.I -dll name[,name[,...]]={native|elfdll|so|builtin}[,{n|e|s|b}[,...]][:...] +Selects the override type and load order of dll used in the loading process +for any dll. The default is set in wine.conf or ~/.winerc. There are +currently four 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 wine internal dlls ( +.I builtin +). The type may be abbreviated with the first letter of the type ( +.I n, e, s, b +). Each sequence of orders must be seperated by commas. +.br +Each dll may have its own specific load order. The load order determines +which verion of the dll is attempted to be loaded into the address space. If +the first fails, then the next is tried and so on. Different load orders can +be specified by seperating the entries with a colon. Multiple libraries +with the same load order can be separated with commas. +.br +Examples: +.br +.I -dll comdlg32,commdlg=n,b +.br +Try to load comdlg32 and commdlg as native windows dll first and try +the builtin version if the native load fails. +.br +.I -dll comdlg32,commdlg=e,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 +comctl32/commctrl always as native. +.br +Note: It is wise to keep dll pairs (comdlg32/commdlg, shell/shell32, etc.) +having exactly the same load order. This will prevent mismatches at runtime. +See also configuration file format below. .TP .I -failreadonly Read only files may not be opened in write mode (the default is to @@ -362,6 +386,81 @@ default: wine.sym Used to specify the path and file name of the symbol table used by the built-in debugger. .PP +.B [DllDefaults] +.br +.I format: EXTRA_LD_LIBRARY_PATH=/usr/local/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. +.PP +.I format: DefaultLoadOrder=native,elfdll,so,builtin +.br +A comma seperated 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. +.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 +.I -dll +for details about the alowable 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. +.br +Examples: +.br +.I kernel32, gdi32, user32 = builtin +.br +.I kernel, gdi, user = builtin +.br +.I comdlg32 = elfdll, native, builtin +.br +.I commdlg = native, builtin +.br +.I version, ver = elfdll, native, builtin +.br +Changing the load order of kernel/kernel32, gdi/gdi32 and user/user32 to +anything other than builtin will cause wine to fail because wine cannot +use native versions for these libraries (user[32] and 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. +.br +Always make sure that you have some kind of strategy in mind when you start +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] =