Quick brief, I've been lurking for quite some time around WineHQ and the wine project, but don't really have time for putting a lot of devel into it. It seems wine is finally getting close enough to working for most things that I can put some time into tracking problems without gobbling up many hours.
All that said, I've been trying to get some InstallShield v6 based installers to work with wine without much success. I've tried various combinations of builtin and native versions of the ole related dlls, each configuration with it's own hitches.
With a mostly 'native' configuration, I get the 0x80070008 (ERROR_NOT_ENOUGH_MEMORY) error when trying to load IKernel.exe. I did not spend a lot of time with this as 'builtin' really is the prefered method anyway.
With a completely 'builtin' configuration for the various ole dlls, I get the dreaded 0x80070005 (ERROR_ACCESS_DENIED) when trying to load IKernel.exe that others have reported on the list in the past. After persuing this a bit, I found that the problems seems to lie in the fact that CoGetClassObject in compobj.c does not have CLSCTX_LOCAL_SERVER implemented, which InstallShield is trying to use when starting up the "InstallShield setup kernel" via CoCreateInstance.
My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.
On Wed, Apr 18, 2001 at 10:42:24AM -0400, Mike Bond wrote:
Quick brief, I've been lurking for quite some time around WineHQ and the wine project, but don't really have time for putting a lot of devel into it. It seems wine is finally getting close enough to working for most things that I can put some time into tracking problems without gobbling up many hours.
All that said, I've been trying to get some InstallShield v6 based installers to work with wine without much success. I've tried various combinations of builtin and native versions of the ole related dlls, each configuration with it's own hitches.
With a mostly 'native' configuration, I get the 0x80070008 (ERROR_NOT_ENOUGH_MEMORY) error when trying to load IKernel.exe. I did not spend a lot of time with this as 'builtin' really is the prefered method anyway.
With a completely 'builtin' configuration for the various ole dlls, I get the dreaded 0x80070005 (ERROR_ACCESS_DENIED) when trying to load IKernel.exe that others have reported on the list in the past. After persuing this a bit, I found that the problems seems to lie in the fact that CoGetClassObject in compobj.c does not have CLSCTX_LOCAL_SERVER implemented, which InstallShield is trying to use when starting up the "InstallShield setup kernel" via CoCreateInstance.
My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.
This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff.
This is not a trivial 100 line patch, its more like 20000+ lines.
Ciao, Marcus
Marcus Meissner wrote:
On Wed, Apr 18, 2001 at 10:42:24AM -0400, Mike Bond wrote:
My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.
This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff.
This is not a trivial 100 line patch, its more like 20000+ lines.
The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL.
Daniel Walker
My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.
This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff.
This is not a trivial 100 line patch, its more like 20000+ lines.
The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL.
Ok, not rpc but lpc so we might get along with 10000+ lines. ;-) Mashalling is nessesary in any case since the function calls have to go from one process to an other. The com object in the exe is likely an automation server.
Bye
Juergen
On Wed, Apr 25, 2001 at 10:24:26PM +0200, Juergen Schmied wrote:
My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER in compobj.c:CoGetClassObject, or have plans to work on this in the near future? If not, I may go back to trying to figure out what is happening with the 'native' configuration.
This will require a lot of work, basically you will need to implement all of the OLE out of process, marshalling, rpc stuff.
This is not a trivial 100 line patch, its more like 20000+ lines.
The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL.
Ok, not rpc but lpc so we might get along with 10000+ lines. ;-) Mashalling is nessesary in any case since the function calls have to go from one process to an other. The com object in the exe is likely an automation server.
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
Unfortunately I've hit crunch time at work so all non-work related efforts have been paused. Hopefully in a week I'll get back to trying to figure out what was up with the 0x80070008. I think it my just be because I need to use native com dlls as well as the ole ones, but that is pure speculation at this point.
As for doing the 10k+ lines of coding myself, I have experience in (de)marshalling and network coding, spent many years doing it, it's more a matter of available time and learning the com wire protocols, neither of which are currently available to me. Here's to hoping someone is already working on it ;).
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
AFAIK, no one is actively doing this. We're working hard on the installers, including everything up to the point of actually diving of the COM/DCOM cliff.
Jeremy
Jeremy White wrote:
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
AFAIK, no one is actively doing this. We're working hard on the installers, including everything up to the point of actually diving of the COM/DCOM cliff.
http://freedce.sourceforge.net/ is an open source project to implement COM. It's been around quite some time, and started off from the same DCE sources that Microsoft based its stuff on. (See also http://linas.org/linux/corba.html ) It was dormant for a while, but I think it's being worked on again.
I wonder if that might not be useful here? - Dan
On Thu, Apr 26, 2001 at 04:47:01PM -0700, Dan Kegel wrote:
http://freedce.sourceforge.net/ is an open source project to implement COM. It's been around quite some time, and started off from the same DCE sources that Microsoft based its stuff on. (See also http://linas.org/linux/corba.html ) It was dormant for a while, but I think it's being worked on again.
I wonder if that might not be useful here?
That sounds interesting. I could start looking into it, but I'm really not sure I am the best person to depend on for moving this effort forward. As I said, I have little time to myself, with two elementary school age kids. I may have a bit more time once the latest crunch at work ends, but not sure I will have enough to put the amount of time it will take to accomplish this.
There is also the matter that I don't really have a lot of experience specifically with ole/com, most of my exerience lies both proprietary and CORBA protocols, almost exclusively on *nix platforms.
On the other hand, I personally see this as a major stumbling block for the widespread use of Wine, beyond the stability of completeness of the basic system. So, until someone else steps forward, I will see what I can do to persue this a bit farther.
On Thu, Apr 26, 2001 at 04:47:01PM -0700, Dan Kegel wrote:
Jeremy White wrote:
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
AFAIK, no one is actively doing this. We're working hard on the installers, including everything up to the point of actually diving of the COM/DCOM cliff.
http://freedce.sourceforge.net/ is an open source project to implement COM. It's been around quite some time, and started off from the same DCE sources that Microsoft based its stuff on. (See also http://linas.org/linux/corba.html ) It was dormant for a while, but I think it's being worked on again.
I wonder if that might not be useful here?
Actually linuxtoday.com happens to link to an article at www.consultingtimes.com/DCE.html just today :-)
(headline "The Free DCE project - Trying to regain lost ground...")
Mike Bond wrote:
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
The fix we put into the TransGaming tree was from Andreas Mohr, and it fixed some problems related to previous versions of InstallSheild. We haven't made any progress on v6.
We'd certainly like to see it get done, but our resources are somewhat limited at the moment, and we're concentrating on the DirectX work.
Something that's interesting about the InstallShield objects is this: They seem to expose a fair amount of their interfaces through OLE Automation. I don't know for certain, but I have a recollection that some work was done to support Automation for WordPerfect. I can't remember whether that work was actually completed, or bypassed through the use of dde for scripting instead.
If automation does work, then perhaps it's enough to simply run the InstallShield ikernel.exe and see if the user-side of the installer works through automation rather than requiring marshalling.
-Gav
On Thu, 26 Apr 2001, Gavriel State wrote:
Mike Bond wrote:
This getes me back to the other part of the question, is anyone currently working on this? I know people at CodeWeavers supposedly were working on getting the various mutations of InstallShield working, this error seems to be pretty common across all InstallSheild v6 based installers I've seen. I had also heard there was progress getting Alice install working at TransGaming, is that InstallSheild v6 based?
The fix we put into the TransGaming tree was from Andreas Mohr, and it fixed some problems related to previous versions of InstallSheild. We haven't made any progress on v6.
We'd certainly like to see it get done, but our resources are somewhat limited at the moment, and we're concentrating on the DirectX work.
Something that's interesting about the InstallShield objects is this: They seem to expose a fair amount of their interfaces through OLE Automation. I don't know for certain, but I have a recollection that some work was done to support Automation for WordPerfect. I can't remember whether that work was actually completed, or bypassed through the use of dde for scripting instead.
Well, that's not in Wine, at least... the Black & White installer fails after something about CLSCTX_LOCAL_SERVER that's not implemented. Do you mean it's in the Corel tree?
On Thu, Apr 26, 2001 at 10:41:07PM +0200, Ove Kaaven wrote:
Well, that's not in Wine, at least... the Black & White installer fails after something about CLSCTX_LOCAL_SERVER that's not implemented. Do you mean it's in the Corel tree?
CLSCTX_LOCAL_SERVER and CLSCTX_REMOTE_SERVER are the class context types that are not implemented yet. Some, though I'm not sure all, InstallShield v6 installers use that feature of ole. So no, the installer for Black & White, and pretty much any recent game that uses InstallShield, probably will not work.
-
Andreas Mohr -
Dan Kegel -
Daniel Walker -
Gavriel State -
Jeremy White -
Juergen Schmied -
Marcus Meissner -
Mike Bond -
Ove Kaaven