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

[Dmitry Timoshkov]

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.

> But I'm sure you can find other ways,
> like using a file in line-buffered mode or things like that. Think about
> it some more.

That would help with avoding a mutex, but mutex is a tiny part of the test.

-- 
Dmitry.