I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in wine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?)
There is another problem. It's with the TypeLib information in the IKernel.exe that comes with InstallShield v6. The TypeLib information is encoded somehow, any ideas? I was able to get around that problem because installshield also looks for type information in "ikernel.tlb" . So I was able to create a .tlb that worked. I also used the reaktivate typelib patch so the typelib info gets put into the registry.
So the way I understand it is that when CoGetClassObject is called Wine is suppose to , in this case, execute IKernel.exe . Then IKernel.exe will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) .. Then we would also need to send an instance of the class object to the Wine server (Yeah??) .. Following that road seems to lead to some messy address translations for DLL's and whatever else..
Since we have complete control over how IKernel.exe is run, how would we get the two processes to share memory? Maybe have IKernel.exe execute in a thread? IKernel.exe doesn't do anything but register it's class objects .. Would it be possible to treat IKernel.exe as a DLL then run CoRegisterClassObject for it?
Daniel Walker
So the way I understand it is that when CoGetClassObject is called Wine is suppose to , in this case, execute IKernel.exe . Then IKernel.exe will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) .. Then we would also need to send an instance of the class object to the Wine server (Yeah??) .. Following that road seems to lead to some messy address translations for DLL's and whatever else..
Please read the Introduction to OLE , especially the messy and very hard understandable parts on Proxies and Stubs and Marshalling.
This is what is basically needed to implement :/
Ciao, Marcus
Marcus Meissner wrote:
Please read the Introduction to OLE , especially the messy and very hard understandable parts on Proxies and Stubs and Marshalling.
This is what is basically needed to implement :/
Where is that, the Introduction to OLE?
Maybe this is laughable , but it seems like we should be able to eliminate the Marshaling since we're dealing with something that is effectively a DLL .. Maybe I'm misguided in thinking that it's "effectively a DLL" ?
Daniel Walker
On Thu, Jul 19, 2001 at 08:40:25AM -0700, Daniel Walker wrote:
Marcus Meissner wrote:
Please read the Introduction to OLE , especially the messy and very hard understandable parts on Proxies and Stubs and Marshalling.
This is what is basically needed to implement :/
Where is that, the Introduction to OLE?
It was part of the MSDN Library or available as a book. Dunno where it got to. (Check msdn.microsoft.com)
Maybe this is laughable , but it seems like we should be able to eliminate the Marshaling since we're dealing with something that is effectively a DLL .. Maybe I'm misguided in thinking that it's "effectively a DLL" ?
No, we need an extra process.
The 'Dll only' approach is an 'in-process' server, these already work.
Ciao, Marcus
Where is that, the Introduction to OLE?
It was part of the MSDN Library or available as a book. Dunno where it got to. (Check msdn.microsoft.com)
I think the book you guys are talking about is "Inside OLE", Microsoft Press, by Kraig Brockschmidt. Available for free in CD version of MSDN, not sure about online. Other books to check out are "Inside COM" from MS Press (not sure the author), and "Programming Applications for Windows" by Richter goes into some of the messy stuff involving thread, processes, etc..
-James
The only description I've seen of how COM is actually implemented by Microsoft apart from msj articles is in Don Box's book "Essential COM" (possibly the self- same articles reprinted in his book), which I found to be the most informative book on the subject.
Inside COM by Dale Rogerson is mistitled, IMO, as it is simply a description of how to write COM clients/ servers.
----- Original Message ----- From: "James Hatheway" james@macadamian.com To: wine-devel@winehq.com Sent: Thursday, July 19, 2001 7:45 PM Subject: Re: CoGetClassObject
Where is that, the Introduction to OLE?
It was part of the MSDN Library or available as a book. Dunno where it
got to.
(Check msdn.microsoft.com)
I think the book you guys are talking about is "Inside OLE", Microsoft Press, by Kraig Brockschmidt. Available for free in CD version of MSDN, not sure about online. Other books to check out are "Inside COM" from MS Press (not sure the author), and "Programming Applications for Windows" by Richter goes into some of the messy stuff involving thread, processes, etc..
-James
James Hatheway james@macadamian.com ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. "Software solutions for leading ISVs and e-Business"
"richard.morgan9" wrote:
I think the book you guys are talking about is "Inside OLE", Microsoft Press, by Kraig Brockschmidt. Available for free in CD version of MSDN, not sure about online. Other books to check out are "Inside COM" from MS Press (not sure the author), and "Programming Applications for Windows" by Richter goes into some of the messy stuff involving thread, processes, etc..
The only description I've seen of how COM is actually implemented by Microsoft apart from msj articles is in Don Box's book "Essential COM" (possibly the self- same articles reprinted in his book), which I found to be the most informative book on the subject.
Another interesting book is "COM IDL & Interface Design" by Al Major. It goes into great detail about how type libraries and marshalling work. http://www.amazon.com/exec/obidos/ASIN/1861002254 One of the amazon reviews calls it "god's gift to those who --pay attention, please-- want to achieve an in-depth understanding of the marshalling issues as applied to MS COM."
- Dan
On Thu, 19 Jul 2001, Daniel Walker wrote:
I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in wine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?)
I'm working on it. In my tree, CoGetClassObject successfully launches ikernel.exe and establishes an IPC connection to it, and queries it for the CLSID that installshield wants. That works fine, but that's just the easy part. Currently the service process (ikernel.exe) can't yet send a reply, since interface marshalling is not quite implemented yet... and I'm not entirely sure how typelibs work yet, and how to retrieve the typelib info for a CLSID.
will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) ..
Not necessarily.
Since we have complete control over how IKernel.exe is run, how would we get the two processes to share memory? Maybe have IKernel.exe execute in a thread?
No. There's no reason to share memory either, we're supposed to do it like Windows does it and it doesn't share memory. It uses proxy objects, created by marshalling the interface across.
IKernel.exe doesn't do anything but register it's class objects .. Would it be possible to treat IKernel.exe as a DLL then run CoRegisterClassObject for it?
I don't know how you're going to get that to work, CoRegisterClassObject needs pointers to application structures, which only ikernel.exe's startup code knows. And you probably *still* won't be able to load it into the same address space as the installer, for reasons known to everyone that eagerly awaited the big Address Space Separation.
Ove Kaaven wrote:
On Thu, 19 Jul 2001, Daniel Walker wrote:
I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working inwine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?)
I'm working on it. In my tree, CoGetClassObject successfully launches ikernel.exe and establishes an IPC connection to it, and queries it for the CLSID that installshield wants. That works fine, but that's just the easy part. Currently the service process (ikernel.exe) can't yet send a reply, since interface marshalling is not quite implemented yet... and I'm not entirely sure how typelibs work yet, and how to retrieve the typelib info for a CLSID.
I had to use a separate "ikernel.tlb" to get Wine to read the type information. It couldn't get it from the ikernel.exe because I think it's encoded somehow (unicode, MultiByte??). It doesn't have the magic MSFT as the first four bytes.. Wine seems to read all the type information correctly ..
So then in CoGetClassObject you would create and return a dummy object that would act like the actual interface the program is looking for. Then the dummy object would accept parameters, do the marshaling, and make the IPC request to the Local Server?
Daniel Walker
On Thu, 19 Jul 2001, Daniel Walker wrote:
I had to use a separate "ikernel.tlb" to get Wine to read the type information.
Where did you get that .tlb file from, and could you send it to me?
It couldn't get it from the ikernel.exe because I think it's encoded somehow (unicode, MultiByte??).
It doesn't look encoded, it's just different (it's most likely what is boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this new format (it has a "SLTG" signature instead of the old "MSFT").
So then in CoGetClassObject you would create and return a dummy object that would act like the actual interface the program is looking for. Then the dummy object would accept parameters, do the marshaling, and make the IPC request to the Local Server?
Something like that, except it's called a "proxy", not a "dummy object".
On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote:
It couldn't get it from the ikernel.exe because I think it's encoded somehow (unicode, MultiByte??).
It doesn't look encoded, it's just different (it's most likely what is boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this new format (it has a "SLTG" signature instead of the old "MSFT").
SLTG is the old format, MSFT came later. Wine can (natively) only read MSFT.
I have no knowledge of a still newer format.
Rein.
On Tue, 7 Aug 2001, Rein Klazes wrote:
On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote:
It couldn't get it from the ikernel.exe because I think it's encoded somehow (unicode, MultiByte??).
It doesn't look encoded, it's just different (it's most likely what is boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this new format (it has a "SLTG" signature instead of the old "MSFT").
SLTG is the old format, MSFT came later. Wine can (natively) only read MSFT.
Allright, but the most important question remains: who will volunteer to reverse engineer these SLTG typelibs and make Wine able to read them, so I can concentrate on the actual COM marshaling stuff (which is pretty hard enough as it is), so we can finally get those @#&% InstallShields up?
On Tue, Aug 07, 2001 at 08:55:41AM +0200, Ove Kaaven wrote:
On Tue, 7 Aug 2001, Rein Klazes wrote:
SLTG is the old format, MSFT came later. Wine can (natively) only read MSFT.
Allright, but the most important question remains: who will volunteer to reverse engineer these SLTG typelibs and make Wine able to read them, so I can concentrate on the actual COM marshaling stuff (which is pretty hard enough as it is), so we can finally get those @#&% InstallShields up?
Does anybody know how to generate files in SLTG format? Is there an old version of mktypelib or something? If anybody has anything useful about the format could they let me know.
Thanks, Huw.
On Tue, 7 Aug 2001 11:35:49 +0100, you wrote:
On Tue, Aug 07, 2001 at 08:55:41AM +0200, Ove Kaaven wrote:
On Tue, 7 Aug 2001, Rein Klazes wrote:
SLTG is the old format, MSFT came later. Wine can (natively) only read MSFT.
Allright, but the most important question remains: who will volunteer to reverse engineer these SLTG typelibs and make Wine able to read them, so I can concentrate on the actual COM marshaling stuff (which is pretty hard enough as it is), so we can finally get those @#&% InstallShields up?
Does anybody know how to generate files in SLTG format? Is there an old version of mktypelib or something? If anybody has anything useful about the format could they let me know.
Thanks, Huw.
midl /oldtlb yourtypelib.tlb
Rein.
-
Dan Kegel -
Daniel Walker -
Huw D M Davies -
James Hatheway -
Marcus Meissner -
Ove Kaaven -
Rein Klazes -
richard.morgan9