Exception Handling: More Compatible With NT To Satisfy Shrinker
rob at codeweavers.com
Mon Oct 31 14:05:34 CST 2005
Shrinker does a number of things that depend on the layout of
instructions in the exception handler:
1. It delibrately causes an exception to transfer execution to its
2. It retrieves the return address from the stack.
3. It calls ReadProcessMemory to read the 8 bytes around the call to the
handler (starting at movl 24(%ebp), %ecx and ending on the first byte of
4. It looks at the "call *%ecx" instruction and if isn't exactly this,
then it fails with "Dispatcher Initialisation Error 03".
5. It looks at the prefix to the "movl 24(%ebp),%ecx" and if it isn't a
move instruction it fails as above.
6. It looks at the prefix to the "movl %fs:(0),%esp" instruction and if
it isn't prefixed with %fs then it fails as above.
7. It replaces the instructions in (4) and (5) with a jump to its code
using a WriteProcessMemory call.
8. It uses GetProcAddress(hntdll, "LdrAccessResource") and scans the
first few bytes of the function for a call instruction. If it doesn't
find one then it fails with "Dispatcher Initialisation Error 13".
9. It replaces the instruction in (8) again with a call to its code
10. It then runs successfully.
This patch attempts to get Shrinker working up to (7). A further patch
will make LdrAccessResource compatible with what it needs and hopefully
get all Shrinker'd apps running (it got the one I was working on running).
Make the call exception handler function more compatible with NT and
with what Shrinker expects.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3313 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20051031/8e1abefb/shrinker1.diff
More information about the wine-patches