Hi all, maybe that one will finally (attempt #ohdamniforgot) see the light... - add documentation section to README - updated HOWTO-winelib - added native DLL config info to configuring.sgml - greatly improve directory description of wine.conf man page - add --debugmsg +all warning to wine man page -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
Determining best CVS host... Using CVSROOT :pserver:cvs@rhlx01.fht-esslingen.de:/home/wine Index: README =================================================================== RCS file: /home/wine/wine/README,v retrieving revision 1.30 diff -u -r1.30 README --- README 4 Jan 2002 18:53:55 -0000 1.30 +++ README 1 Feb 2002 15:42:19 -0000 @@ -21,8 +21,9 @@ Run programs as "wine [options] program". For more information and problem resolution, read the rest of this file, the Wine man page, -the files in the documentation directory in the Wine source, and -especially the wealth of information found at http://www.winehq.com. +the files in the documentation directory in the Wine source +(see "DOCUMENTATION"), and especially the wealth of information +found at http://www.winehq.com. 3. REQUIREMENTS @@ -87,8 +88,8 @@ Bison will work as a replacement for yacc. If you are using RedHat or Debian, install the flex and bison packages. -In case you want to build the documentation yourself, you'll also -need the DocBook tools (db2html, db2ps, db2pdf). +For requirements in case you intend to build the documentation yourself, +see "DOCUMENTATION" section. 4. COMPILATION @@ -116,7 +117,6 @@ Wine-yymmdd.diff.gz). You can then re-run "./configure", and then run "make depend && make". - 5. SETUP Once Wine has been built correctly, you can do "make install"; this @@ -127,8 +127,8 @@ first. Try either "dpkg -r wine" or "rpm -e wine" or "make uninstall" before installing. -If you want to build the documentation, you can run "make" in the -documentation directory. +If you want to read the documentation supplied with the Wine source, +then see the "DOCUMENTATION" section. Wine requires a configuration file named named "config" in your ~/.wine directory. The format of this file is explained in the config file @@ -164,7 +164,7 @@ Note: the path of the file will also be added to the path when a full name is supplied on the commandline. -Wine is not yet complete, so some programs may crash. Provided you set up +Wine is not yet complete, so several programs may crash. Provided you set up winedbg correctly according to documentation/debugger.sgml, you will be dropped into a debugger so that you can investigate and fix the problem. For more information on how to do this, please read the file documentation/debugging. @@ -180,16 +180,27 @@ can at least partially be fixed by using http://home.nexgo.de/andi.mohr/download/decorrupt_explorer +7. DOCUMENTATION + +Some documentation (various Wine Guides etc.) can be found in the +documentation/ directory (apart from also being available on WineHQ). + +If you want to process the SGML files in there, then you can run "make" +in the documentation/ directory. +Doing so requires the sgml tools package (for db2html, db2ps, db2pdf) named: +Debian: docbook-utils +Mandrake: sgml-tools-A.B.C-DDmdk +SuSE: docbktls-A.BB.C-DD -7. GETTING MORE INFORMATION +8. GETTING MORE INFORMATION WWW: A great deal of information about Wine is available from WineHQ at - http://www.winehq.com/ : various user guides, application database, + http://www.winehq.com/ : various Wine Guides, application database, bug tracking. This is probably the best starting point. FAQ: The Wine FAQ is located at http://www.winehq.com/FAQ -HOWTO: The Wine HOWTO is available at +HOWTO: The Wine HOWTO (outdated !) is available at http://www.westfalen.de/witch/wine-HOWTO.txt . Usenet: The best place to get help or to report bugs is the Usenet newsgroup @@ -210,10 +221,9 @@ There are several mailing lists for Wine developers; see http://www.winehq.com/dev.shtml#ml for more information. -If you add something, or fix a bug, please send a patch ('diff -u' -format preferred) to julliard@winehq.com or to the -wine-patches@winehq.com mailing list for inclusion in the next -release. +If you add something, or fix a bug, please send a patch ('diff -u' format +much preferred) to julliard@winehq.com or to the wine-patches@winehq.com +mailing list for inclusion in the next release. -- Alexandre Julliard Index: documentation/HOWTO-winelib =================================================================== RCS file: /home/wine/wine/documentation/HOWTO-winelib,v retrieving revision 1.5 diff -u -r1.5 HOWTO-winelib --- documentation/HOWTO-winelib 29 Dec 2000 03:34:24 -0000 1.5 +++ documentation/HOWTO-winelib 1 Feb 2002 15:42:20 -0000 @@ -141,7 +141,7 @@ MFC. The first hurdle is how to legally get MFC source code on your computer. MFC source code comes as a part of Visual Studio. The license for Visual Studio implies it is a single product that can not -be broken up into its components. The cleanest way to get MFC on you +be broken up into its components. The cleanest way to get MFC on your system is to use a dual boot Linux box with the windows partition visible to the Linux OS. Boot into windows and install Visual Studio. Since Visual Studio is installed on the computer, you have not @@ -221,7 +221,7 @@ During the execution of your program, Wine prints error messages to standard error. These error messages include "stubs", which are windows API functions that have not been completely -implemented. Depending on the the system call, these could be harmless +implemented. Depending on the system call, these could be harmless or crash your program. Most of the common windows API functions have already been implemented, so you should have no missing API functions or only a few missing functions. If you intend to continue with the @@ -403,9 +403,7 @@ import winmm If you need to list multiple DLLs, then the import specification can -appear multiple times. - -FIXME: can multiple libraries appear on one import line? +appear multiple times, one line per imported DLL. VI. Compiling A Win32 Program With Resources @@ -494,7 +492,7 @@ file <wine>/tools/winebuild/README for more details on the spec file format. -During the the compile process, a command like +During the compile process, a command like winebuild -fPIC -o winedll.spec.c -spec winedll.spec will be executed to create the file winedll.spec.c from information in the file winedll.spec. The file winedll.spec.c and winedll.c are @@ -551,7 +549,7 @@ pointers. There is no need for any function ordinals unless your program calls functions by the ordinal. -During the the compile process, a command like +During the compile process, a command like winebuild -fPIC -o winedll.spec.c -spec winedll.spec will be executed to create the file winedll.spec.c from information in the file winedll.spec. The file winedll.spec.c and winedll.c are @@ -559,7 +557,7 @@ Now that the shared library is compiled, you still need to compile your program. Part of the compile process for your program will -consist of a spec file for you program. For example, +consist of a spec file for your program. For example, name program mode guiexe type win32 @@ -571,7 +569,7 @@ winedll.dll. If this import line is not included, the "hidden" DLL will not be loaded and the function pointers will not be initialized. -During the the compile process, a command like +During the compile process, a command like winebuild -fPIC -o program.spec.c -spec program.spec will be executed to create the file program.spec.c from information in the file program.spec. The file program.spec.c and your source code are @@ -596,7 +594,7 @@ shared library (what you renamed DllMain to). There is no need for any function ordinals unless your program calls functions by the ordinal. -During the the compile process, a command like +During the compile process, a command like winebuild -fPIC -o winedll.spec.c -spec winedll.spec will be executed to create the file winedll.spec.c from information in the file winedll.spec. The file winedll.spec.c and the source code for @@ -611,7 +609,7 @@ init WinMain import winedll.dll -During the the compile process, a command like +During the compile process, a command like winebuild -fPIC -o program.spec.c -spec program.spec will be executed to create the file program.spec.c from information in the file program.spec. The file program.spec.c and your source code are @@ -638,7 +636,7 @@ for quite some time, because: 1. It is difficult for us to support and it is impossible - to do so prefectly without special compiler support, + to do so perfectly without special compiler support, because of memory layout issues. For example Win16 int is 16-bit and data is aligned 16-bit. 2. It is in almost all cases easier to port a Index: documentation/configuring.sgml =================================================================== RCS file: /home/wine/wine/documentation/configuring.sgml,v retrieving revision 1.10 diff -u -r1.10 configuring.sgml --- documentation/configuring.sgml 14 Jan 2002 19:44:30 -0000 1.10 +++ documentation/configuring.sgml 1 Feb 2002 15:42:22 -0000 @@ -1434,390 +1434,423 @@ </sect2> </sect1> - <sect1 id="dll-overrides"> - <title>Dll Overrides</title> - - <para> - Written by &name-ove-kaaven; <email>&email-ove-kaaven;</email> - </para> - <para> - (Extracted from <filename>wine/documentation/dll-overrides</filename>) - </para> - - <para> - The <filename>wine.conf</filename> directives [DllDefaults] - and [DllOverrides] are the subject of some confusion. The - overall purpose of most of these directives are clear enough, - though - given a choice, should Wine use its own built-in - DLLs, or should it use <filename>.DLL</filename> files found - in an existing Windows installation? This document explains - how this feature works. - </para> - - <sect2> - <title>DLL types</title> - <variablelist> - <varlistentry> - <term>native</term> - <listitem> <para> - A "native" DLL is a <filename>.DLL</filename> file - written for the real Microsoft Windows. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>builtin</term> - <listitem> <para> - A "builtin" DLL is a Wine DLL. These can either be a - part of <filename>libwine.so</filename>, or more - recently, in a special <filename>.so</filename> file - that Wine is able to load on demand. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>elfdll</term> - <listitem> <para> - An "elfdll" is a Wine <filename>.so</filename> file - with a special Windows-like file structure that is as - close to Windows as possible, and that can also - seamlessly link dynamically with "native" DLLs, by - using special ELF loader and linker tricks. Bertho - Stultiens did some work on this, but this feature has - not yet been merged back into Wine (because of - political reasons and lack of time), so this DLL type - does not exist in the official Wine at this time. In - the meantime, the "builtin" DLL type gained some of - the features of elfdlls (such as dynamic loading), so - it's possible that "elfdll" functionality will be - folded into "builtin" at some point. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>so</term> - <listitem> <para> - A native Unix <filename>.so</filename> file, with - calling convention conversion thunks generated on the - fly as the library is loaded. This is mostly useful - for libraries such as "glide" that have exactly the - same API on both Windows and Unix. - </para> </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2> - <title>The [DllDefaults] section</title> - <variablelist> - <varlistentry> - <term>DefaultLoadOrder</term> - <listitem> <para> - This specifies in what order Wine should search for - available DLL types, if the DLL in question was not - found in the [DllOverrides] section. - </para> </listitem> - </varlistentry> - </variablelist> - </sect2> - - <sect2> - <title>The [DllPairs] section</title> + <sect1 id="dll-config"> + <title>DLL configuration</title> + <sect2 id="dll-overrides"> + <title>DLL Overrides</title> + + <para> + Written by &name-ove-kaaven; <email>&email-ove-kaaven;</email> + </para> + <para> + (Extracted from <filename>wine/documentation/dll-overrides</filename>) + </para> + <para> - At one time, there was a section called [DllPairs] in the - default configuration file, but this has been obsoleted - because the pairing information has now been embedded into - Wine itself. (The purpose of this section was merely to be - able to issue warnings if the user attempted to pair - codependent 16-bit/32-bit DLLs of different types.) If you - still have this in your <filename>wine.conf</filename> or - <filename>~/.wine/config</filename>, you may safely delete it. + The <filename>wine.conf</filename> directives [DllDefaults] + and [DllOverrides] are the subject of some confusion. The + overall purpose of most of these directives are clear enough, + though - given a choice, should Wine use its own built-in + DLLs, or should it use <filename>.DLL</filename> files found + in an existing Windows installation? This document explains + how this feature works. </para> + + <sect3> + <title>DLL types</title> + <variablelist> + <varlistentry> + <term>native</term> + <listitem> <para> + A "native" DLL is a <filename>.DLL</filename> file + written for the real Microsoft Windows. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>builtin</term> + <listitem> <para> + A "builtin" DLL is a Wine DLL. These can either be a + part of <filename>libwine.so</filename>, or more + recently, in a special <filename>.so</filename> file + that Wine is able to load on demand. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>elfdll</term> + <listitem> <para> + An "elfdll" is a Wine <filename>.so</filename> file + with a special Windows-like file structure that is as + close to Windows as possible, and that can also + seamlessly link dynamically with "native" DLLs, by + using special ELF loader and linker tricks. Bertho + Stultiens did some work on this, but this feature has + not yet been merged back into Wine (because of + political reasons and lack of time), so this DLL type + does not exist in the official Wine at this time. In + the meantime, the "builtin" DLL type gained some of + the features of elfdlls (such as dynamic loading), so + it's possible that "elfdll" functionality will be + folded into "builtin" at some point. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>so</term> + <listitem> <para> + A native Unix <filename>.so</filename> file, with + calling convention conversion thunks generated on the + fly as the library is loaded. This is mostly useful + for libraries such as "glide" that have exactly the + same API on both Windows and Unix. + </para> </listitem> + </varlistentry> + </variablelist> + </sect3> + + <sect3> + <title>The [DllDefaults] section</title> + <variablelist> + <varlistentry> + <term>DefaultLoadOrder</term> + <listitem> <para> + This specifies in what order Wine should search for + available DLL types, if the DLL in question was not + found in the [DllOverrides] section. + </para> </listitem> + </varlistentry> + </variablelist> + </sect3> + + <sect3> + <title>The [DllPairs] section</title> + <para> + At one time, there was a section called [DllPairs] in the + default configuration file, but this has been obsoleted + because the pairing information has now been embedded into + Wine itself. (The purpose of this section was merely to be + able to issue warnings if the user attempted to pair + codependent 16-bit/32-bit DLLs of different types.) If you + still have this in your <filename>wine.conf</filename> or + <filename>~/.wine/config</filename>, you may safely delete it. + </para> + </sect3> + + <sect3> + <title>The [DllOverrides] section</title> + <para> + This section specifies how you want specific DLLs to be + handled, in particular whether you want to use "native" DLLs + or not, if you have some from a real Windows configuration. + Because builtins do not mix seamlessly with native DLLs yet, + certain DLL dependencies may be problematic, but workarounds + exist in Wine for many popular DLL configurations. Also see + WWN's [16]Status Page to figure out how well your favorite + DLL is implemented in Wine. + </para> + <para> + It is of course also possible to override these settings by + explictly using Wine's <parameter>--dll</parameter> + command-line option (see the man page for details). Some + hints for choosing your optimal configuration (listed by + 16/32-bit DLL pair): + </para> + <variablelist> + <varlistentry> + <term>krnl386, kernel32</term> + <listitem> <para> + Native versions of these will never work, so don't try. Leave + at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>gdi, gdi32</term> + <listitem> <para> + Graphics Device Interface. No effort has been made at trying to + run native GDI. Leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>user, user32</term> + <listitem> <para> + Window management and standard controls. It was + possible to use Win95's <literal>native</literal> + versions at some point (if all other DLLs that depend + on it, such as comctl32 and comdlg32, were also run + <literal>native</literal>). However, this is no longer + possible after the Address Space Separation, so leave + at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>ntdll</term> + <listitem> <para> + NT kernel API. Although badly documented, the + <literal>native</literal> version of this will never + work. Leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>w32skrnl</term> + <listitem> <para> + Win32s (for Win3.x). The <literal>native</literal> + version will probably never work. Leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>wow32</term> + <listitem> <para> + Win16 support library for NT. The + <literal>native</literal> version will probably never + work. Leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>system</term> + <listitem> <para> + Win16 kernel stuff. Will never work + <literal>native</literal>. Leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>display</term> + <listitem> <para> + Display driver. Definitely leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>toolhelp</term> + <listitem> <para> + Tool helper routines. This is rarely a source of problems. + Leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>ver, version</term> + <listitem> <para> + Versioning. Seldom useful to mess with. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>advapi32</term> + <listitem> <para> + Registry and security features. Trying the + <literal>native</literal> version of this may or may + not work. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>commdlg, comdlg32</term> + <listitem> <para> + Common Dialogs, such as color picker, font dialog, + print dialog, open/save dialog, etc. It is safe to try + <literal>native</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>commctrl, comctl32</term> + <listitem> <para> + Common Controls. This is toolbars, status bars, list controls, + the works. It is safe to try <literal>native</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>shell, shell32</term> + <listitem> <para> + Shell interface (desktop, filesystem, etc). Being one of the + most undocumented pieces of Windows, you may have luck with the + <literal>native</literal> version, should you need it. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>winsock, wsock32</term> + <listitem> <para> + Windows Sockets. The <literal>native</literal> version + will not work under Wine, so leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>icmp</term> + <listitem> <para> + ICMP routines for wsock32. As with wsock32, leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mpr</term> + <listitem> <para> + The <literal>native</literal> version may not work due + to thunking issues. Leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>lzexpand, lz32</term> + <listitem> <para> + Lempel-Ziv decompression. Wine's + <literal>builtin</literal> version ought to work fine. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>winaspi, wnaspi32</term> + <listitem> <para> + Advanced SCSI Peripheral Interface. The + <literal>native</literal> version will probably never + work. Leave at <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>crtdll</term> + <listitem> <para> + C Runtime library. The <literal>native</literal> + version will easily work better than Wine's on this + one. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>winspool.drv</term> + <listitem> <para> + Printer spooler. You are not likely to have more luck + with the <literal>native</literal> version. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>ddraw</term> + <listitem> <para> + DirectDraw/Direct3D. Since Wine does not implement the + DirectX HAL, the <literal>native</literal> version + will not work at this time. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>dinput</term> + <listitem> <para> + DirectInput. Running this <literal>native</literal> + may or may not work. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>dsound</term> + <listitem> <para> + DirectSound. It may be possible to run this + <literal>native</literal>, but don't count on it. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>dplay/dplayx</term> + <listitem> <para> + DirectPlay. The <literal>native</literal> version + ought to work best on this, if at all. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mmsystem, winmm</term> + <listitem> <para> + Multimedia system. The <literal>native</literal> + version is not likely to work. Leave at + <literal>builtin</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>msacm, msacm32</term> + <listitem> <para> + Audio Compression Manager. The + <literal>builtin</literal> version works best, if you + set msacm.drv to the same. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>msvideo, msvfw32</term> + <listitem> <para> + Video for Windows. It is safe (and recommended) to try + <literal>native</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mcicda.drv</term> + <listitem> <para> + CD Audio MCI driver. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mciseq.drv</term> + <listitem> <para> + MIDI Sequencer MCI driver (<filename>.MID</filename> + playback). + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mciwave.drv</term> + <listitem> <para> + Wave audio MCI driver (<filename>.WAV</filename> playback). + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mciavi.drv</term> + <listitem> <para> + AVI MCI driver (<filename>.AVI</filename> video + playback). Best to use <literal>native</literal>. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>mcianim.drv</term> + <listitem> <para> + Animation MCI driver. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>msacm.drv</term> + <listitem> <para> + Audio Compression Manager. Set to same as msacm32. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>midimap.drv</term> + <listitem> <para> + MIDI Mapper. + </para> </listitem> + </varlistentry> + <varlistentry> + <term>wprocs</term> + <listitem> <para> + This is a pseudo-DLL used by Wine for thunking + purposes. A <literal>native</literal> version of this + doesn't exist. + </para> </listitem> + </varlistentry> + </variablelist> + </sect3> </sect2> - - <sect2> - <title>The [DllOverrides] section</title> + <sect2 id="dll-missing"> + <title>Missing DLLs</title> + <para> - This section specifies how you want specific DLLs to be - handled, in particular whether you want to use "native" DLLs - or not, if you have some from a real Windows configuration. - Because builtins do not mix seamlessly with native DLLs yet, - certain DLL dependencies may be problematic, but workarounds - exist in Wine for many popular DLL configurations. Also see - WWN's [16]Status Page to figure out how well your favorite - DLL is implemented in Wine. + Written by &name-andreas-mohr; <email>&email-andreas-mohr;</email> </para> + <para> - It is of course also possible to override these settings by - explictly using Wine's <parameter>--dll</parameter> - command-line option (see the man page for details). Some - hints for choosing your optimal configuration (listed by - 16/32-bit DLL pair): + In case Wine complains about a missing DLL, you should check whether + this file is a publicly available DLL or a custom DLL belonging + to your program (by searching for its name on the internet). + If you managed to get hold of the DLL, then you should make sure + that Wine is able to find and load it. + DLLs usually get loaded according to the mechanism of the + SearchPath() function. + This function searches directories in the following order: + + a) The directory the program was started from. + b) The current directory. + c) The Windows system directory. + d) The Windows directory. + e) The PATH variable directories. + + In short: either put the required DLL into your application + directory (might be ugly), or usually put it into the Windows system + directory. Just find out its directory by having a look at the Wine + config File variable "System" (which indicates the location of the + Windows system directory) and the associated drive entry. </para> - <variablelist> - <varlistentry> - <term>krnl386, kernel32</term> - <listitem> <para> - Native versions of these will never work, so don't try. Leave - at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>gdi, gdi32</term> - <listitem> <para> - Graphics Device Interface. No effort has been made at trying to - run native GDI. Leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>user, user32</term> - <listitem> <para> - Window management and standard controls. It was - possible to use Win95's <literal>native</literal> - versions at some point (if all other DLLs that depend - on it, such as comctl32 and comdlg32, were also run - <literal>native</literal>). However, this is no longer - possible after the Address Space Separation, so leave - at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>ntdll</term> - <listitem> <para> - NT kernel API. Although badly documented, the - <literal>native</literal> version of this will never - work. Leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>w32skrnl</term> - <listitem> <para> - Win32s (for Win3.x). The <literal>native</literal> - version will probably never work. Leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>wow32</term> - <listitem> <para> - Win16 support library for NT. The - <literal>native</literal> version will probably never - work. Leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>system</term> - <listitem> <para> - Win16 kernel stuff. Will never work - <literal>native</literal>. Leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>display</term> - <listitem> <para> - Display driver. Definitely leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>toolhelp</term> - <listitem> <para> - Tool helper routines. This is rarely a source of problems. - Leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>ver, version</term> - <listitem> <para> - Versioning. Seldom useful to mess with. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>advapi32</term> - <listitem> <para> - Registry and security features. Trying the - <literal>native</literal> version of this may or may - not work. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>commdlg, comdlg32</term> - <listitem> <para> - Common Dialogs, such as color picker, font dialog, - print dialog, open/save dialog, etc. It is safe to try - <literal>native</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>commctrl, comctl32</term> - <listitem> <para> - Common Controls. This is toolbars, status bars, list controls, - the works. It is safe to try <literal>native</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>shell, shell32</term> - <listitem> <para> - Shell interface (desktop, filesystem, etc). Being one of the - most undocumented pieces of Windows, you may have luck with the - <literal>native</literal> version, should you need it. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>winsock, wsock32</term> - <listitem> <para> - Windows Sockets. The <literal>native</literal> version - will not work under Wine, so leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>icmp</term> - <listitem> <para> - ICMP routines for wsock32. As with wsock32, leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mpr</term> - <listitem> <para> - The <literal>native</literal> version may not work due - to thunking issues. Leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>lzexpand, lz32</term> - <listitem> <para> - Lempel-Ziv decompression. Wine's - <literal>builtin</literal> version ought to work fine. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>winaspi, wnaspi32</term> - <listitem> <para> - Advanced SCSI Peripheral Interface. The - <literal>native</literal> version will probably never - work. Leave at <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>crtdll</term> - <listitem> <para> - C Runtime library. The <literal>native</literal> - version will easily work better than Wine's on this - one. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>winspool.drv</term> - <listitem> <para> - Printer spooler. You are not likely to have more luck - with the <literal>native</literal> version. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>ddraw</term> - <listitem> <para> - DirectDraw/Direct3D. Since Wine does not implement the - DirectX HAL, the <literal>native</literal> version - will not work at this time. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>dinput</term> - <listitem> <para> - DirectInput. Running this <literal>native</literal> - may or may not work. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>dsound</term> - <listitem> <para> - DirectSound. It may be possible to run this - <literal>native</literal>, but don't count on it. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>dplay/dplayx</term> - <listitem> <para> - DirectPlay. The <literal>native</literal> version - ought to work best on this, if at all. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mmsystem, winmm</term> - <listitem> <para> - Multimedia system. The <literal>native</literal> - version is not likely to work. Leave at - <literal>builtin</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>msacm, msacm32</term> - <listitem> <para> - Audio Compression Manager. The - <literal>builtin</literal> version works best, if you - set msacm.drv to the same. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>msvideo, msvfw32</term> - <listitem> <para> - Video for Windows. It is safe (and recommended) to try - <literal>native</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mcicda.drv</term> - <listitem> <para> - CD Audio MCI driver. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mciseq.drv</term> - <listitem> <para> - MIDI Sequencer MCI driver (<filename>.MID</filename> - playback). - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mciwave.drv</term> - <listitem> <para> - Wave audio MCI driver (<filename>.WAV</filename> playback). - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mciavi.drv</term> - <listitem> <para> - AVI MCI driver (<filename>.AVI</filename> video - playback). Best to use <literal>native</literal>. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>mcianim.drv</term> - <listitem> <para> - Animation MCI driver. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>msacm.drv</term> - <listitem> <para> - Audio Compression Manager. Set to same as msacm32. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>midimap.drv</term> - <listitem> <para> - MIDI Mapper. - </para> </listitem> - </varlistentry> - <varlistentry> - <term>wprocs</term> - <listitem> <para> - This is a pseudo-DLL used by Wine for thunking - purposes. A <literal>native</literal> version of this - doesn't exist. - </para> </listitem> - </varlistentry> - </variablelist> </sect2> </sect1> Index: documentation/wine.conf.man.in =================================================================== RCS file: /home/wine/wine/documentation/wine.conf.man.in,v retrieving revision 1.12 diff -u -r1.12 wine.conf.man.in --- documentation/wine.conf.man.in 14 Jan 2002 19:44:30 -0000 1.12 +++ documentation/wine.conf.man.in 1 Feb 2002 15:42:22 -0000 @@ -104,25 +104,30 @@ .br default: "C:\\\\WINDOWS" .br -Used to specify a different Windows directory; make sure to double the -backslashes. -So if you previously configured drive C: to be at /dos, this now means that -the windows directory should be at /dos/WINDOWS. +Used to specify where Wine is supposed to have its Windows directory +(which is an essential part of a Windows environment); make sure to double +the backslashes. +In case of e.g. C:\\WINDOWS, with drive C: being configured as +/home/user/wine_c, the /home/user/wine_c/WINDOWS directory would be used for +this. .PP .I format: """system""=""<directory>""" .br default: "C:\\\\WINDOWS\\\\System" .br -Used to specify a different system directory; make sure to double the -backslashes. -Again, given a drive C: at /dos, this would be at /dos/WINDOWS/System. +Used to specify where Wine is supposed to have its Windows system directory +(again, essential part of Windows environment); make sure to double the backslashes. +Given a setting of C:\\WINDOWS\\System (the standard setting on Windows) +and a C: drive again at /home/user/wine_c, the /home/user/wine_c/WINDOWS/System +directory would be used for this. .PP .I format: """temp""=""<directory>""" .br default: "C:\\\\TEMP" .br Used to specify a directory where Windows applications can store -temporary files. +temporary files. E.g. with a C: drive at /home/user/wine_c, this would be +the /home/user/wine_c/TEMP directory. .PP .I format: """profile""=""<directory>""" .br Index: documentation/wine.man.in =================================================================== RCS file: /home/wine/wine/documentation/wine.man.in,v retrieving revision 1.33 diff -u -r1.33 wine.man.in --- documentation/wine.man.in 23 Nov 2001 23:05:00 -0000 1.33 +++ documentation/wine.man.in 1 Feb 2002 15:42:22 -0000 @@ -81,6 +81,8 @@ .br .I --debugmsg +relay=advapi32 will only turn on relay messages into the ADVAPI32 code. +Never ever use simply --debugmsg +all ! Way too much info, and it crashes +way too easily, thus confusing unexperienced users. .PP The full list of names is: all, accel, advapi, animate, aspi, atom, avifile, bitblt, bitmap, caret,
