handling IUnknown/IRemUnknown for (outproc) objects

[Jeroen Janssen]

>>After last weeks discussion on the "unhandled interface" message in
>>CFProxy_QueryInterface I was getting, we concluded (if I'm correct) that
>>this is part of the "IRemUnknown" handling that is not (yet) implemented
>>correctly in the wine CVS tree.
>
> I can't work out how IUnknown marshalling is getting delegated to the
> IClassFactory marshaller, but IUnknown marshalling should be a special
> case in StdMarshalImpl_UnmarshalInterface.
>
>>I'm trying to figure out exactly where in the (OLE) code, this should be
>>handled. If someone could point me in the right direction I would
>>appreciate it very much.
>
> Does this patch help?

No, with this patch it does not work yet.

I will try to have a more detailed look at the path itself tonight and
hopefully understand more about how it should work.

In the mean time, I have attached a small zipfile with the server & client
logging from the lab7 test program I send you and Mike (running on CVS as
of today + your patch).

If you want an "easy" testcase to see for yourself if the patch works, you
can use the original test programs I send you(that zipfile contained both
src and executables that you can run with wine).

On a side note I noticed there are no 'unittest' in the ole32 directory.
This sounds like something that could be usefull to have in there
(although I'm not sure what the best way is to put it in the wine tree).
Note though that I didn't write the original testprogram, so we probably
would need to write some from scratch to be sure.

 >>I think it would also be helpfull if there was some "fixme" logging so
>>other people can also see if they hit upon the same problem (since it
>> took
>>a while to finally figure out the problem).
>
> I suppose I could put a fixme in the above mentioned function that will
> alert you to this specific problem, but there are so many problems with
> the current code that putting in fixme's for all of them would take ages
> and I'd much rather prefer to be fixing them.

I agree that fixing things is the preferred way to go, however whenever
someone 'hits' a problem (like this one), it would be helpfull to point
slightly in the right direction on where to look for the problem/a
solution.

A 'fixme' in the logging might also make it easier to trigger other people
(than the original developer) to try and help & fix, because it's easier
to see that something is not implemented (correctly) yet.

If I run a program and I don't see 'fixme' logging for items that are
(known to be) broken/missing, it's harder for me to see/understand and
have a look at it, so I can help with it.

On the other hand, I do understand that people want to focus on the
'important' things, instead of having to walk through all the (wine) code
and put a fixme/todo statement where needed.

> If you'd like a list things not implemented in our current COM
implementation then please let
> me know and I'll send one to you.

That would be nice to have indeed (I don't know if other people on this
list are interested in it too).
---
Jeroen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lab7_client_server.zip
Type: application/zip
Size: 2170 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040726/5f6ecc3a/lab7_client_server.zip