Fixed typos.
diff --git a/documentation/debug-msgs b/documentation/debug-msgs
index eacf370..69650d6 100644
--- a/documentation/debug-msgs
+++ b/documentation/debug-msgs
@@ -72,7 +72,7 @@
Also, we divide the debugging messages on a component basis. Each
component is assigned a debugging channel. 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.
+reserved word like int or static.
Examples of debugging channels:
reg, updown, string
@@ -248,7 +248,7 @@
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,
+ interface (when it will become available). So, if you need to use it,
then follow the following guidelines:
-- wrap calls to dsprintf with a
if(YYY(xxx))
@@ -416,10 +416,10 @@
* try to avoid the style:
FIXME(xxx,
- "(fd: %d, file: %s): stub\n", fd, name);
+ "(fd=%d, file=%s): stub\n", fd, name);
but use:
- FIXME(xxx, "(fd: %d, file: %s): stub\n", fd, name);
+ FIXME(xxx, "(fd=%d, file=%s): stub\n", fd, name);
The reason is that if you want to grep for things, you would search for
FIXME but in the first case there is no additional information available,
diff --git a/documentation/debugging b/documentation/debugging
index 72a57db..47a0ff9 100644
--- a/documentation/debugging
+++ b/documentation/debugging
@@ -312,16 +312,29 @@
Ret KERNEL.52: FREEPROCINSTANCE() retval=0x0001 ret=01f7:1460 ds=01ff
Call USER.1: MESSAGEBOX(0x0000,0x01ff1246 "Runtime error 219 at 0004:1056.",0x00000000,0x1010) ret=01f7:2160 ds=01ff
-I think that the call to MessageBox() in this example is _not_ caused by a wrong result value of some previously executed function (it's happening quite often like that), but instead the messagebox complains about a runtime error at 0x0004:0x1056.
-As the segment value of the address is only "4", I think that that is only an internal program value. But the offset address reveals something quite interesting:
+I think that the call to MessageBox() in this example is _not_ caused
+by a wrong result value of some previously executed function (it's
+happening quite often like that), but instead the messagebox complains
+about a runtime error at 0x0004:0x1056.
+
+As the segment value of the address is only "4", I think that that is
+only an internal program value. But the offset address reveals something
+quite interesting:
+
Offset 1056 is _very_ close to the return address of FREELIBRARY():
Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
^^^^
-Provided that segment 0x0004 is indeed segment 0x1cf, we now we can use IDA (available at ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip) to
-disassemble the part that caused the error. We just have to find the address of
-the call to FreeLibrary(). Some lines before that the runtime error occurred.
-But be careful ! In some cases you don't have to disassemble the main program, but instead some DLL called by it in order to find the correct place where the runtime error occurred. That can be determined by finding the origin of the segment value (in this case 0x1cf).
+Provided that segment 0x0004 is indeed
+segment 0x1cf, we now we can use IDA (available at
+ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip)
+to disassemble the part that caused the error. We just have to find
+the address of the call to FreeLibrary(). Some lines before that the
+runtime error occurred. But be careful ! In some cases you don't have
+to disassemble the main program, but instead some DLL called by it in
+order to find the correct place where the runtime error occurred. That
+can be determined by finding the origin of the segment value (in this
+case 0x1cf).
c) If you have created a relay file of some crashing program and want to set a
breakpoint at a certain location which is not yet available as the
diff --git a/documentation/internal-dll b/documentation/internal-dll
index d90b70b..02b891f 100644
--- a/documentation/internal-dll
+++ b/documentation/internal-dll
@@ -21,7 +21,7 @@
}
-2. Using functions from other build-in DLL's
+2. Using functions from other built-in DLL's
--------------------------------------------
The problem here is, that you can't know if you have to call the function from
the internal or the external DLL. If you just call the function you will get
diff --git a/documentation/ioport-trace-hints b/documentation/ioport-trace-hints
index 9c6521a..ae34193 100644
--- a/documentation/ioport-trace-hints
+++ b/documentation/ioport-trace-hints
@@ -174,10 +174,10 @@
put: 84 8f
wait: ff
-From this it is easy to see that put routine is oftern gouped together in five
-sucessive calls sending information to the scanner. Once these are understood
+From this it is easy to see that put routine is often grouped together in five
+successive calls sending information to the scanner. Once these are understood
it should be possible to process the logs further to show the higher level
-routines in an easy to see format. Once the higest level format that you
+routines in an easy to see format. Once the highest level format that you
can derive from this process is understood, you then need to produce a
series of scans varying only one parameter between them, so you can
discover how to set the various parameters for the scanner.
diff --git a/documentation/wine_os2 b/documentation/wine_os2
index f66fb71..8a78443 100644
--- a/documentation/wine_os2
+++ b/documentation/wine_os2
@@ -34,7 +34,7 @@
- File functions,
- I/O access (do it!),
- Communication (modem),
-- Interrupt (if int unknow, call current RealMode one...),
+- Interrupt (if int unknown, call current RealMode one...),
- verify that everything is thread safe (how does Win95/NT handle multi-thread?),
- move X functions in some files (and make a wrapper, to use PM instead latter),
- return right CPU type,
