Problem with InstallShield (Was Re: [Bug 629] Changed - Problem with InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

[Andriy Palamarchuk]

A problem with InstallShield was reported to Bugzilla.
InstallShield support is very critical for the project
and I decided to announce this bug on wine-devel.

http://bugs.winehq.com/show_bug.cgi?id=629

I do not have time to do deep investigation of the
issue. Please, take ownership of the bug if you start
to work on it.

Thanks,
Andriy Palamarchuk

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[Ove Kaaven]

On Mon, 6 May 2002, Andriy Palamarchuk wrote:
> A problem with InstallShield was reported to Bugzilla.
> InstallShield support is very critical for the project
> and I decided to announce this bug on wine-devel.
>
> http://bugs.winehq.com/show_bug.cgi?id=629
>
> I do not have time to do deep investigation of the
> issue.

Oh, well, it's a known problem. It's not easily fixable in the official
Wine tree without, say, half a man-year of work. There's an ugly hack (an
one-liner) to make it work (in conjunction with a stdole32.tlb file from
real Windows), but since Alexandre never yet applied this hack to the
official Wine (though it might be in CodeWeavers Crossover), I presume he
never will before there's a "real" solution (which will take man-months of
work, and writing an IDL compiler to let us generate our own .tlb file
instead of using the native one, maybe another month or two).

After the WineX 2.0 release, I've once again been working on completing my
version of the real solution (I'm close to have it working now), but of
course, Gav probably still wants a fair chunk of LGPL-ed code relicensed
in exchange...

[Andriy Palamarchuk]

--- Ove Kaaven  wrote:
> On Mon, 6 May 2002, Andriy Palamarchuk wrote:
> > A problem with InstallShield was reported to
>
> Bugzilla.
> > InstallShield support is very critical for the
>
> project
> > and I decided to announce this bug on wine-devel.
> >
> > http://bugs.winehq.com/show_bug.cgi?id=629

[... skipped ...]
> Oh, well, it's a known problem. It's not easily
> fixable in the official
> Wine tree without, say, half a man-year of work.
> There's an ugly hack (an
> one-liner) to make it work (in conjunction with a
> stdole32.tlb file from
> real Windows), but since Alexandre never yet applied
> this hack to the
> official Wine (though it might be in CodeWeavers
> Crossover), I presume he
> never will before there's a "real" solution (which
> will take man-months of
> work, and writing an IDL compiler to let us generate
> our own .tlb file
> instead of using the native one, maybe another month
> or two).
>
> After the WineX 2.0 release, I've once again been
> working on completing my
> version of the real solution (I'm close to have it
> working now), but of
> course, Gav probably still wants a fair chunk of
> LGPL-ed code relicensed
> in exchange...

Ove, is this the same issue as described in bug 423
"Out of Process COM"?
http://bugs.winehq.com/show_bug.cgi?id=423

If you don't mind I'll add your comments to that bug.

Andriy Palamarchuk

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[Ove Kaaven]

On Mon, 6 May 2002, Andriy Palamarchuk wrote:
> Ove, is this the same issue as described in bug 423
> "Out of Process COM"?
> http://bugs.winehq.com/show_bug.cgi?id=423

Almost, except Marcus already implemented this Out of Process COM in
official Wine, it's just that it isn't a full implementation, only enough
to make InstallShield work with some hacks and files from real Windows.
The full (i.e. "clean and hack-free", at least to the degree that MS's
implementation is clean and hack-free, which it isn't) implementation is
what I'm working on.

[Uwe Bonnes]

> > > > > "Ove" == Ove Kaaven  writes:

Ove> Oh, well, it's a known problem. It's not easily fixable in the
    Ove> official Wine tree without, say, half a man-year of work. There's
    Ove> an ugly hack (an one-liner) to make it work (in conjunction with a
    Ove> stdole32.tlb file from real Windows), but since Alexandre never yet
    Ove> applied this hack to the official Wine (though it might be in
    Ove> CodeWeavers Crossover), I presume he never will before there's a
    Ove> "real" solution (which will take man-months of work, and writing an
    Ove> IDL compiler to let us generate our own .tlb file instead of using
    Ove> the native one, maybe another month or two).

Could you please republish that hack?

And Alexandre could perhaps reconsider.

Ove> After the WineX 2.0 release, I've once again been working on
    Ove> completing my version of the real solution (I'm close to have it
    Ove> working now), but of course, Gav probably still wants a fair chunk
    Ove> of LGPL-ed code relicensed in exchange...

Bye

[Michael Cardenas]

yes, I'd like to know what the hack was also!

On Mon, May 06, 2002 at 09:37:02PM +0200, Uwe Bonnes wrote:
> > > > > > "Ove" == Ove Kaaven  writes:
> Ove> official Wine tree without, say, half a man-year of work. There's
> Ove> an ugly hack (an one-liner) to make it work (in conjunction with a
> Ove> stdole32.tlb file from real Windows), but since Alexandre never yet

...
> Could you please republish that hack?
>
> And Alexandre could perhaps reconsider.

[Marcus Meissner]

On Mon, May 06, 2002 at 12:54:14PM -0400, Michael Cardenas wrote:
> yes, I'd like to know what the hack was also!
>
> On Mon, May 06, 2002 at 09:37:02PM +0200, Uwe Bonnes wrote:
> > > > > > > "Ove" == Ove Kaaven  writes:
> > Ove> official Wine tree without, say, half a man-year of work. There's
> > Ove> an ugly hack (an one-liner) to make it work (in conjunction with a
> > Ove> stdole32.tlb file from real Windows), but since Alexandre never yet
>
> ...
> > Could you please republish that hack?
> >
> > And Alexandre could perhaps reconsider.

Basically the "1 ||" below is enough. Just more debug output in here.

Ciao, Marcus

Index: typelib.c
===================================================================
RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v
retrieving revision 1.65
diff -u -r1.65 typelib.c
--- typelib.c	1 May 2002 18:13:18 -0000	1.65
+++ typelib.c	6 May 2002 18:45:13 -0000
@@ -468,10 +468,36 @@
    	TYPEATTR *tattr = NULL;
    	ITypeInfo_GetTypeAttr(tinfo, &tattr);
    	if (tattr) {
-		    TRACE_(typelib)("guid=%s, flags=%04x\n",
+		    TRACE_(typelib)("guid=%s, flags=%04x (",
    			    debugstr_guid(&tattr->guid),
    			    tattr->wTypeFlags);
-		    if (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION) {
+		    if (TRACE_ON(typelib)) {
+#define XX(x) if (TYPEFLAG_##x & tattr->wTypeFlags) MESSAGE(#x"|");
+			XX(FAPPOBJECT);
+			XX(FCANCREATE);
+			XX(FLICENSED);
+			XX(FPREDECLID);
+			XX(FHIDDEN);
+			XX(FCONTROL);
+			XX(FDUAL);
+			XX(FNONEXTENSIBLE);
+			XX(FOLEAUTOMATION);
+			XX(FRESTRICTED);
+			XX(FAGGREGATABLE);
+			XX(FREPLACEABLE);
+			XX(FDISPATCHABLE);
+			XX(FREVERSEBIND);
+			XX(FPROXY);
+#undef XX
+			MESSAGE("\n");
+		    }
+		    /*
+		     * FIXME: The 1 is just here until we implement rpcrt4
+		     *        stub/proxy handling. Until then it helps IShield
+		     *        v6 to work.
+		     */
+		    if (1 || (tattr->wTypeFlags & TYPEFLAG_FOLEAUTOMATION))
+		    {
    		/* register interface<->typelib coupling */
    		StringFromGUID2(&tattr->guid, guid, 80);
    		guidA = HEAP_strdupWtoA(GetProcessHeap(), 0, guid);

[Marcus Meissner]

On Mon, May 06, 2002 at 09:37:02PM +0200, Uwe Bonnes wrote:
> > > > > > "Ove" == Ove Kaaven  writes:
> Ove> Oh, well, it's a known problem. It's not easily fixable in the
> Ove> official Wine tree without, say, half a man-year of work. There's
> Ove> an ugly hack (an one-liner) to make it work (in conjunction with a
> Ove> stdole32.tlb file from real Windows), but since Alexandre never yet
> Ove> applied this hack to the official Wine (though it might be in
> Ove> CodeWeavers Crossover), I presume he never will before there's a
> Ove> "real" solution (which will take man-months of work, and writing an
> Ove> IDL compiler to let us generate our own .tlb file instead of using
> Ove> the native one, maybe another month or two).
>
> Could you please republish that hack?

I have sent my version of it to Alexandre already.

Ciao, M

[Alexandre Julliard]

Ove Kaaven  writes:
> Oh, well, it's a known problem. It's not easily fixable in the official
> Wine tree without, say, half a man-year of work. There's an ugly hack (an
> one-liner) to make it work (in conjunction with a stdole32.tlb file from
> real Windows), but since Alexandre never yet applied this hack to the
> official Wine (though it might be in CodeWeavers Crossover), I presume he
> never will before there's a "real" solution (which will take man-months of
> work, and writing an IDL compiler to let us generate our own .tlb file
> instead of using the native one, maybe another month or two).

It just fell through the cracks. Marcus resent me the patch and it's
applied now.
> After the WineX 2.0 release, I've once again been working on completing my
> version of the real solution (I'm close to have it working now), but of
> course, Gav probably still wants a fair chunk of LGPL-ed code relicensed
> in exchange...

Last we heard it was to be exchanged against the ALSA driver...

[Michael Cardenas]

But does it work without that stdole32.tlb file? Does it work at all?

On Mon, May 06, 2002 at 01:13:33PM -0700, Alexandre Julliard wrote:
...
> It just fell through the cracks. Marcus resent me the patch and it's
> applied now.

[Marcus Meissner]

On Mon, May 06, 2002 at 01:25:25PM -0400, Michael Cardenas wrote:
> On Mon, May 06, 2002 at 01:13:33PM -0700, Alexandre Julliard wrote:
> > It just fell through the cracks. Marcus resent me the patch and it's
> > applied now.
>
> But does it work without that stdole32.tlb file? Does it work at all?

I just installed DreamWeaver 4 again. ;)

But yes, you would need the stdole32.tlb file.

(Not sure if you could legally download it by just downloading the DCOM pack:
        http://www.microsoft.com/com/dcom/dcom95/download.asp
)

Ciao, Marcus

[Michael Cardenas]

Hmmm... strangely, when I try to install dreamweaver4, the installer
crashes. I have stdole32.tlb (and an entire windows directory).

here's the output of +relay,+snoop, around the crash...

08d39318:Call ntdll.RtlInitAnsiString(40555444,4085fce9 "Version")
ret=40801eb3
08d39318:Ret  ntdll.RtlInitAnsiString() retval=00000008 ret=40801eb3
08d39318:Call
ntdll.RtlAnsiStringToUnicodeString(401018cc,40555444,00000000)
ret=40801ec8
08d39318:Ret  ntdll.RtlAnsiStringToUnicodeString() retval=00000000
ret=40801ec8
08d39318:Call
ntdll.NtSetValueKey(000000bc,401018cc,00000000,00000001,403885a4,00000008)
ret=40801ee5
08d39318:Ret  ntdll.NtSetValueKey() retval=00000000 ret=40801ee5
08d39318:Call ntdll.RtlFreeHeap(40330000,00000000,403885a4) ret=40801f01
08d39318:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40801f01
08d39318:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801f07
08d39318:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801f07
08d39318:Ret  advapi32.RegSetValueExA() retval=00000000 ret=4084b34f
08d39318:Call advapi32.RegCloseKey(000000bc) ret=4084b35a
08d39318:Call ntdll.NtClose(000000bc) ret=40801c3b
08d39318:Ret  ntdll.NtClose() retval=00000000 ret=40801c3b
08d39318:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801c41
08d39318:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801c41
08d39318:Ret  advapi32.RegCloseKey() retval=00000000 ret=4084b35a
08d39318:Call advapi32.RegCloseKey(000000ac) ret=4084b368
08d39318:Call ntdll.NtClose(000000ac) ret=40801c3b
08d39318:Ret  ntdll.NtClose() retval=00000000 ret=40801c3b
08d39318:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801c41
08d39318:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801c41
08d39318:Ret  advapi32.RegCloseKey() retval=00000000 ret=4084b368
08d39318:Call ntdll.RtlFreeHeap(40330000,00000000,40368574) ret=40840a7b
08d39318:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
08d39318:Call ntdll.RtlFreeHeap(40330000,00000000,4036854c) ret=408509a3
08d39318:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=408509a3
08d39318:Call ntdll.RtlFreeHeap(40330000,00000000,40368454) ret=40840a7b
08d39318:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
08d39318:Call kernel32.lstrlenW(40387688 L"Release") ret=4084084e
08d39318:Ret  kernel32.lstrlenW() retval=00000007 ret=4084084e
08d39318:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
ret=4084096b
08d39318:Ret  ntdll.RtlAllocateHeap() retval=403885a4 ret=4084096b
08d39318:Call kernel32.lstrlenW(403692c4 L"IUnknown") ret=4084084e
08d39318:Ret  kernel32.lstrlenW() retval=00000008 ret=4084084e
08d39318:Call ntdll.RtlAllocateHeap(40330000,00000000,00000016)
ret=4084096b
08d39318:Ret  ntdll.RtlAllocateHeap() retval=40368454 ret=4084096b
08d39318:Call kernel32.lstrlenW(40387688 L"Release") ret=4084084e
08d39318:Ret  kernel32.lstrlenW() retval=00000007 ret=4084084e
08d39318:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
ret=4084096b
08d39318:Ret  ntdll.RtlAllocateHeap() retval=40368474 ret=4084096b
wine: Unhandled exception, starting debugger...
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
addr 0x4027d1c7
08073b88:Ret  kernel32.WaitForSingleObject() retval=00000000
ret=004036a9
08073b88:Call kernel32.CloseHandle(00000044) ret=004036bb
08073b88:Ret  kernel32.CloseHandle() retval=00000001 ret=004036bb
08073b88:Call kernel32.CloseHandle(00000048) ret=004036c0
08073b88:Ret  kernel32.CloseHandle() retval=00000001 ret=004036c0
08073b88:Call user32.DestroyWindow(00020021) ret=004036c7
08073b88:Call x11drv.ResetSelectionOwner(00020021,00000000) ret=406796c1
08073b88:Ret  x11drv.ResetSelectionOwner() retval=01c0002b ret=406796c1
08073b88:Call x11drv.ShowWindow(00020021,00000000) ret=4067de36
08073b88:Ret  x11drv.ShowWindow() retval=00000000 ret=4067de36
08073b88:Call x11drv.ResetSelectionOwner(00020021,00000001) ret=406794df
08073b88:Ret  x11drv.ResetSelectionOwner() retval=01c0002b ret=406794df
08073b88:Call window proc 0x40658650
(hwnd=00020021,msg=WM_DESTROY,wp=00000000,lp=00000000)

could you send me your config file so I can see what dll's you're using
native/builtin?

I put in the 1 || patch and I set my config file to use the builtin
oleaut32.

thanks
      michael

On Mon, May 06, 2002 at 09:32:43PM +0200, Marcus Meissner wrote:
> On Mon, May 06, 2002 at 01:25:25PM -0400, Michael Cardenas wrote:
> > On Mon, May 06, 2002 at 01:13:33PM -0700, Alexandre Julliard wrote:
> > > It just fell through the cracks. Marcus resent me the patch and it's
> > > applied now.
> >
> > But does it work without that stdole32.tlb file? Does it work at all?
>
> I just installed DreamWeaver 4 again. ;)
>
> But yes, you would need the stdole32.tlb file.
>
> (Not sure if you could legally download it by just downloading the DCOM pack:
>         http://www.microsoft.com/com/dcom/dcom95/download.asp
> )
>
> Ciao, Marcus

[Marcus Meissner]

On Mon, May 06, 2002 at 03:08:46PM -0400, Michael Cardenas wrote:
> Hmmm... strangely, when I try to install dreamweaver4, the installer
> crashes. I have stdole32.tlb (and an entire windows directory).
>
> here's the output of +relay,+snoop, around the crash...

...
> 08d39318:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
> ret=4084096b
> 08d39318:Ret  ntdll.RtlAllocateHeap() retval=40368474 ret=4084096b
> wine: Unhandled exception, starting debugger...

Did this have my BSTR patch from yesterday applied? If yes, can you also
add -debugmsg +olerelay?

Ciao, Marcus

[Michael Cardenas]

Yes, it still crashes with your bstr patch. The first window comes up,
and the the little window in the right hand corner comes up, and there's
an image window that gets created but not drawn.

If it run it in winedbg, it crashes in TOOLBAR_testImageExist,
toolbar.c:370, wih read access to 0x00000000. It seems to be using the
native ole32.dll.

Here's the output...

084040a8:RET  ole32.254: StringFromGUID2() retval = 00000027
ret=4084b325
084040a8:Call kernel32.lstrlenW(40555620
L"{00020430-0000-0000-C000-000000000046}") ret=4084b356
084040a8:Ret  kernel32.lstrlenW() retval=00000026 ret=4084b356
084040a8:Call
advapi32.RegSetValueExW(000000bc,00000000,00000000,00000001,40555620,0000004c)
ret=4084b371
084040a8:Call kernel32.GetVersion() ret=40801d35
084040a8:Ret  kernel32.GetVersion() retval=c0000004 ret=40801d35
084040a8:Call ntdll.RtlInitUnicodeString(40555448,00000000) ret=40801d9a
084040a8:Ret  ntdll.RtlInitUnicodeString() retval=40555434 ret=40801d9a
084040a8:Call
ntdll.NtSetValueKey(000000bc,40555448,00000000,00000001,40555620,0000004e)
ret=40801dae
084040a8:Ret  ntdll.NtSetValueKey() retval=00000000 ret=40801dae
084040a8:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801db4
084040a8:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801db4
084040a8:Ret  advapi32.RegSetValueExW() retval=00000000 ret=4084b371
084040a8:Call kernel32.lstrlenA(40555574 "1.0") ret=4084b377
084040a8:Ret  kernel32.lstrlenA() retval=00000003 ret=4084b377
084040a8:Call advapi32.RegSetValueExA(000000bc,4085fd29
"Version",00000000,00000001,40555574,00000003) ret=4084b38f
084040a8:Call kernel32.GetVersion() ret=40801de1
084040a8:Ret  kernel32.GetVersion() retval=c0000004 ret=40801de1
084040a8:Call ntdll.RtlMultiByteToUnicodeSize(4055544c,40555574
"1.0",00000004) ret=40801e61
084040a8:Ret  ntdll.RtlMultiByteToUnicodeSize() retval=00000000
ret=40801e61
084040a8:Call ntdll.RtlAllocateHeap(40330000,00000000,00000008)
ret=40801e74
084040a8:Ret  ntdll.RtlAllocateHeap() retval=403885cc ret=40801e74
084040a8:Call
ntdll.RtlMultiByteToUnicodeN(403885cc,00000008,00000000,40555574,00000004)
ret=40801e9b
084040a8:Ret  ntdll.RtlMultiByteToUnicodeN() retval=00000000
ret=40801e9b
084040a8:Call ntdll.RtlInitAnsiString(40555444,4085fd29 "Version")
ret=40801eb3
084040a8:Ret  ntdll.RtlInitAnsiString() retval=00000008 ret=40801eb3
084040a8:Call
ntdll.RtlAnsiStringToUnicodeString(401018cc,40555444,00000000)
ret=40801ec8
084040a8:Ret  ntdll.RtlAnsiStringToUnicodeString() retval=00000000
ret=40801ec8
084040a8:Call
ntdll.NtSetValueKey(000000bc,401018cc,00000000,00000001,403885cc,00000008)
ret=40801ee5
08073b88:Ret  kernel32.WaitForSingleObject() retval=00000102
ret=004036a9
08073b88:Call
user32.PeekMessageA(40556890,00000000,00000000,00000000,00000001)
ret=004037da
08073b88:Call
x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000)
ret=40621def
08073b88:Ret  x11drv.MsgWaitForMultipleObjectsEx() retval=00000102
ret=40621def
08073b88:Ret  user32.PeekMessageA() retval=00000000 ret=004037da
08073b88:Call kernel32.WaitForSingleObject(00000044,00000064)
ret=004036a9
084040a8:Ret  ntdll.NtSetValueKey() retval=00000000 ret=40801ee5
084040a8:Call ntdll.RtlFreeHeap(40330000,00000000,403885cc) ret=40801f01
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40801f01
084040a8:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801f07
084040a8:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801f07
084040a8:Ret  advapi32.RegSetValueExA() retval=00000000 ret=4084b38f
084040a8:Call advapi32.RegCloseKey(000000bc) ret=4084b39a
084040a8:Call ntdll.NtClose(000000bc) ret=40801c3b
084040a8:Ret  ntdll.NtClose() retval=00000000 ret=40801c3b
084040a8:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801c41
084040a8:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801c41
084040a8:Ret  advapi32.RegCloseKey() retval=00000000 ret=4084b39a
084040a8:Call advapi32.RegCloseKey(000000ac) ret=4084b3a8
084040a8:Call ntdll.NtClose(000000ac) ret=40801c3b
084040a8:Ret  ntdll.NtClose() retval=00000000 ret=40801c3b
084040a8:Call ntdll.RtlNtStatusToDosError(00000000) ret=40801c41
084040a8:Ret  ntdll.RtlNtStatusToDosError() retval=00000000 ret=40801c41
084040a8:Ret  advapi32.RegCloseKey() retval=00000000 ret=4084b3a8
084040a8:Call ntdll.RtlFreeHeap(40330000,00000000,4036859c) ret=40840a7b
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
084040a8:Call ntdll.RtlFreeHeap(40330000,00000000,40368574) ret=408509e3
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=408509e3
084040a8:Call ntdll.RtlFreeHeap(40330000,00000000,4036847c) ret=40840a7b
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
084040a8:Call kernel32.lstrlenW(403876b0 L"Release") ret=4084084e
084040a8:Ret  kernel32.lstrlenW() retval=00000007 ret=4084084e
084040a8:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
ret=4084096b
084040a8:Ret  ntdll.RtlAllocateHeap() retval=403885cc ret=4084096b
084040a8:Call kernel32.lstrlenW(403692ec L"IUnknown") ret=4084084e
084040a8:Ret  kernel32.lstrlenW() retval=00000008 ret=4084084e
084040a8:Call ntdll.RtlAllocateHeap(40330000,00000000,00000016)
ret=4084096b
084040a8:Ret  ntdll.RtlAllocateHeap() retval=4036847c ret=4084096b
trace:olerelay:xCall ->L"IUnknown":L"Release"(2)(084040a8:Call
ntdll.RtlFreeHeap(40330000,00000000,4036847c) ret=40840a7b
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
084040a8:Call ntdll.RtlFreeHeap(40330000,00000000,403885cc) ret=40840a7b
084040a8:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=40840a7b
084040a8:Call kernel32.lstrlenW(403876b0 L"Release") ret=4084084e
084040a8:Ret  kernel32.lstrlenW() retval=00000007 ret=4084084e
084040a8:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
ret=4084096b
084040a8:Ret  ntdll.RtlAllocateHeap() retval=403885cc ret=4084096b
)wine: Unhandled exception, starting debugger...
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0
addr 0x4027d1c7
08073b88:Ret  kernel32.WaitForSingleObject() retval=00000000
ret=004036a9
08073b88:Call kernel32.CloseHandle(00000044) ret=004036bb

...
> On Mon, May 06, 2002 at 03:08:46PM -0400, Michael Cardenas wrote:
> > Hmmm... strangely, when I try to install dreamweaver4, the installer
> > crashes. I have stdole32.tlb (and an entire windows directory).
> >
> > here's the output of +relay,+snoop, around the crash...
>
> ...
> > 08d39318:Call ntdll.RtlAllocateHeap(40330000,00000000,00000014)
> > ret=4084096b
> > 08d39318:Ret  ntdll.RtlAllocateHeap() retval=40368474 ret=4084096b
> > wine: Unhandled exception, starting debugger...
>
> Did this have my BSTR patch from yesterday applied? If yes, can you also
> add -debugmsg +olerelay?

[Andriy Palamarchuk]

FYI, the issue (the same or another with similiar
effect) still exists with an hour fresh CVS Wine.

For details see
http://bugs.winehq.com/show_bug.cgi?id=629

Andriy

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[Michael Cardenas]

I tried this again on another machine, with a clean install and a fresh
registry and a complete windows directory.

The dreamweaver installer still crashed in the same place. Attached is a
log of the crash.

If anyone has any input on this, I'd really appreciate it.

michael

On Mon, May 06, 2002 at 09:32:43PM +0200, Marcus Meissner wrote:
> On Mon, May 06, 2002 at 01:25:25PM -0400, Michael Cardenas wrote:
> > On Mon, May 06, 2002 at 01:13:33PM -0700, Alexandre Julliard wrote:
> > > It just fell through the cracks. Marcus resent me the patch and it's
> > > applied now.
> >
> > But does it work without that stdole32.tlb file? Does it work at all?
>
> I just installed DreamWeaver 4 again. ;)
>
> But yes, you would need the stdole32.tlb file.
>
> (Not sure if you could legally download it by just downloading the DCOM pack:
>         http://www.microsoft.com/com/dcom/dcom95/download.asp
> )
>
> Ciao, Marcus

[Ove Kaaven]

On 6 May 2002, Alexandre Julliard wrote:
> Ove Kaaven  writes:
> > After the WineX 2.0 release, I've once again been working on completing my
> > version of the real solution (I'm close to have it working now), but of
> > course, Gav probably still wants a fair chunk of LGPL-ed code relicensed
> > in exchange...
>
> Last we heard it was to be exchanged against the ALSA driver...

That was an example of what TransGaming might be willing to exchange it
against, I don't think Gav made a commitment on that. But the ALSA driver
is not yet complete, and the situation changed since the suggestion was
first made; Eric used to be on the Wine side ("against" TransGaming), and
was willing to write the ALSA driver in exchange for getting more AFPL-ed
code into Wine, but that was before Wine was LGPL-ed. Now, Eric is on the
ReWind side ("against" Wine), so now he is also interested in getting more
LGPL-ed code into ReWind. What he'll exchange the ALSA driver for will
depend on his priorities, but the deal certainly needs renegotiation in
any case.

What is most important for TransGaming now, is to see the DLL separation
work get into ReWind. He's making a list of things to trade it with, such
as a DIB drawing engine, fast DIB sections using ShmPixmaps, this COM
stuff I'm working on, and of course various DirectX things. Since I've
researched and worked on this COM thing (with undocumented stuff all over)
for months, I doubt TransGaming would settle with just an ALSA driver, now
that their development costs have increased from the forking.

[Alexandre Julliard]

Ove Kaaven  writes:
> That was an example of what TransGaming might be willing to exchange it
> against, I don't think Gav made a commitment on that. But the ALSA driver
> is not yet complete, and the situation changed since the suggestion was
> first made; Eric used to be on the Wine side ("against" TransGaming), and
> was willing to write the ALSA driver in exchange for getting more AFPL-ed
> code into Wine, but that was before Wine was LGPL-ed. Now, Eric is on the
> ReWind side ("against" Wine), so now he is also interested in getting more
> LGPL-ed code into ReWind. What he'll exchange the ALSA driver for will
> depend on his priorities, but the deal certainly needs renegotiation in
> any case.

I fail to see how the fact that the driver was written by a Rewind
supporter instead of a Wine supporter should make any difference from
Transgaming's point of view. And I personally don't see Wine as being
"against Transgaming", or Rewind as being "against Wine"; and if
that's how you see it I find that pretty sad. I also don't understand
how this method of holding code back and blackmailing other developers
can be considered a good thing either for Wine, or for Rewind, or for
Transgaming.

[Ove Kaaven]

On 6 May 2002, Alexandre Julliard wrote:
> Ove Kaaven  writes:
> > That was an example of what TransGaming might be willing to exchange it
> > against, I don't think Gav made a commitment on that. But the ALSA driver
> > is not yet complete, and the situation changed since the suggestion was
> > first made; Eric used to be on the Wine side ("against" TransGaming), and
> > was willing to write the ALSA driver in exchange for getting more AFPL-ed
> > code into Wine, but that was before Wine was LGPL-ed. Now, Eric is on the
> > ReWind side ("against" Wine), so now he is also interested in getting more
> > LGPL-ed code into ReWind. What he'll exchange the ALSA driver for will
> > depend on his priorities, but the deal certainly needs renegotiation in
> > any case.
>
> I fail to see how the fact that the driver was written by a Rewind
> supporter instead of a Wine supporter should make any difference from
> Transgaming's point of view.

Oh, there's none of that kind of difference; what could be different here
is just what Eric may want to do (and let TransGaming do).
> And I personally don't see Wine as being "against Transgaming", or
> Rewind as being "against Wine"; and if that's how you see it I find
> that pretty sad.

I used quotes for a reason. The intent was to express relativeness, not
attitude.
> I also don't understand how this method of holding code back and
> blackmailing other developers can be considered a good thing either
> for Wine, or for Rewind, or for Transgaming.

Agreed. If people would stop holding code back using the LGPL, the
symbiosis we'd have in any case would have a friendlier feel to it. But
the idea here is that, given the restrictions we now have in the LGPL, the
"blackmail" symbiosis we'll be entering now, will result in the most code
available for everyone; CodeWeavers and Wine will benefit from code
blackmailed out of TransGaming, and TransGaming and WineX will benefit
from code blackmailed out of CodeWeavers, and ReWind will benefit from
both. And ReWind is what's important to me personally.

(I better put a disclaimer here: I do not speak for my employer. I speak
because of the extra, more boring, work I am now forced to do, but mostly
from the ReWind perspective.)

[Gavriel State]

Alexandre Julliard wrote:
> I fail to see how the fact that the driver was written by a Rewind
> supporter instead of a Wine supporter should make any difference from
> Transgaming's point of view. And I personally don't see Wine as being

Indeed - it has nothing to do with anything.

The situation with the ALSA driver is this:
   - We offered Eric money to do the ALSA driver
   - Eric asked instead that we put the money towards something else
     to benefit Wine
   - That money (and other money) is going to go towards our sponsorship
     of a method to speed up the WineServer / Client interface, ie: via
     a kernel module if that make sense
   - I've been trying to find the time to write up a detailed proposal
     for said sponsorship, as well as proposals for trades of other code
     but my time has been limited lately.  We've done a fair bit of
     research on a Kenel module approach, but we need to put together
     more cohesive documentation on the results so far.
> "against Transgaming", or Rewind as being "against Wine"; and if
> that's how you see it I find that pretty sad. I also don't understand
> how this method of holding code back and blackmailing other developers
> can be considered a good thing either for Wine, or for Rewind, or for
> Transgaming.

What we are proposing is not "blackmail" but *trade*.

Really, the economic problem in this licensing situation comes down to a
question of accounting (most economic problems do).  What value do you place
on a contribution to the project, whether it is your own or someone else's?

The LGPL license that Wine is currently using is effectively saying that
the value of your current contribution is equal to the expected value
of any future contributions.  IE: All contributions and contributors,
current and future are equivalent.  Certainly this simplifies the accounting,
but at a serious loss in accuracy.

As we've already stated, TransGaming can't operate within that framework,
for a wide variety of reasons.  Instead, we're going to be making the
value picture more specific.  We would like access to some code that's
currently licensed under the LGPL by copyright holders like yourself and
CodeWeavers.  In particular, we would like to see address space separation
work made available under the X11/ReWind license.  That would be a boon
for everyone, as it would allow easy interchangability between Wine and
ReWind (and WineX) DLLs.  There are a few other things that would be
nice as well.

In exchange, we have a number of things that we would be happy to contribute
to ReWind, and thus to the Wine tree.  These things include our new DIB engine
work, COM/DCOM work, selected portions of our work on copy protection, and a
number of other significant features.  We're also quite happy to work on any
DLLs that need additional seperation work.

What has to get figured out is simply this: exactly what do current Wine
copyright holders want to have for the things that we want from you?

I'd like to resolve this question soon, and establish some kind of ongoing
framework for how to manage this cooperation in the future.  I hope to
have a detailed proposal for the Wine LGPL-only contributors shortly.

Take care,
   -Gav

Problem with InstallShield

[Hetz Ben Hamo]

The question is - who decides what? - and I'll explain...

I'm not sure that CodeWeavers have the same priorities as Transgaming. As much 
as I see now, Transgaming is very focused on multimedia (e.g: WineX 2) while 
CodeWeavers is more focused on productivity applications (e.g: CrossOver 
Office, the Kylix RAD GUI and other stuff)..

So I wonder - if every side see different parts in different priorities - who 
decides what-worth-what? just an hypothetical example: does ALSA driver worth 
DCOM implementation?

Maybe it's time that both Jeremy White and Gavriel State would say what parts 
of their side of wine (WineHQ VS. Re-Wind/WineX) they're willing to trade? I 
don't know if there is a need for a middle man here since both sides knows 
how to express themselves quite well (oh, and Brett - if you see this email 
and want to respond - SHUT UP!)..

Would either one of the side put down a list of what he's want to trade?

Thanks,
Hetz

Problem with InstallShield

[Jeremy White]

> Would either one of the side put down a list of what he's want to trade?

Hetz, the fundamental problem is that I am not interested in trading.

I think Alexandre expressed the problems with this approach quite well.

Finally, as Alexandre tried to do, let's please take this
discussion over to wine-license.

Cheers,

Jeremy

[Alexandre Julliard]

Gavriel State  writes:
> Really, the economic problem in this licensing situation comes down to a
> question of accounting (most economic problems do).  What value do you place
> on a contribution to the project, whether it is your own or someone else's?

The problem is that you are seeing this in economic terms. That's not
how it works. The real value is not in the individual contributions,
it's in the collaboration, where everybody works with everybody else
on building the best possible Windows emulator.

Consider you are organizing a party with your friends: someone who has
a large music collection will bring his CDs, some will cook something,
others will spend time decorating the room, etc.  What value do you
place on each contribution?  How many cakes do I have to bring to be
allowed to listen to the music?  That's not how it works. Everybody
helps according to his time and ability, and then we all enjoy the
party.

What you are doing is you come to the party, you eat and drink from
what others have brought, but when people want some of your stuff you
charge them for it. And when they complain you ask them to start
charging for their stuff too, and transform the party into a shopping
mall. Sorry, but for me that would take all the fun out of it.

If you want to join the party you are expected to participate
according to your abilities. And yes, with your full-time programmers
you can (and should) contribute more than people who just have a few
hours a month to spend on it. That doesn't mean you are somehow
entitled to get more fun out of the party than they do.

So far we have welcomed you to the party, even though you contributed
much less than you could have; but the problem is that you are
actually preventing others from enjoying the party, and this can't go
on. So you can either start participating and sharing like everybody
else, or you can stay home and cook your own dinner. But if you want
to eat some of what I've brought, the only way is to join the party.

[Follow-ups to wine-party^H^H^H^H^Hlicense please]

Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

[Eric Pouech]

Ove Kaaven a écrit :
> On 6 May 2002, Alexandre Julliard wrote:
> > Ove Kaaven  writes:
> > > After the WineX 2.0 release, I've once again been working on completing my
> > > version of the real solution (I'm close to have it working now), but of
> > > course, Gav probably still wants a fair chunk of LGPL-ed code relicensed
> > > in exchange...
> >
> > Last we heard it was to be exchanged against the ALSA driver...
>
> That was an example of what TransGaming might be willing to exchange it
> against, I don't think Gav made a commitment on that. But the ALSA driver
> is not yet complete, and the situation changed since the suggestion was
> first made; Eric used to be on the Wine side ("against" TransGaming), and
> was willing to write the ALSA driver in exchange for getting more AFPL-ed
> code into Wine, but that was before Wine was LGPL-ed. Now, Eric is on the
> ReWind side ("against" Wine), so now he is also interested in getting more
> LGPL-ed code into ReWind. What he'll exchange the ALSA driver for will
> depend on his priorities, but the deal certainly needs renegotiation in
> any case.

Just to make things clear

When I decided starting coding the ALSA driver, TG offered to sponsor
the
work. I turned down the offer (don't need sponsor for what I'm doing)
and
suggested using the money for some other use.
Furthermore, I'm not for or against Wine nor for or against WineX. I'm
just
trying not to let an important gap being created between all the
different
projects.

The ALSA driver has been started on a X11/MIT license, some people
currently are
giving an hand to shape it better (David Hammerton did some testing and
bug
fixing for 0.5, Marco Pietrobono is currently fighting with the awes of
the
0.9 interface, but that's another story), and will remain under the
X11/MIT 
license.

A+

Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

[Roland]

This whole discussion going on now about trading patches is another point 
against the license change. Probably no one has thought about these 
complications. Not that changing licenses can't be done. But one should 
think carefully before doing so...

Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

[Michael Cardenas]

Well, a big part of discussion was the wokr around that ove kaaven
mentioned, but it doesn't seem to work, or it works for some people and
not for others.

I'm putting some time into making it work, aand so is Marcus, and so is 
Marcus, maybe some other people can help. I think that we all agree that
InstallShield support is a huge, important feature.

On Tue, May 07, 2002 at 07:17:50PM -0300, Roland wrote:
> This whole discussion going on now about trading patches is another point 
> against the license change. Probably no one has thought about these 
> complications. Not that changing licenses can't be done. But one should 
> think carefully before doing so...

Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

Ironically, it was myself who started the first "Let's change to the GPL"
movement (the second one being after Jeremy changed his mind about the
GPL) (of course, mine wasn't the 'first', it was just the most recent)
(I'll stop doing this now)..

Anyway, I simply asked if Ove would be able to release the IShield patches
anytime soon. This of course sparked debate, with the conclusion being
that very few people being corporatly involved were activly commiting
useful chunks of work back, recently.

Now, this license debate issue went on for several months before coming to
the vote. And I have to say, in all respect to Gav, Ove and everyone at TG
(great work on the actual code)... during this period of debate there was
no real sign of goodwill from 'that side' of the fence.

The debate started because no substantial work has been released to WINE
core from these commercial ventures. During the debate period, it would
have been quite easy for them to release some of said code and say "Okay,
okay, we're slow, but we done it" then promise for the last x months that
it would be 'returned eventually'.

And the code exchange idea seems fundementally flawed. In theory, the
concept is sound. In practice, the examples I've heard are very
unrealistic. For example, Gav gave an example at WineConf, which I believe
was...

"We'd trade the InstallShield code for a complete DIB engine"
(paraphrased, apologies if I got it wrong). Even if this is an example, it
is very unrealistic in terms of expectations. Looking at the WineX tree,
and the actual code for the InstallShield hacks.. then comparing that to
the work that would be needed on a DIB engine - the scales don't ballance.

And unfortunatly, as I said, there was been very little sign of any return
coming in, besides mere promises.

- Ender

Disclaimer: 1) This is not a flame. 2) I respect the work of everyone
involved, and this is not a flame. 3) I'm not a wine developer, just a
user and long-time follower of wine development :) 4) Did I mention this
is not a flame? 5) Yes, yes. I'm naturally pessimstic.

On Tue, May 07, 2002 at 07:17:50PM -0300, Roland wrote:
> This whole discussion going on now about trading patches is another point
> against the license change. Probably no one has thought about these
> complications. Not that changing licenses can't be done. But one should
> think carefully before doing so...

Problem with InstallShield (Was Re: [Bug 629] Changed - Problemwith InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

[Francois Gouget]

On Tue, 7 May 2002 [e-mail] wrote:
[...]
> And the code exchange idea seems fundementally flawed. In theory, the
> concept is sound. In practice, the examples I've heard are very
> unrealistic.

[...]

The code exchange idea is sound only if the number of copyright holders
is limited (typically 2 or 3). But this is not the case, and more than
any balance problem this is the fundamental flaw of this idea.
> From the example you cited, let's assume that a DIB engine is supposed

to be given to the X11 tree in exchange for some other piece of code. A
DIB engine is no small piece of code and will not be developped by a
single individual but more by something like 10+ developpers.

To 'give' it to the X11 tree you have to have the agreement of all 10
developpers. Even if there is a 70% chance that each of them will agree
to relicense their code (which seems overly optimistic), there is only a
2.8% chance that all 10 will agree.

Then you have to hack and slash into the code to remove the
contributions of all those who oppose the exchange, and work on
replacing them. Urgh.

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
           Demander si un ordinateur peut penser revient à demander
                          si un sous-marin peut nager.