Problem with InstallShield (Was Re: [Bug 629] Changed - Problem with InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)
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
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...
--- Ove Kaaven <ovehk(a)ping.uio.no> 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.
[... 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
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.
"Ove" == Ove Kaaven <ovehk(a)ping.uio.no> 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 -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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 <ovehk(a)ping.uio.no> 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.
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
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 <ovehk(a)ping.uio.no> 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);
On Mon, May 06, 2002 at 09:37:02PM +0200, Uwe Bonnes wrote:
"Ove" == Ove Kaaven <ovehk(a)ping.uio.no> 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
Ove Kaaven <ovehk(a)ping.uio.no> 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... -- Alexandre Julliard julliard(a)winehq.com
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.
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
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
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
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
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
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?
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
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
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
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
On 6 May 2002, Alexandre Julliard wrote:
Ove Kaaven <ovehk(a)ping.uio.no> 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.
Ove Kaaven <ovehk(a)ping.uio.no> 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. -- Alexandre Julliard julliard(a)winehq.com
On 6 May 2002, Alexandre Julliard wrote:
Ove Kaaven <ovehk(a)ping.uio.no> 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.)
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 -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com
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
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
Gavriel State <gav(a)transgaming.com> 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] -- Alexandre Julliard julliard(a)winehq.com
Ove Kaaven a écrit :
On 6 May 2002, Alexandre Julliard wrote:
Ove Kaaven <ovehk(a)ping.uio.no> 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+
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...
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...
-- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi
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...
On Tue, 7 May 2002 winedev(a)admdev.com 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 fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
participants (13)
-
Alexandre Julliard -
Andriy Palamarchuk -
Eric Pouech -
Francois Gouget -
Gavriel State -
Hetz Ben Hamo -
Jeremy White -
Marcus Meissner -
Michael Cardenas -
Ove Kaaven -
Roland -
Uwe Bonnes -
winedev＠admdev.com