ole32: Add a basic OLE client/server test suite. Take 2.

Alexandre Julliard julliard at winehq.org
Wed Jun 5 05:06:20 CDT 2013

Dmitry Timoshkov <dmitry at baikal.ru> writes:

> Alexandre Julliard <julliard at winehq.org> wrote:
>> >> Launching the server in responce to say CoCreateInstance is out of our
>> >> control, happens behind the scene, and the server runs in its own console,
>> >> so it's impossible make a simple redirection by passing in/out handles to
>> >> CreateProcess. So using a pipe and a passing its write end via shared memory
>> >> seems like an obvious solution. Without a mutex client and server output is
>> >> messed up under Windows. Redefining trace allows to write to the pipe in
>> >> the server and synchronize server output on the client side.
>> >
>> > Did my explanation help with understanding the reasons behind the test
>> > implementation details?
>> >
>> >> If you have a suggestion how to simplify all of this please let me know.
>> >
>> > It's pretty hard to make any progress without a reponse.
>> The easy way is to not print traces in the server, you shouldn't need
>> that once your test is working.
> The whole complexity of the test is because I really need to see what
> actions on the server side a client request does produce. That's the actual
> reason of the test, without it the test doesn't make sense. I need to see
> output of client and server in order to see why a pretty complex client/
> server COM application fails to connect to its components. My test shows
> that for instance CoCreateInstance on the client side leads to interface
> queries on the server side from the class factory instead of the object,
> without my test I wouldn't figure that out.

If it's a test app meant to investigate the behavior, that's fine, but
then there's no reason to put it in the test suite.

Just use it to figure out the behavior, and then write a proper test
that checks for that behavior using ok() and the like. At that point you
don't need traces, because the test is supposed to run unattended and
detect failures on its own, without requiring anybody to look at a

Alexandre Julliard
julliard at winehq.org

More information about the wine-devel mailing list