So, how's that Installshield 6 support coming along? :-)
The company I work for uses Installshield to package up its windows stuff. Today I tried running its installer under cvs Wine, and shortly after it started running IKernel.exe, it dropped me into the wine debugger.
Copying and pasting from the wine debugger window is beyond me; it seems totally broken. However, it looks like it was complaining of a null pointer read.
Here are the last few interesting lines of the wine log:
trace:ole:ITypeInfo_fnGetTypeAttr (0x40298e58) trace:ole:ITypeInfo_fnGetRefTypeOfImplType (0x40298e58) index 0 trace:ole:dump_TypeInfo 0x40298e58 ref=2 trace:ole:dump_TypeInfo attr:{91814ec1-b5f0-11d2-80b9-00104b1f6cea} trace:ole:dump_TypeInfo kind:TKIND_INTERFACE trace:ole:dump_TypeInfo fct:13 var:0 impl:1 trace:ole:dump_TypeInfo parent tlb:0x4026c9c8 index in TLB:28 trace:ole:dump_TypeInfo L"ISetupCABFile" (null) trace:ole:ITypeInfo_fnGetRefTypeOfImplType -- 0x00000000 trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded 080761c8:Call ntdll.RtlUnicodeToMultiByteSize(40791ac8,40791ae4 L"stdole32.tlb",0000001a) ret=409e78c8 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,00000000,00000000) ret=40b9e285 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,4028bfdc,0000000d) ret=40b9e2a8 trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x40791f2c) 080761c8:Call kernel32.SearchPathW(00000000,4028bfdc L"stdole32.tlb",00000000,00000105,40791cac,00000000) ret=40b9e41a trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil)) trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"C:\WINNT\System32\StdOle32.tlb",0,0x40791f2c) trace:ole:ITypeInfo_fnGetRefTypeInfo (0x40298e58) hreftype 0x0000 loaded FAILURE (0x13) fixme:ole:_get_funcdesc Did not find a typeinfo for reftype 0? fixme:ole:PSFacBuf_CreateProxy GetFuncDesc 80004005 should not fail here. fixme:ole:StdMarshalImpl_UnmarshalInterface Failed to create a proxy for {91814ec1-b5f0-11d2-80b9-00104b1f6cea} fixme:ole:CoUnmarshalInterface Failed to Unmarshal the interface, 80004005? 080761c8:Ret ole32.CoUnmarshalInterface() retval=80004005 ret=40b9a2fd fixme:ole:_unmarshal_interface Marshaling interface {91814ec1-b5f0-11d2-80b9-00104b1f6cea} failed with 80004005 fixme:ole:deserialize_param failed to stuballoc in TKIND_RECORD. trace:ole:ITypeInfo_fnRelease (0x40279798)->(1) fixme:ole:xCall Failed to unmarshall param, hres 80004005 wine: Unhandled exception, starting debugger...
Any suggestions? I am a babe in the woods when it comes to the wine debugger, or for that matter, ole. - Dan
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory. maybe stdole.tlb and stdole2.tlb too, but i don't know if they're needed or not, i just copy them just in case.
Bobby Bingham
On Monday 20 January 2003 9:53 pm, Dan Kegel wrote:
So, how's that Installshield 6 support coming along? :-)
The company I work for uses Installshield to package up its windows stuff. Today I tried running its installer under cvs Wine, and shortly after it started running IKernel.exe, it dropped me into the wine debugger.
Copying and pasting from the wine debugger window is beyond me; it seems totally broken. However, it looks like it was complaining of a null pointer read.
Here are the last few interesting lines of the wine log:
trace:ole:ITypeInfo_fnGetTypeAttr (0x40298e58) trace:ole:ITypeInfo_fnGetRefTypeOfImplType (0x40298e58) index 0 trace:ole:dump_TypeInfo 0x40298e58 ref=2 trace:ole:dump_TypeInfo attr:{91814ec1-b5f0-11d2-80b9-00104b1f6cea} trace:ole:dump_TypeInfo kind:TKIND_INTERFACE trace:ole:dump_TypeInfo fct:13 var:0 impl:1 trace:ole:dump_TypeInfo parent tlb:0x4026c9c8 index in TLB:28 trace:ole:dump_TypeInfo L"ISetupCABFile" (null) trace:ole:ITypeInfo_fnGetRefTypeOfImplType -- 0x00000000 trace:ole:ITypeInfo_fnGetRefTypeInfo typeinfo in imported typelib that isn't already loaded 080761c8:Call ntdll.RtlUnicodeToMultiByteSize(40791ac8,40791ae4 L"stdole32.tlb",0000001a) ret=409e78c8 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,00000000,00000000) ret=40b9e285 080761c8:Call kernel32.MultiByteToWideChar(00000000,00000001,40791cf8 "stdole32.tlb",0000000d,4028bfdc,0000000d) ret=40b9e2a8 trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x40791f2c) 080761c8:Call kernel32.SearchPathW(00000000,4028bfdc L"stdole32.tlb",00000000,00000105,40791cac,00000000) ret=40b9e41a trace:ole:LoadRegTypeLib (IID: {00020430-0000-0000-c000-000000000046}) load FAILED ((nil)) trace:ole:LoadTypeLib trace:ole:LoadTypeLibEx (L"C:\WINNT\System32\StdOle32.tlb",0,0x40791f2c) trace:ole:ITypeInfo_fnGetRefTypeInfo (0x40298e58) hreftype 0x0000 loaded FAILURE (0x13) fixme:ole:_get_funcdesc Did not find a typeinfo for reftype 0? fixme:ole:PSFacBuf_CreateProxy GetFuncDesc 80004005 should not fail here. fixme:ole:StdMarshalImpl_UnmarshalInterface Failed to create a proxy for {91814ec1-b5f0-11d2-80b9-00104b1f6cea} fixme:ole:CoUnmarshalInterface Failed to Unmarshal the interface, 80004005? 080761c8:Ret ole32.CoUnmarshalInterface() retval=80004005 ret=40b9a2fd fixme:ole:_unmarshal_interface Marshaling interface {91814ec1-b5f0-11d2-80b9-00104b1f6cea} failed with 80004005 fixme:ole:deserialize_param failed to stuballoc in TKIND_RECORD. trace:ole:ITypeInfo_fnRelease (0x40279798)->(1) fixme:ole:xCall Failed to unmarshall param, hres 80004005 wine: Unhandled exception, starting debugger...
Any suggestions? I am a babe in the woods when it comes to the wine debugger, or for that matter, ole.
- Dan
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work, and even then, I had to move the big background window around, etc. Also, if things failed for any reason, I had to kill leftover wine processes, or the next run would fail. Still, this is progress!
I'd like to help get wine to the point where it can run this stuff cleanly. I suppose the inability to run the package-for-the-web wrapper is the worst problem... I'll try to track that down and provide more details.
Thanks! - Dan
Dan Kegel wrote:
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work
It looks like there's a Heisenbug here. If I run without logging, I get a window titled "Unhandled Exception", with contents "Error Number: 0x80040706 Description: Object reference not set Setup will now terminate."
Intriguingly, this error message may be from a bug in Installshield itself; see http://www.installsite.org/pages/en/bugs_is60.htm I'll check to see what version of Installshield this setup.exe was built with. However, I wouldn't be suprised if there's a race condition here, seeing as how setup worked fine with logging on.
- Dan
On Mon, Jan 20, 2003 at 11:12:29PM -0800, Dan Kegel wrote:
Dan Kegel wrote:
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
I will add a large message suggesting that.
Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work
It looks like there's a Heisenbug here. If I run without logging, I get a window titled "Unhandled Exception", with contents "Error Number: 0x80040706 Description: Object reference not set Setup will now terminate."
I have seen this on and off, but I thought I fixed it.
Ciao, Marcus
Marcus Meissner wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
I will add a large message suggesting that.
Thanks. (I'm also looking forward to the possibility of wine having its own stdole32.tlb soon.)
It looks like there's a Heisenbug here. If I run without logging, I get a window titled "Unhandled Exception", with contents "Error Number: 0x80040706 Description: Object reference not set Setup will now terminate."
I have seen this on and off, but I thought I fixed it.
Interestingly, under wine20020605, I am able to complete the installation program. Thus we seem to have a regression. Which would be more helpful: me tracking down which patch caused the regression, or me sending some more knowledgeable person a minimal test case?
Thanks, Dan
On Wed, Jan 22, 2003 at 01:50:36PM -0800, Dan Kegel wrote:
Marcus Meissner wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
I will add a large message suggesting that.
Thanks. (I'm also looking forward to the possibility of wine having its own stdole32.tlb soon.)
It looks like there's a Heisenbug here. If I run without logging, I get a window titled "Unhandled Exception", with contents "Error Number: 0x80040706 Description: Object reference not set Setup will now terminate."
I have seen this on and off, but I thought I fixed it.
Interestingly, under wine20020605, I am able to complete the installation program. Thus we seem to have a regression. Which would be more helpful: me tracking down which patch caused the regression, or me sending some more knowledgeable person a minimal test case?
Hmm, I think binary search for the broken patch would be easier.
Ciao, Marcus
Marcus Meissner wrote:
"Error Number: 0x80040706 Description: Object reference not set Setup will now terminate."
I have seen this on and off, but I thought I fixed it.
Interestingly, under wine20020605, I am able to complete the installation program. Thus we seem to have a regression. Which would be more helpful: me tracking down which patch caused the regression, or me sending some more knowledgeable person a minimal test case?
Hmm, I think binary search for the broken patch would be easier.
I was afraid you'd say that :-) Will do. - Dan
"Dan" == Dan Kegel dank@kegel.com writes:
Dan> Bobby Bingham wrote: >> IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real >> windows to wine's system directory.
Dan> Yep, copying just that one file made things get a lot further! Be sure to use builtin ole32,oleaut32 and rpcrt4 and have the native std*.tbl in your windows directory.
Bye
Would this be fixed by the work that's being done on Wines RPC implementation?
Why exactly does an installer require such complex parts of OLE anyway? That seems like overkill for a self-extracting exe to me.
On Tue, 2003-01-21 at 03:39, Dan Kegel wrote:
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory.
Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work, and even then, I had to move the big background window around, etc. Also, if things failed for any reason, I had to kill leftover wine processes, or the next run would fail. Still, this is progress!
I'd like to help get wine to the point where it can run this stuff cleanly. I suppose the inability to run the package-for-the-web wrapper is the worst problem... I'll try to track that down and provide more details.
Thanks!
- Dan
On Tue, Jan 21, 2003 at 09:43:29AM +0000, Mike Hearn wrote:
Would this be fixed by the work that's being done on Wines RPC implementation?
This is a different implementation, when it is finished ... yes.
The current implementation should be capable of doing that too.
Why exactly does an installer require such complex parts of OLE anyway? That seems like overkill for a self-extracting exe to me.
No clue.
Ciao, Marcus
On Tuesday 21 January 2003 04:38 am, Marcus Meissner wrote:
On Tue, Jan 21, 2003 at 09:43:29AM +0000, Mike Hearn wrote:
Would this be fixed by the work that's being done on Wines RPC implementation?
This is a different implementation, when it is finished ... yes.
don't hold your breath :) But I concur, implementing the RPC APIs, including the DCOM specific ones, will fix it eventually. Now that I have an actual working test, I can continue work on the actual implementation side. But first I want to do some more cabextract stuff, since it appears that it's not 100% working yet.
The current implementation should be capable of doing that too.
Why exactly does an installer require such complex parts of OLE anyway? That seems like overkill for a self-extracting exe to me.
No clue.
Well, it's not hard to imagine why an installer might need some interprocess communicaiton. And since RPC is available for basically every MS OS out there, and even non-MS platforms, it's easy to see how they came to the decision to use it.
Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code?
On Tue, 2003-01-21 at 16:48, Greg Turner wrote:
On Tuesday 21 January 2003 04:38 am, Marcus Meissner wrote:
On Tue, Jan 21, 2003 at 09:43:29AM +0000, Mike Hearn wrote:
Would this be fixed by the work that's being done on Wines RPC implementation?
This is a different implementation, when it is finished ... yes.
don't hold your breath :) But I concur, implementing the RPC APIs, including the DCOM specific ones, will fix it eventually. Now that I have an actual working test, I can continue work on the actual implementation side. But first I want to do some more cabextract stuff, since it appears that it's not 100% working yet.
The current implementation should be capable of doing that too.
Why exactly does an installer require such complex parts of OLE anyway? That seems like overkill for a self-extracting exe to me.
No clue.
Well, it's not hard to imagine why an installer might need some interprocess communicaiton. And since RPC is available for basically every MS OS out there, and even non-MS platforms, it's easy to see how they came to the decision to use it.
On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote:
Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code?
I don't know the full story with IS6: I haven't experimented with that particular bug. But, generally speaking, you can't just fudge threads for processes; if a.exe runs b.exe, and exepects to speak to it via RPC, there's basically no hope of getting around the cross-process nature of the problem.
Ah, I meant from the perspective of the InstallShield developers rather than how to hack around it in Wine. Well, they must have had their reasons....
On Wed, 2003-01-22 at 10:34, Greg Turner wrote:
On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote:
Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code?
I don't know the full story with IS6: I haven't experimented with that particular bug. But, generally speaking, you can't just fudge threads for processes; if a.exe runs b.exe, and exepects to speak to it via RPC, there's basically no hope of getting around the cross-process nature of the problem.
On 22 Jan 2003, Mike Hearn wrote:
Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code?
It does use threads, and a lot of other things. But I think the idea of using advanced COM stuff makes sense from the InstallShield point of view - all that COM/DCOM/RPC stuff is already on every Windows installation, so the installer executable does become smaller by using it instead of writing their own mechanisms to achieve the same thing.
The program you launch simply does the "Preparing InstallShield Wizard" thing, this is where interprocess COM call takes place. Once you get past that and start the actual installer, the main engine (ikernel) only uses threads (though unfortunately, interthread COM calls aren't quite implemented yet, so repainting suffers). However, that engine does export OLE Automation-compatible COM interfaces, probably so that app-specific installation routines can be written in any language, including Visual Basic, Java, C++, etc (not just iscript), and still be able to easily call the ikernel API. This sometimes calls for IPC, but again, this is all handled by the stuff that's already there in every Windows installation, so there's no reason for InstallShield to bloat itself with its own reimplementation of these mechanisms - other than "it causes headaches for those Wine guys", but that probably wouldn't be their primary concern...
what are the missing functions that live in stdole2.tlb ? is someone trying to implement it ?
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Tue, Jan 21, 2003 at 04:26:28PM +0100, Sylvain Petreolle wrote:
what are the missing functions that live in stdole2.tlb ? is someone trying to implement it ?
The TLB is a typelib file, which is compiled from a .IDL file.
So widl needs to generate it at one point.
Ciao, Marcus
Dan Kegel wrote:
... Copying and pasting from the wine debugger window is beyond me; it seems totally broken...
In ~/.wine/user.reg, look for the [Software\Wine\WineDbg] key and change "UseXTerm"=dword:00000000 (yes, zero is true for some reason).
Then in ~/.wine/system.reg, look for [Software\Microsoft\Windows NT\CurrentVersion\AeDebug] and set "Auto"="1" "Debugger"="winedbg.exe --debugmsg -all %ld %ld" ___________________^^^^ put in the ".exe"
I think that was all I did to be able to run the debugger within an xterm. Cutting and pasting is now much easier.
doesnt seem to work happily if you use it with wcmd... --- Duane Clark dclark@akamail.com a écrit : > Dan Kegel wrote:
... Copying and pasting from the wine debugger window is beyond me; it seems totally broken...
In ~/.wine/user.reg, look for the [Software\Wine\WineDbg] key and change "UseXTerm"=dword:00000000 (yes, zero is true for some reason).
Then in ~/.wine/system.reg, look for [Software\Microsoft\Windows NT\CurrentVersion\AeDebug] and set "Auto"="1" "Debugger"="winedbg.exe --debugmsg -all %ld %ld" ___________________^^^^ put in the ".exe"
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Bobby Bingham -
Dan Kegel -
Duane Clark -
Greg Turner -
Marcus Meissner -
Marcus Meissner -
Mike Hearn -
Ove Kaaven -
Sylvain Petreolle -
Uwe Bonnes