Commit fa5fe429 authored by Zygo Blaxell's avatar Zygo Blaxell Committed by Alexandre Julliard

Fixed typos.

parent b12e72d6
...@@ -72,7 +72,7 @@ Debugging channels ...@@ -72,7 +72,7 @@ Debugging channels
Also, we divide the debugging messages on a component basis. Each Also, we divide the debugging messages on a component basis. Each
component is assigned a debugging channel. The identifier of the 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 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: Examples of debugging channels:
reg, updown, string reg, updown, string
...@@ -248,7 +248,7 @@ IMPORTANT NOTE: ...@@ -248,7 +248,7 @@ IMPORTANT NOTE:
reason, please try not to use it. However, if you need to output a line 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 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 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: then follow the following guidelines:
-- wrap calls to dsprintf with a -- wrap calls to dsprintf with a
if(YYY(xxx)) if(YYY(xxx))
...@@ -416,10 +416,10 @@ use : to separate categories. ...@@ -416,10 +416,10 @@ use : to separate categories.
* try to avoid the style: * try to avoid the style:
FIXME(xxx, FIXME(xxx,
"(fd: %d, file: %s): stub\n", fd, name); "(fd=%d, file=%s): stub\n", fd, name);
but use: 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 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, FIXME but in the first case there is no additional information available,
......
...@@ -312,16 +312,29 @@ Call KERNEL.52: FREEPROCINSTANCE(0x02cf00ba) ret=01f7:1460 ds=01ff ...@@ -312,16 +312,29 @@ Call KERNEL.52: FREEPROCINSTANCE(0x02cf00ba) ret=01f7:1460 ds=01ff
Ret KERNEL.52: FREEPROCINSTANCE() retval=0x0001 ret=01f7:1460 ds=01ff 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 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. I think that the call to MessageBox() in this example is _not_ caused
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: 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(): Offset 1056 is _very_ close to the return address of FREELIBRARY():
Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff 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 Provided that segment 0x0004 is indeed
disassemble the part that caused the error. We just have to find the address of segment 0x1cf, we now we can use IDA (available at
the call to FreeLibrary(). Some lines before that the runtime error occurred. ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip)
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). 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 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 breakpoint at a certain location which is not yet available as the
......
...@@ -21,7 +21,7 @@ BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL, ...@@ -21,7 +21,7 @@ BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL,
} }
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 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 the internal or the external DLL. If you just call the function you will get
......
...@@ -174,10 +174,10 @@ put: 05 8f ...@@ -174,10 +174,10 @@ put: 05 8f
put: 84 8f put: 84 8f
wait: ff wait: ff
From this it is easy to see that put routine is oftern gouped together in five From this it is easy to see that put routine is often grouped together in five
sucessive calls sending information to the scanner. Once these are understood 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 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 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 series of scans varying only one parameter between them, so you can
discover how to set the various parameters for the scanner. discover how to set the various parameters for the scanner.
......
...@@ -34,7 +34,7 @@ What needs to be redone: ...@@ -34,7 +34,7 @@ What needs to be redone:
- File functions, - File functions,
- I/O access (do it!), - I/O access (do it!),
- Communication (modem), - 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?), - 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), - move X functions in some files (and make a wrapper, to use PM instead latter),
- return right CPU type, - return right CPU type,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment