[PATCH 3/4] urlmon/tests: Add tests for synchronous vs asynchronous binding.

Misha Koshelev mk144210 at bcm.edu
Mon Aug 6 20:17:50 CDT 2007


Here are the tests. The S_OK being returned sometimes from asynchronous binding nad not
MK_S_ASYNCHORNOUS and exactly when this happens I investigated quite thoroughly. It is fairly
easy to elicit this behavior by swithcing WINE_ABOUT_URL to the posttest URL from protocol.c.
I also used some not-ready-for-git emualted http tests Jacek sent me to track down exactly
what the point is when MK_S_ASYNCHRONOUS vs S_OK is being sent (the two options being whether
we have finished the download, i.e., OnStoppedBinding has been called, or whether we have received
some data, i.e., OnDataAvailable has been called); turned out to be the latter, which is also nice
as it makes the previous patch smaller (the existing git code already checks for init_buf and
returns S_OK or MK_S_ASYNCHRONOUS appropriately). I am still working on getting a test that tickles
this dichotomy going, but it is a little complicated as it tickles some other stuff (basically
native staying ocnnected to a server, etc).

Btw, in my tests with Jacek's emulated http test I also tested whether the behavior that is already
in git that I submitted as far as init_buf being set if any bytes are retrieved is correct (by way
of looking at when S_OK vs MK_S_ASYNCHRONOUS is returned; also I already knew what was in git before
was wrong as it caused skipping of data on a real application, i.e., Vector NTI). Turns out that
it is largely correct, except native wants 256 bytes or more (i.e., not 255) no matter whether E_PENDING
or S_OK is returned from IINternetProtocol_Read; I believe this is the minimum it wants for a MIME
type. However, since native behavior following not getting 256 bytes is also different from ours currently
(no OnDataAvailable or any notifications of data are sent if less than 256 bytes are retrieved by the
first clal to IInternetProtocol_Read), I am not correcting this at the time, as it would prob be a little
involved and I can't imagine any app that depends on this behavior (famous last words I'm sure).
---
 dlls/urlmon/tests/url.c |   36 ++++++++++++++++++++++++++++++------
 1 files changed, 30 insertions(+), 6 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 410345a6da6ac5cd6555b8cf3cd135c84c863aa3.diff
Type: text/x-patch
Size: 3798 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20070806/f5978c45/410345a6da6ac5cd6555b8cf3cd135c84c863aa3.bin


More information about the wine-patches mailing list