Release 980301
Sun Mar 1 10:45:23 1998 Andreas Mohr <100.30936@germany.net>
* [loader/ne_image.c]
Fixed problem with weird DLLs (NE_FFLAGS_SINGLEDATA && DGROUP = 0).
* [msdos/dosmem.c]
Export address for __0000H, too.
* [msdos/dpmi.c]
Changed MemAlloc functions to return less fragmented addresses.
Sat Feb 28 18:50:12 1998 Alexandre Julliard <julliard@lrc.epfl.ch>
* [scheduler/process.c] [scheduler/sysdeps.c]
Don't use %fs register before threading initialization.
Sat Feb 28 14:04:56 1998 Kristian Nielsen <kristian.nielsen@risoe.dk>
* [configure.in] [include/acconfig.h]
Autoconf macro to check for non-reentrant X libraries.
* [windows/winpos.c]
In SetWindowPos32(), do not cause WM_SIZE messages when the
SWP_NOSIZE flag is specified. This fixes the division-by-zero in
Borland C++ 4.0 "Open Project" menu item.
Sat Feb 28 13:11:26 1998 James Moody <013263m@dragon.acadiau.ca>
* [ole/ole2nls.c]
Changed "English" values from German to English.
* [files/dos_fs.c]
Fixed off-by-one month bug.
Fri Feb 27 22:12:01 1998 Douglas Ridgway <ridgway@winehq.com>
* [windows/win.c]
Fix winelib class menu loading bug.
* [include/module.h] [loader/module.c]
LoadModule32 should be implemented in terms of CreateProcess.
* [programs/view/*]
Metafile viewer sample program.
* [documentation/wine.texinfo] [documentation/Makefile.in]
Improvements and additions, HTML target.
Fri Feb 27 04:27:48 1998 Dimitrie O. Paun <dimi@cs.toronto.edu>
* [*/*]
Switched to the new debug messages interface. For more information
please refer to documentation/debug-msgs. Because the new scheme
introduces a new semantic level, I had to manually do through
about 530 dprintf_xxx! The rest of about 2400 where transformed
via a script. Because of the large number of changes that I had
to do, some may have not come out as nicely as I wanted them. If
this is the case, please let me know. There is a lot of work left
to do: -- a few hundred printf's to be converted -- about 2300
fprintf's to be converted -- about 600 FIXME's to be transformed
The problem is that in the above mentioned cases, a lot of manual
intervention is required because a lot of the information is
missing. There are also a lot of other things to be done to the
interface and so forth. I have now ideas for a at least a month
worth of full time work :) I will proceed with many changes in the
next few releases, so please do not start modifing things because
there will be a hell of a lot of conflicts. If you have ideas that
you want to integrate or you want to work on different things,
please coordinate with me.
Thu Feb 26 13:04:29 1998 David Lee Lambert <lamber45@egr.msu.edu>
* [ole/ole2nls.c] [include/windows.h]
First try at OLE date- and time-formatting functions.
Wed Feb 25 11:20:35 1998 Marcus Meissner <msmeissn@cip.informatik.uni-erlangen.de>
* [files/*.c]
Changed dos device handling, added 'CON' devicehandling.
* [graphics/ddraw.c]
Bug fixes, some additions.
* [if1632/builtin.c][loader/module.c][library/winestub.c]
Small hack so we don't need a dummy BUILTIN_LoadModule
in winestub.c.
* [ole/*][relay32/ole32.spec][if1632/storage.spec]
storage.dll started. winword loads documents (saving
doesn't work yet, dunno why).
Several ole additions, some cleanups and bugfixes.
IMalloc16 implemented.
* [loader/pe_image.c]
Added some comments, fixed circular dll references,
fixed modref ordering, fixed tls allocation.
* [memory/global.c]
Added validity checks before every GET_ARENA_PTR.
(several functions rely on Global* return values
on invalid handles, like IsTask).
Implemented GlobalUnlockFree16.
* [memory/virtual.c]
Replaced dprintf_virtual by fprintf, so we can
do 'info map' again in the debugger. Increase read
linesize for Linux2.1 cases.
* [misc/cpu.c][misc/registry.c]
Moved cpu registry initialization to misc/cpu.c.
* [multimedia/dsound.c]
Enhanced, replaced GETOSPACE bufferingcheck by SETFRAGMENT.
* [relay32/crtdll.spec][relay32/ntdll.spec]
Replaced some ptr by respective 'str' and 'wstr' arguments
for libc functions.
* [scheduler/thread.c]
Added some sanity checks to stackallocation, tlshandling fixed.
* [tools/build.c]
Fixed cdecl argumenttype order (was reversed).
* [win32/ordinals.c]
Implemented KERNEL_449.
* [windows/dinput.c]
Some fixes, needs much more work. Tomb Raider2 works with keyboard ;)
Tue Feb 24 20:46:37 1998 James Juran <jrj120@psu.edu>
* [windows/win.c]
Fixed USER32 ordinal numbers in documentation.
Sat Feb 21 12:30:38 1998 John Richardson <jrichard@zko.dec.com>
* [files/file.c] [include/k32obj.h] [memory/virtual.c]
[scheduler/critsection.c] [scheduler/event.c] [scheduler/handle.c]
[scheduler/k32obj.c] [scheduler/mutex.c] [scheduler/process.c]
[scheduler/semaphore.c] [scheduler/thread.c]
Added generic k32obj read and write routines for k32objs that
support I/O.
* [documentation/console]
Updated console docs.
* [win32/console.c]
Make console work like a k32obj that supports I/O.
* [include/windows.h]
Make WriteFile and ReadFile take HANDLE32 for handle.
Sun Feb 15 14:07:07 1998 Dimitrie O. Paun <dimi@mail.cs.toronto.edu>
* [controls/menu.c] [misc/ver.c] [multimedia/dsound.c]
[multimedia/joystick.c] [windows/dialog.c]
Modified some dprintf_xxx's to prepare them for a new
dprintf_ scheme. Basically, I changed the dprintf's that
outputed a line with many dprintf calls to do just one
dprintf call.
diff --git a/documentation/Makefile.in b/documentation/Makefile.in
index 6026158..fdf44b1 100644
--- a/documentation/Makefile.in
+++ b/documentation/Makefile.in
@@ -18,14 +18,21 @@
wine.info-1 \
wine.info-2
+HTMLFILES = \
+ wine_toc.html \
+ wine.html
+
DVIFILES = wine.dvi
-all: $(INFOFILES) $(DVIFILES)
+
+all: $(INFOFILES) $(DVIFILES) $(HTMLFILES)
info: $(INFOFILES)
dvi: $(DVIFILES)
+html: $(HTMLFILES)
+
@MAKE_RULES@
$(INFOFILES): $(SOURCES)
@@ -34,6 +41,10 @@
$(DVIFILES): $(SOURCES)
texi2dvi $(SRCDIR)/wine.texinfo
+$(HTMLFILES): $(SOURCES)
+ makeinfo -E wine.texi $(SRCDIR)/wine.texinfo
+ texi2html wine.texi
+
$(INCLUDES):
$(RM) $(INCLUDES)
for i in $(INCLUDES); do $(LN_S) $(TOPSRCDIR)/$$i $$i || exit 1; done
@@ -48,7 +59,8 @@
clean::
$(RM) $(INFOFILES) $(DVIFILES) $(INCLUDES)
$(RM) wine.aux wine.cp wine.cps wine.fn wine.fns wine.ky wine.log \
- wine.pg wine.toc wine.tp wine.tps wine.vr wine.vrs
+ wine.pg wine.toc wine.tp wine.tps wine.vr wine.vrs \
+ wine.texi
$(RM) -r man3w
### Dependencies:
diff --git a/documentation/console b/documentation/console
index a623e35..f6c71c6 100644
--- a/documentation/console
+++ b/documentation/console
@@ -4,12 +4,17 @@
Consoles are just xterms created with the -Sxxn switch.
A pty is opened and the master goes to the xterm side
-and the slave is held by the wine side. The slave fd
-is changed into a HANDLE32 and this HANDLE32 is set
+and the slave is held by the wine side. The console
+itself it turned into a few HANDLE32s and is set
to the STD_*_HANDLES.
-For now writing/reading to a console just calls FileWrite/FileRead.
+It is possible to use the WriteFile and ReadFile commands
+to write to a win32 console. To accomplish this, all K32OBJs
+that support I/O have a read and write function pointer.
+So, WriteFile calls K32OBJ_WriteFile which calls the K32OBJ's
+write function pointer, which then finally calls write.
+[this paragraph is now out of date]
If the command line console is to be inheirited or
a process inherits it's parents console (-- can that happen???),
the console is created at process init time via PROCESS_InheritConsole.
@@ -23,20 +28,55 @@
it is possible to create a new console (via AllocConsole).
-Like most k32 objects, when the FreeConsole is called, the
-ref count is decremented and the console is freed when
-it reaches zero. The free kills the xterm and closes
-the master/slave fds.
+When FreeConsole is called, all handles that the process has
+open to the console are closed. Like most k32objs, if the
+console's refcount reaches zero, its k32obj destroy function
+is called. The destroy kills the xterm if one was open.
Also like most k32 objects, we assume that (K32OBJ) header is the
first field so the casting (from K32OBJ *to CONSOLE *)
works correctly.
+FreeConsole is called on process exit (in ExitProcess) if
+pdb->console is not NULL.
+
BUGS
----
+Console processes do not inherit their parent's handles. I think
+there needs to be two cases, one where they have to inherit
+the stdin/stdout/stderr from unix, and one where they have to
+inherit from another windows app.
-A exit handler needs to be added. If the process exits
-without calling FreeConsole, the xterm continues on...
-But... there should probably be a generic exit handler in
-wine for this kind of stuff (K32OBJs).
+================================================================
+
+experimentation with NT4 yields that:
+
+WriteFile
+---------
+ o does not truncate file on 0 length write
+ o 0 length write or error on write changes numcharswritten to 0
+ o 0 length write returns TRUE
+ o works with console handles
+
+_lwrite
+-------
+ o does truncate/expand file at current position on 0 length write
+ o returns 0 on a zero length write
+ o works with console handles (typecasted)
+
+WriteConsole
+------------
+ o expects only console handles
+
+
+SetFilePointer
+--------------
+ o returns -1 (err 6) when used with a console handle
+
+
+FreeConsole
+-----------
+ o even when all the handles to it are freed, the win32 console
+ stays visible, the only way I could find to free it
+ was via the FreeConsole
diff --git a/documentation/debug-msgs b/documentation/debug-msgs
new file mode 100644
index 0000000..3953a68
--- /dev/null
+++ b/documentation/debug-msgs
@@ -0,0 +1,351 @@
+Note: the debugging interface is under development. Please do not make
+ changes to it yet as I will do major changes in the next few weeks.
+ To make my life easier, PLEASE follow the guidelines described in
+ this document. If you have some ideas that you would like to
+ incorporate, please contact me first.
+ Please read the document before writing new code.
+ Also, DO NOT USE fprintf (or printf) to output things. All these
+ will have to be translated to dprintf_ calls and there are already
+ about 3000 of them! Also, instead of writing FIXMEs in the source,
+ output a dprintf_fixme message. But read on...
+25 Feb 1998, Dimitrie O. Paun <dimi@cs.toronto.edu>
+
+
+Debugging classes
+-----------------
+
+The debugging messages are divided into 4 classes:
+
+fixme -- Messages in this class relate to behavior of Wine that does
+ not correspond to standard Windows behavior and that should
+ be fixed.
+ Examples: stubs, semi-implemented features, etc.
+
+err -- Messages in this class relate to serious errors in Wine.
+ This sort of messages are close to asserts -- that is,
+ you should output a 'err' message when the code detects a
+ condition which should not happen.
+ Examples: unexpected change in internal state, etc.
+
+warn -- This are warning messages. You should report a warning when
+ something unwanted happen but the function behaves properly.
+ That is, output a warning when you encounter something
+ unexpected (ex: could not open a file) but the function deals
+ correctly with the situation (that is, according to the docs).
+ If you do not deal correctly with it, output a fixme.
+ Examples: fail to access a resource required by the app, etc.
+
+info -- This are detailed debugging messages that are mainly useful
+ to debug a component. This are usually turned off.
+ Examples: everything else that does not fall in one of the
+ above mentioned categories and the user does not
+ need to know about it. This sort of messages simply
+ outputs something about the state of some component
+ that is of interest mainly to the developer of that
+ component.
+
+We will refer to a generic class as yyy.
+
+The user has the capability to turn on or off messages in a particular
+class. You can expect the following patters of usage (but note that
+any combination is possible):
+ -- when you debug a component, all classes (info,warn,err,fixme)
+ will be enabled.
+ -- during the pre-alpha (maybe alpha) stage of Wine, most likely
+ the info class will be disabled by default, but all others
+ (warn,err,fixme) will be enabled by default.
+ -- when Wine will become stable, most likely the info and warn
+ classes will be disabled by default, but all err and fixme
+ will be enabled by default.
+ -- in some installations that want the smallest footprint
+ and where the debug information is of no interest,
+ all classes may be disabled by default.
+
+Of course, the user will have the runtime ability to override these
+defaults. However, this ability may be turned off and certain classes
+of messages may be completely disabled at compile time to reduce the
+size of Wine.
+
+Debugging channels
+------------------
+
+Also, we divide the debugging messages per component. Each component
+is assigned a debugging channel (or type). The identifier of the
+channel must be a valid C identifier but note that it may also be a
+reserve word like int or static.
+
+Examples of debugging channels/types:
+reg, updown, string
+
+We will refer to a generic channel as xxx.
+
+Note: for those who know the old interface, the channel/type is
+ what followed the _ in the dprintf_xxx statements.
+ For example, to output a message on the debugging channel
+ reg in the old interface you would have to write:
+
+ dprintf_reg(stddeb, "Could not access key!\n");
+
+ In the new interface, we drop the stddeb as it is implicit.
+ However, we add an orthogonal piece of information to the
+ message: its class. This is very important as it will allow
+ us to selectively turn on or off certain messages based on
+ type of information they report. For this reason it is VERY
+ important to choose the right class for the message.
+ Anyhow, suppose we figured that this message should belong
+ in the warn class, so in the new interface, you write:
+
+ dprintf_warn(reg, "Could not access key!\n");
+
+---
+
+How to use it
+-------------
+
+So, to output a message (class yyy) on channel xxx, do:
+
+#include "debug.h"
+
+....
+
+dprintf_yyy(xxx, "<message>", ...);
+
+
+Some examples from the code:
+
+#include "debug.h"
+
+...
+
+ dprintf_info(crtdll,
+ "CRTDLL_setbuf(file %p buf %p)\n",
+ file, buf);
+
+ dprintf_warn(aspi, "Error opening device errno=%d\n", save_error);
+
+
+If you need to declare a new debugging channel, do:
+%tools/make_debug
+in the root directory of Wine.
+
+Note that this will result in almost complete recompilation of Wine.
+
+Notes:
+ 1. Please pay attention to which class you assign the message.
+ It is very, Very, VERY important to get the class right.
+ There are only 4 classes, so it is not hard. The reason
+ it is important to get it right is that too much information
+ is no information. For example, if you put things into the
+ warn class that should really be in the info class, the
+ output will be too big and this will force the user to
+ turn of warnings. But this way he will fail to see the important
+ ones. Also, if you put warnings into the info class lets say,
+ he will most likely miss those because usually the info class
+ is turned off. A similar argument can be made if you mix any
+ other two classes.
+ 2. ALL LINES MUST END WITH A NEWLINE!!! If you can NOT output
+ everything that you want in the line with only one dprintf_xxx
+ statement, then you need to build the string in memory.
+ Please read the section below "In-memory messages" on the
+ preferred way to do it. PLEASE USE THAT INTERFACE TO BUILD
+ MESSAGES IN MEMORY. The reason is that we are not sure that
+ we like it and having everything in one format will facilitate
+ the (automatic) translation to a better interface.
+
+
+
+Are we debugging?
+-----------------
+
+To test whether the debugging output of class yyy on channel xxx is
+enabled, do:
+
+debugging_yyy(xxx)
+
+Examples:
+
+if(debugging_info(atom)){
+ ...blah...
+}
+
+
+
+In-memory messages
+------------------
+
+If you NEED to build the message from multiple calls, you need to
+build it in memory. To do that, you should use the following
+interface:
+
+ - declare a string (where you are allowed to declare C variables)
+ as follows:
+ dbg_decl_str(name, len);
+ where name is the name of the string (you should use the channel
+ name on which you are going to output it)
+
+ - print in it with:
+ dsprintf(name, "<message>", ...);
+ which is just like a sprintf function but instead of a C string as
+ first parameter it takes the name you used to declare it.
+
+ - obtain a pointer to the string with:
+ dbg_str(name)
+
+ - reset the string (if you want to reuse it with):
+ dbg_reset_str(name);
+
+Example (modified from the code):
+
+void some_func(tabs)
+{
+ INT32 i;
+ LPINT16 p = (LPINT16)tabs;
+ dbg_decl_str(listbox, 256); /* declare the string */
+
+ for (i = 0; i < descr->nb_tabs; i++) {
+ descr->tabs[i] = *p++<<1;
+ if(debugging_info(listbox)) /* write in it only if
+ dsprintf(listbox, "%hd ", descr->tabs[i]); /* we are gonna output it */
+ }
+ dprintf_info(listbox, "Listbox %04x: settabstops %s\n",
+ wnd->hwndSelf, dbg_str(listbox)); /* output the whole thing */
+}
+
+If you need to use it two times in the same scope do like this:
+
+void some_func(tabs)
+{
+ INT32 i;
+ LPINT16 p = (LPINT16)tabs;
+ dbg_decl_str(listbox, 256); /* declare the string */
+
+ for (i = 0; i < descr->nb_tabs; i++) {
+ descr->tabs[i] = *p++<<1;
+ if(debugging_info(listbox)) /* write in it only if
+ dsprintf(listbox, "%hd ", descr->tabs[i]); /* we are gonna output it */
+ }
+ dprintf_info(listbox, "Listbox %04x: settabstops %s\n",
+ wnd->hwndSelf, dbg_str(listbox)); /* output the whole thing */
+
+ dbg_reset_str(listbox); /* !!!reset the string!!! */
+ for (i = 0; i < descr->extrainfo_nr; i++) {
+ descr->extrainfo = *p+1;
+ if(debugging_info(listbox)) /* write in it only if
+ dsprintf(listbox,"%3d ",descr->extrainfo); /* we are gonna output it */
+ }
+
+ dprintf_info(listbox, "Listbox %04x: extrainfo %s\n",
+ wnd->hwndSelf, dbg_str(listbox)); /* output the whole thing */
+
+}
+
+IMPORTANT NOTE:
+ As I already stated, I do not think this will be the ultimate interface
+ for building in-memory debugging messages. In fact, I do have better ideas
+ which I hope to have time to implement for the next release. For this
+ reason, please try not to use it. However, if you need to output a line
+ in more than one dprintf_xxx calls, then USE THIS INTERFACE. DO NOT use
+ other methods. This way, I will easily translate everything to the new
+ interface (when it will become available). So, if you need to use if,
+ then follow the following guidelines:
+ -- wrap calls to dsprintf with a
+ if(debugging_yyy(xxx))
+ dsprintf(xxx,...);
+ Of course, if the call to dsprintf is made from within a function
+ which you know is called only if debugging_yyy(xxx) is true
+ (say you call it only like this:
+ if(debugging_yyy(xxx))
+ print_some_debug_info();
+ )
+ then you need not (and should not) wrap calls to dsprintf with
+ the before mentioned if.
+ -- name the string EXACTLY like the debugging channel on which
+ is going to be output. Please see the above example.
+
+
+Resource identifiers
+--------------------
+
+Resource identifiers can be either strings or numbers. To make life a bit
+easier for outputting this beasts (and to help you avoid the need to build
+the message in memory), I introduced a new function called:
+
+debugres
+
+The function is defined in debugstr.h
+and has the following prototype:
+
+LPSTR debugres(const void *id);
+
+It takes a pointer to the resource id and returns a nicely formatted
+string of the identifier.
+
+It the high word of the pointer is 0, then it assumes that the
+identifier is a number and thus returns a string of the form:
+
+#xxxx
+
+where xxxx are 4 hex-digits representing the low word of id.
+
+It the high word of the pointer is not 0, then it assumes that the
+identifier is a string and thus returns a string of the form:
+
+'<identifier>'
+
+Thus, to use it, do something on the following lines:
+
+#include "debugstr.h"
+
+...
+
+ dprintf_yyy(xxx, "resource is %s", debugres(myresource));
+
+
+The -debugmsg command line option
+---------------------------------
+
+So, the -debugmsg command line option has been changed as follows:
+ - the new syntax is: -debugmsg [yyy]#xxx[,[yyy1]#xxx1]*
+ where # is either + or -
+
+ - when the optional class argument (yyy) is not present,
+ then the statement will enable(+)/disable(-) all messages for
+ the given channel (xxx) on all classes. For example:
+
+ -debugmsg +reg,-file
+
+ enables all messages on the reg channel and disables all
+ messages on the file channel.
+ This is very close (actually identical) to the old semantics.
+
+ - when the optional class argument (yyy) is present,
+ then the statement will enable(+)/disable(-) messages for
+ the given channel (xxx) only on the given class. For example:
+
+ -debugmsg info+reg,warn-file
+
+ enables info messages on the reg channel and disables warning
+ messages on the file channel.
+
+ - also, the pseudo-channel all is also supported and it has the
+ intuitive semantics:
+
+ -debugmsg +all -- enables all debug messages
+ -debugmsg -all -- disables all debug messages
+ -debugmsg yyy+all -- enables debug messages for class yyy on all
+ channels.
+ -debugmsg yyy-all -- disables debug messages for class yyy on all
+ channels.
+
+ So, for example:
+
+ -debugmsg warn-all -- disables all warning messages.
+
+
+Also, note that at the moment:
+ - the fixme, err, warn classes are all enabled by default
+ - the info class is disabled by default
+ - there is no way to compile out the messages. All are
+ runtime configurable. This will come next release.
+
+
diff --git a/documentation/debugging b/documentation/debugging
index 1686ae7..7142179 100644
--- a/documentation/debugging
+++ b/documentation/debugging
@@ -51,18 +51,19 @@
the reason is located in the last call(s). Those lines usually look like
this:
-|Call KERNEL.90: LSTRLEN(0227:0692) ret=01e7:2ce7 ds=0227
- ^^^^^^^^^ ^ ^^^^^^^^^ ^^^^^^^^^ ^^^^
- | | | | |Datasegment on entry
- | | | |Return address.
+|Call KERNEL.90: LSTRLEN(0227:0692 "text") ret=01e7:2ce7 ds=0227
+ ^^^^^^^^^ ^ ^^^^^^^^^ ^^^^^^ ^^^^^^^^^ ^^^^
+ | | | | | |Datasegment
+ | | | | |Return address
+ | | | |textual parameter
| | |
| | |Argument(s). This one is a win16 segmented pointer.
| |Function called.
|The module, the function is called in. In this case it is KERNEL.
-|Ret KERNEL.90: LSTRLEN() retval=0x0007 ret=01e7:2ce7 ds=0227
+|Ret KERNEL.90: LSTRLEN() retval=0x0004 ret=01e7:2ce7 ds=0227
^^^^^^
- |Returnvalue is 16 bit and has the value 7.
+ |Returnvalue is 16 bit and has the value 4.
3. If you have found a misbehaving function, try to find out why it
@@ -119,18 +120,28 @@
"continue". With "-debugmsg +all" Wine will now stop directly directly
before setting up the Messagebox. Proceed as explained above.
+ You can also run wine using "wine -debugmsg +relay program.exe 2>&1|less -i"
+ and in less search for messagebox.
Disassembling programs:
=======================
You may also try to disassemble the offending program to check for
undocumented features and/or use of them.
- The best, freely available, disassembler for win16 programs is
+
+ The best, freely available, disassembler for Win16 programs is
Windows Codeback, archivename wcbxxx.zip, which usually can be found
in the Cica-Mirror subdirectory on the WINE ftpsites. (See ANNOUNCE).
- Disassembling win32 programs is currenty only possible using
- Windows Disassembler 32, archivename something like wdasm32x.zip on
- ftp.winsite.com and mirrors.
+ Disassembling win32 programs is possible using the Windows Disassembler 32,
+ archivename something like w32dasm.zip on ftp.winsite.com and mirrors.
+ The shareware version does not allow saving of disassembly listings.
+
+ [It also has a bug, it disassembles the dll and immediately after that
+ crashes, leaving a very large file caled 'winsys' in the directory of the
+ disassembled file. This file contains nothing of value (just the disassembly)
+ and can be safely deleted.]
+
Understanding disassembled code is just a question of exercise.
+
Most code out there uses standard C function entries (for it is usually
written in C). Win16 function entries usually look like that:
| push bp
@@ -157,7 +168,6 @@
| call KERNEL.LSTRLEN
Here first the selector and then the offset to the passed string are pushed.
-
Sample debugging session:
=========================
@@ -171,88 +181,78 @@
|marcus@jet $ wine winword.exe -debugmsg +relay -debug
-|CallTo32(func=08007e00,000001c4,00000081,00000000,00000000)
-|CallTo32(func=08007e00,000001c4,00000014,000006d0,00000000)
-|Win16 task 'winword': Breakpoint 1 at 0x0157:0x001a
-|CallTo16(func=0097:0130,ds=0000)
-|Call WPROCS.24: TASK_RESCHEDULE() ret=003f:0759 ds=0000
-|Ret WPROCS.24: TASK_RESCHEDULE() retval=0x0000 ret=003f:0759 ds=08a7
-|CallTo16(func=0157:001a,ds=08a7,0x11d7,0x0000,0x0000,0x3cb4,0x1f40,0x0000,0x0000,0x08a7)
-|Loading symbols from ELF file /home/marcus/wine/wine...
-|...more Loading symbols ...
-|Stopped on breakpoint 1 at 0x0157:0x001a (WPROCS_VXD_PAGEFILE+0xffffeeea)
+|CallTo32(wndproc=0x40065bc0,hwnd=000001ac,msg=00000081,wp=00000000,lp=00000000)
+|Win16 task 'winword': Breakpoint 1 at 0x01d7:0x001a
+|CallTo16(func=0127:0070,ds=0927)
+|Call WPROCS.24: TASK_RESCHEDULE() ret=00b7:1456 ds=0927
+|Ret WPROCS.24: TASK_RESCHEDULE() retval=0x8672 ret=00b7:1456 ds=0927
+|CallTo16(func=01d7:001a,ds=0927)
+| AX=0000 BX=3cb4 CX=1f40 DX=0000 SI=0000 DI=0927 BP=0000 ES=11f7
+|Loading symbols: /home/marcus/wine/wine...
+|Stopped on breakpoint 1 at 0x01d7:0x001a
|In 16 bit mode.
|Wine-dbg>break MessageBox32A <---- Set Breakpoint
-|Breakpoint 2 at 0x080e792c (MessageBox32A [msgbox.c:198])
+|Breakpoint 2 at 0x40189100 (MessageBox32A [msgbox.c:190])
|Wine-dbg>c <---- Continue
|Call KERNEL.91: INITTASK() ret=0157:0022 ds=08a7
| AX=0000 BX=3cb4 CX=1f40 DX=0000 SI=0000 DI=08a7 ES=11d7 EFL=00000286
|CallTo16(func=090f:085c,ds=0dcf,0x0000,0x0000,0x0000,0x0000,0x0800,0x0000,0x0000,0x0dcf)
|... <----- Much debugoutput
-|Call KERNEL.97: GETTEMPFILENAME(0x00c3,08a7:8350,0x0000,08a7:8234) ret=058f:09b1 ds=08a7
- ^ ^ ^ ^
- | | | |LPSTR buffer
- | | |UINT16 unique
- | |LPCSTR prefix
- |BYTE drive
+|Call KERNEL.136: GETDRIVETYPE(0x0000) ret=060f:097b ds=0927
+ ^^^^^^ Drive 0 (A:)
+|Ret KERNEL.136: GETDRIVETYPE() retval=0x0002 ret=060f:097b ds=0927
+ ^^^^^^ DRIVE_REMOVEABLE
+ (It is a floppy diskdrive.)
-|Ret KERNEL.97: GETTEMPFILENAME() retval=0xce3f ret=058f:09b1 ds=08a7
- ^
- |new unique number
+|Call KERNEL.136: GETDRIVETYPE(0x0001) ret=060f:097b ds=0927
+ ^^^^^^ Drive 1 (B:)
+|Ret KERNEL.136: GETDRIVETYPE() retval=0x0000 ret=060f:097b ds=0927
+ ^^^^^^ DRIVE_CANNOTDETERMINE
+ (I don't have drive B: assigned)
-|Call KERNEL.74: OPENFILE(08a7:8234,08a7:82c6,0x1012) ret=058f:09d8 ds=08a7
- ^ ^ ^
- | | |UINT32 mode
- | |OFSTRUCT *ofs
- |LPCSTR name
+|Call KERNEL.136: GETDRIVETYPE(0x0002) ret=060f:097b ds=0927
+ ^^^^^^^ Drive 2 (C:)
+|Ret KERNEL.136: GETDRIVETYPE() retval=0x0003 ret=060f:097b ds=0927
+ ^^^^^^ DRIVE_FIXED
+ (specified as a harddisk)
-|Ret KERNEL.74: OPENFILE() retval=0xffff ret=058f:09d8 ds=08a7
- ^
- | -1 aka. HFILE_ERROR
+|Call KERNEL.97: GETTEMPFILENAME(0x00c3,0x09278364"doc",0x0000,0927:8248) ret=060f:09b1 ds=0927
+ ^^^^^^ ^^^^^ ^^^^^^^^^
+ | | |buffer for fname
+ | |temporary name ~docXXXX.tmp
+ |Force use of Drive C:.
-|Call USER.1: MESSAGEBOX(0x0000,08ef:8362,0000:0000,0x1030) ret=05d7:084f ds=08efStopped on breakpoint 2 at 0x080e792c (MessageBox32A [msgbox.c:198])
-|198 {
-|In 32 bit mode.
-|Wine-dbg> _
-
- Now, we see that OPENFILE seem to have returned 0xFFFF (or -1). Checking
- the implementation of OpenFile in files/file.c, this signals an error.
- The mode flags (OF_READWRITE|OF_SHARE_EXCLUSIVE|OF_CREATE) seems to
- indicate, that WinWord wants to open the file for writing, so we check
- the filename. Since we don't see the filename in this debugoutput, we use
- the dprintf_file() in OpenFile to print out more information by adding
- "-debugmsg +relay" to the commandline.
-
- (In fact, we see that the filename has been returned by the GetTempFileName
- function above, but we check it anyway.)
-
-|marcus@jet $ wine winword.exe -debugmsg +relay,+file -debug
-|.....much more debugoutput .....
-|
-
-|Call KERNEL.97: GETTEMPFILENAME(0x00c3,08ef:8350,0x0000,08ef:8234) ret=05d7:09b1 ds=08ef
-|FILE_Create: 'C:\~doc8b93.tmp' 01b6 1
-|FILE_SetDosError: errno = 13
-
-|Warning: GetTempFileName returns 'C:\~doc8b93.tmp', which doesn't seem to be writeable.
+|Warning: GetTempFileName returns 'C:~doc9281.tmp', which doesn't seem to be writeable.
|Please check your configuration file if this generates a failure.
- ^ Warning message
-|GetTempFileName: returning C:\~doc8b93.tmp
-|Ret KERNEL.97: GETTEMPFILENAME() retval=0x8b93 ret=05d7:09b1 ds=08ef
-|Call KERNEL.74: OPENFILE(08ef:8234,08ef:82c6,0x1012) ret=05d7:09d8 ds=08ef
-|OpenFile: C:\~doc8b93.tmp 1012
-|FILE_Create: 'C:\~doc8b93.tmp' 01b6 0
-|FILE_SetDosError: errno = 13
-|OpenFile(C:\~doc8b93.tmp): return = HFILE_ERROR
-|Ret KERNEL.74: OPENFILE() retval=0xffff ret=05d7:09d8 ds=08ef
+Whoops, it even detects that something is wrong!
+|Ret KERNEL.97: GETTEMPFILENAME() retval=0x9281 ret=060f:09b1 ds=0927
+ ^^^^^^ Temporary storage ID
- The filename is "C:\~docd03d.tmp". Of course, C:\ is writeable for the
- superuser only, so the open fails for a normal user and OpenFile returns
- -1, which in turn generates this messagebox. (As said by the warning
- message.)
+|Call KERNEL.74: OPENFILE(0x09278248"C:~doc9281.tmp",0927:82da,0x1012) ret=060f:09d8 ds=0927
+ ^^^^^^^^^^^^^^^^ ^^^^^^^^^ ^^^^^^^
+ |filename |OFSTRUCT |open mode:
+ OF_CREATE|OF_SHARE_EXCLUSIVE|OF_READWRITE
+
+This fails, since my C: drive is in this case mounted readonly.
+
+|Ret KERNEL.74: OPENFILE() retval=0xffff ret=060f:09d8 ds=0927
+ ^^^^^^ HFILE_ERROR16, yes, it failed.
+
+|Call USER.1: MESSAGEBOX(0x0000,0x09278376"Sie müssen Windows verlassen und SHARE.EXE laden bevor Sie Word starten.",0x00000000,0x1030) ret=060f:084f ds=0927
+
+And MessageBox'ed.
+
+|Stopped on breakpoint 2 at 0x40189100 (MessageBox32A [msgbox.c:190])
+|190 { <- the sourceline
+In 32 bit mode.
+Wine-dbg>
+
+ The code seems to find a writeable harddisk and tries to create a file
+ there. To work around this bug, you can define C: as a networkdrive,
+ which is ignored by the code above.
Written by Marcus Meissner <msmeissn@cip.informatik.uni-erlangen.de>,
additions welcome.
diff --git a/documentation/wine.texinfo b/documentation/wine.texinfo
index 02f88a6..1425f84 100644
--- a/documentation/wine.texinfo
+++ b/documentation/wine.texinfo
@@ -23,7 +23,7 @@
This file documents Wine, the Windows Emulator.
@c
-Copyright @copyright{} 1997 The Wine authors. @*
+Copyright @copyright{} 1997,1998 The Wine authors. @*
@xref{Authors, The Wine Authors, The Wine Authors},
for a list of the copyright holders.
@@ -44,8 +44,8 @@
the section entitled ``License, Warranty, and Authors of Wine''.
@sp 4
-FIXME: UNIX and POSIX trademarks. @*
-X11 @*
+FIXME: X11 and POSIX trademarks. @*
+UNIX is a registered trademark of the Open Group.
Microsoft, Windows, MS-Windows, Windows-NT, Windows 95, and MS-DOS are
registered trademarks of Microsoft Corporation.
NT is a trademark of Northern Telecom Limited.
@@ -59,17 +59,16 @@
@setchapternewpage odd
@titlepage
-@sp 10
-@center @titlefont{The Wine Reference Manual}
-@center Edition 0.0.3, 14 August 1997
+@title{The Wine Reference Manual}
+@subtitle{Edition 0.0.5, February 1998}
-
+@author{The Wine Team}
@c The following two commands start the copyright page.
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1997 The Wine authors. @*
+Copyright @copyright{} 1997, 1998 The Wine authors. @*
@xref{Authors, The Wine Authors, The Wine Authors},
for a list of the copyright holders.
@@ -101,12 +100,12 @@
@c Edit this macro manually in the above parts of the document
@macro winemanualversion
-0.0.3
+0.0.4
@end macro
@c Edit this macro manually in the above parts of the document
@macro winemanualdate
-14 August 1997
+February 1998
@end macro
@c Edit this macro manually into the TeX titlepage
@@ -122,12 +121,12 @@
@c MICROSOFT
@c
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro mswindows
MS-Windows
@end macro
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@c spell it always the same
@macro WIN32
WIN32
@@ -136,17 +135,17 @@
WIN16
@end macro
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro WINNT
Windows NT
@end macro
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro WINNT40
Windows NT 4.0
@end macro
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro WIN95
Windows 95
@end macro
@@ -155,12 +154,12 @@
@c
@c THE OTHERS
@c
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro unix
UNIX
@end macro
-@c FIXME: automatical trademark reference
+@c FIXME: automatic trademark reference
@macro posix
POSIX
@end macro
@@ -1203,7 +1202,14 @@
@section Applying patches
@xref{Creating patches}, for instructions on creating patches.
-FIXME: write patch instructions
+@kbd{cd} to the top source directory for Wine, and run
+@code{patch -p1 < @var{patchfile}}.
+What needs to be done next depends to some extent on what the
+patch touches. For small patches which only alter C source, it can be
+enough to rerun @code{make}. In general, the sequence @code{configure},
+@code{make depend}, @code{make} is sufficient, unless the patch alters
+@code{[config.in]}, in which case you must regenerate @code{configure}
+via @code{make configure} (which just runs @code{autoconf}).
@node The Wine Project, , Installation, Top
@@ -1842,7 +1848,7 @@
emulator, they won't.
You therefore have to access all functions and data types by their full
-names, with the proper suffix explicitely appended. In Wine, the 16 bit
+names, with the proper suffix explicitly appended. In Wine, the 16 bit
and 32 bit versions of the functions are distinct entities, which might
(theoretically) show a completely different behaviour. They may even
call each other (and they will quite frequently).
@@ -1858,7 +1864,20 @@
@section Creating patches
@xref{Applying patches}, for instructions on applying patches.
-FIXME: how to create patches
+Patches are created with the program @code{diff}. You need a copy
+of clean source tree to diff against. The @samp{-u} option, to create
+unified diffs, is popular but not obligatory.
+For changes to a single file,
+@code{diff -u wine990101/windows/win.c mywine/windows/win.c > win_patch}
+is sufficient.
+To generate a complete diff between your tree and the distribution,
+use @code{diff -uR wine990101 mywine}.
+
+This assumes that the original distribution and your personal tree
+have the same parent directory, from which you make the diff.
+This ensures a consistent format for the diffs, which in turn
+is necessary so that they can be applied consistently as described in
+@xref{Applying patches}.
@node Adding Documentation, File names, Creating patches, The Wine Project
@section Adding Documentation
