Out of process COM objects & Installshield v6

[Sander van Leeuwen]

Hi,

What's the current state of OOP COM objects in Wine?
I've noticed a lot of related changes, but have yet to find an InstallShield 6
installer that works. (I did copy the stdole*.tlb files to the windows & system directory)

After porting the OLE changes to Odin, I tried the Java 1.4 installer.
It fails with error 0x80070057 (CoMarshalInterface; failed to marshal interface)
Trying the same installer in Wine (built from latest CVS) results in the same error
There's a fixme for NdrDllRegisterProxy for the same GUID that fails in 
CoMarshallInterface. Perhaps that's the cause.

Before I start debugging this, I'd like to know if it is supposed to work at all.

Thanks,

Sander

[Marcus Meissner]

On Sun, Feb 24, 2002 at 06:21:28PM +0100, Sander van Leeuwen wrote:
> Hi,
>
> What's the current state of OOP COM objects in Wine?
> I've noticed a lot of related changes, but have yet to find an InstallShield 6
> installer that works. (I did copy the stdole*.tlb files to the windows & system directory)
>
> After porting the OLE changes to Odin, I tried the Java 1.4 installer.
> It fails with error 0x80070057 (CoMarshalInterface; failed to marshal interface)
> Trying the same installer in Wine (built from latest CVS) results in the same error
> There's a fixme for NdrDllRegisterProxy for the same GUID that fails in 
> CoMarshallInterface. Perhaps that's the cause.
>
> Before I start debugging this, I'd like to know if it is supposed to work at all.

If you do -debugmsg +olerelay, you see that it does several interprocess
calls.

I am not sure when and how this NdrDllRegisterProxy appeared, but I am
experiencing the same problem.

Oh and debugging might not really help, support for proxies registered with
NdrDllRegisterProxy needs to get implemented. :/

Ciao, Marcus

[Sander van Leeuwen]

On Mon, 25 Feb 2002 08:44:03 +0100, Marcus Meissner wrote:
> > After porting the OLE changes to Odin, I tried the Java 1.4 installer.
> > It fails with error 0x80070057 (CoMarshalInterface; failed to marshal interface)
> > Trying the same installer in Wine (built from latest CVS) results in the same error
> > There's a fixme for NdrDllRegisterProxy for the same GUID that fails in 
> > CoMarshallInterface. Perhaps that's the cause.
> >
> > Before I start debugging this, I'd like to know if it is supposed to work at all.
>
> If you do -debugmsg +olerelay, you see that it does several interprocess
> calls.

Yes, I noticed that too. A few processes are launched.
> I am not sure when and how this NdrDllRegisterProxy appeared, but I am
> experiencing the same problem.

Neither do I. Not sure if we need to implement it at all. As you said, the dreamweaver
install used to work. And Transgaming hasn't implemented this function either.

If you know when you checked this installer the last time, then we can look for the regression.
> Oh and debugging might not really help, support for proxies registered with
> NdrDllRegisterProxy needs to get implemented. :/

Are the rpcrt4 functions documented anywhere? A quick search on MSDN
didn't give any hits. (NdrDllRegisterProxy nor DllRegisterProxy)

Sander

[Gerhard W. Gruber]

Sander van Leeuwen wrote:
> Are the rpcrt4 functions documented anywhere? A quick search on MSDN
> didn't give any hits. (NdrDllRegisterProxy nor DllRegisterProxy)

rcprt4 functions are not documented anywhere. Not even the names of the
functions are to be found.

[Ove Kaaven]

On Mon, 25 Feb 2002, Sander van Leeuwen wrote:
> > I am not sure when and how this NdrDllRegisterProxy appeared, but I am
> > experiencing the same problem.
>
> Neither do I. Not sure if we need to implement it at all. As you said, the dreamweaver
> install used to work. And Transgaming hasn't implemented this function either.

The reason it works for us without NdrDllRegisterProxy is this (pretty
bad and rejectable) patch:

--- dlls/oleaut32/typelib.c   2002/01/29 17:05:11     1.61
+++ dlls/oleaut32/typelib.c   2002/02/25 10:09:27
@@ -457,7 +457,11 @@
                    TRACE_(typelib)("guid=%s, flags=%04x\n",
                                    debugstr_guid(&tattr->guid),
                                    tattr->wTypeFlags);
-                   if (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION) {
+#define INSTALLSHIELD_HACK
+#ifndef INSTALLSHIELD_HACK
+                   if (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION)
+#endif
+                   {
                        /* register interface<->typelib coupling */
                        StringFromGUID2(&tattr->guid, guid, 80);
                        guidA = HEAP_strdupWtoA(GetProcessHeap(), 0, guid);

[Marcus Meissner]

On Mon, Feb 25, 2002 at 01:11:16PM +0100, Ove Kaaven wrote:
> On Mon, 25 Feb 2002, Sander van Leeuwen wrote:
> > > I am not sure when and how this NdrDllRegisterProxy appeared, but I am
> > > experiencing the same problem.
> >
> > Neither do I. Not sure if we need to implement it at all. As you said, the dreamweaver
> > install used to work. And Transgaming hasn't implemented this function either.
>
> The reason it works for us without NdrDllRegisterProxy is this (pretty
> bad and rejectable) patch:

Hmm, I think we can pass it that one time.

With this patch it works again.

Alexandre, please apply :)

Ciao, Marcus
> --- dlls/oleaut32/typelib.c   2002/01/29 17:05:11     1.61
> +++ dlls/oleaut32/typelib.c   2002/02/25 10:09:27
> @@ -457,7 +457,11 @@
>                     TRACE_(typelib)("guid=%s, flags=%04x\n",
>                                     debugstr_guid(&tattr->guid),
>                                     tattr->wTypeFlags);
> -
>               if (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION) {
>
> +#define INSTALLSHIELD_HACK
> +#ifndef INSTALLSHIELD_HACK
> -
>               if (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION)
>
> +#endif
> -
>               {
>                   /* register interface<->typelib coupling */
>                   StringFromGUID2(&tattr->guid, guid, 80);
>                   guidA = HEAP_strdupWtoA(GetProcessHeap(), 0, guid);

[Ove Kaaven]

On Mon, 25 Feb 2002, Marcus Meissner wrote:
> I am not sure when and how this NdrDllRegisterProxy appeared, but I am
> experiencing the same problem.
>
> Oh and debugging might not really help, support for proxies registered with
> NdrDllRegisterProxy needs to get implemented. :/

I've been working on this as part of my COM restructure. I've implemented
NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd
like to release it to WineHQ, but Gav still wants something in exchange.
(If we can't get money, we'll consider releasing it if a Wine developer
agrees to work on stuff that may be useful for us, like an ALSA driver,
and/or a Wine kernel module to speed up synchronization primitives (like
mutexes), or maybe more DirectShow work, or something of the kind.)

[Dan Kegel]

Ove Kaaven wrote:
> I've been working on this as part of my COM restructure. I've implemented
> NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd
> like to release it to WineHQ, but Gav still wants something in exchange.
> (If we can't get money, we'll consider releasing it if a Wine developer
> agrees to work on stuff that may be useful for us, like an ALSA driver,
> and/or a Wine kernel module to speed up synchronization primitives (like
> mutexes), or maybe more DirectShow work, or something of the kind.)

Cool.  I bet something could be worked out.

As you know, David Howells did a bunch of work on a kernel module last year 
( see
http://marc.theaimsgroup.com/?l=linux-kernel&m=101344885113906&w=2
http://cvs.winehq.com/cvsweb/kernel-win32/
http://marc.theaimsgroup.com/?l=wine-devel&m=98628491209432&w=2 )

I wonder if Red Hat would be willing to have David bring his
wine kernel module up to date in exchange for Transgaming
contributing your COM work?

- Dan