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