for the record, my ole32 binary tree search patch is correct

[Vincent Povirk]

I sent the following patch recently:

commit ee6856d874d687c4504914e61bcde3e6b8823bca
Author: Vincent Povirk <madewokherd at gmail.com>
Date:   Fri Oct 23 13:57:42 2009 -0500

    ole32: Don't use IEnumSTATSTG to search for elements of storages.

    We use it to do a linear search of a binary tree, which is overkill.
    Replace it with a simple binary search.

It was accepted and caused this bug:
http://bugs.winehq.org/show_bug.cgi?id=20477

It actually turned out that the mistake was in a previous patch, but
it didn't matter for reading files until we started to depend on the
tree to be valid. Nonetheless, I've done a test to make sure we can
really rely on the binary trees in storage files to be valid.

I wrote two programs: one that reads the directory entries of a
storage file and prints some information to stdout (useful for
debugging), and one that swaps the left and right child of every
directory entry, corrupting the trees in the file.

It turns out that corrupting an msi file in this way makes it fail on
both windows and on wine (although it crashes on wine; msi's error
handling code is broken). Running the program again (thus swapping the
children back to their original, correct position) makes it work.

However, on an older version of Wine without my change, the corrupted
msi file loads fine.

This means that Windows does depend on the tree in a storage file to
be correct, and Wine's behavior is now closer to Windows, even though
it now fails in some cases when it used to succeed.

(I think that current Wine without the fix for bug 20477 will load
only the corrupted files, but I didn't test this.)

I've attached my test programs so they're in the public record.

-- 
Vincent Povirk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corrupt_storage_file.py
Type: text/x-python
Size: 1595 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20091027/47a75ec4/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: read_storage_directory.py
Type: text/x-python
Size: 1581 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20091027/47a75ec4/attachment-0001.py>