VMPatcher - written by: Gerardo Richarte (gera@COREST.COM)

* File in the attached code, modify (if needed) VMPatcher class >>
#vmFileName to point to your VVM31W.DLL and #vmFileNewName to point to
desired output file name.
* Do " VMPatcher new applyAll "
* See if you got messages in the Transcript, they should look like
the following,offsets may vary:

patching at offset 1EB2B
patching at offset 1EB76

This are the offsets in the file (.dll) where the patch was applied.

* Exit VSE (no need to save) and rename the new file to the original
file name (save the original "just in case")

Now, when you enter again VSE everything should work as it always did,
but the bug will be fixed.

*How does it work?*

Two parts, VMPatcher and the patch itself.

VMPatcher is just a framework for releasing patches to the VM, we hope
we'll all benefit from this and we also hope to evolve it as the
community uses it. Let's see what happens.

Notice that it uses a full match for the code to replace, and enforces
same size for original and patched code, this two invariants (while we
can enforce them) should reduce the risk of bogus patching.

*The patch for Manfred's hash bug*:

We first played a little bit around with the assembly to make space for
3 extra bytes, with no change in functionality (if you pay attention the
trick is in first shifting ecx right and multiplying it by 2, instead of
clearing its lower bit).

With this three extra bytes we changed all memory accesses from dwords
to words, using movzx (zero extend) where necessary.

*Additional thoughts*:

We could think that accessing memory in words, instead of bytes, may
still open the door for a similar bug, but we think that's not the case,
as Objects are always aligned to 4 in memory and the lowest bit is
cleared before accessing.

    hope this helps you and opens the door for more contributions like this!

    richie



