Misha wrote:
[I have the scripting required by the Vector NTI and the iTunes 7 installers working. What should I do next?]
First off, congratulations!
If you're interested in continuing to work on MSI, I'd suggest asking James Hawkins for suggestions.
If you're more interested in adding COM interfaces to things, perhaps implementing the iTextServices api to riched20 would be useful. Maarten got started on that, but I think it's not complete enough for say, Google Talk to function.
Most useful of all might be for you to look at improving our COM implementation itself. Rob Shearman could give you suggestions on where to start there. - Dan
On Mon, 2007-05-21 at 08:23 -0700, Dan Kegel wrote:
Misha wrote:
[I have the scripting required by the Vector NTI and the iTunes 7 installers working. What should I do next?]
First off, congratulations!
If you're interested in continuing to work on MSI, I'd suggest asking James Hawkins for suggestions.
If you're more interested in adding COM interfaces to things, perhaps implementing the iTextServices api to riched20 would be useful. Maarten got started on that, but I think it's not complete enough for say, Google Talk to function.
Most useful of all might be for you to look at improving our COM implementation itself. Rob Shearman could give you suggestions on where to start there.
- Dan
Thanks Dan for your thoughtful descriptions, I will have to mull over where to head next.
I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff:
The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it.
Now I really don't understand this or whether this is still the plan for custom actions (James?) or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else...
Thanks Misha
On 5/21/07, Misha Koshelev mk144210@bcm.edu wrote:
I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff:
The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it.
Now I really don't understand this or whether this is still the plan for custom actions (James?)
It's still the plan, and James is going to be working on it.
or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else...
I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.) - Dan
On Mon, 2007-05-21 at 10:05 -0700, Dan Kegel wrote:
On 5/21/07, Misha Koshelev mk144210@bcm.edu wrote:
I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff:
The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it.
Now I really don't understand this or whether this is still the plan for custom actions (James?)
It's still the plan, and James is going to be working on it.
or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else...
I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.)
- Dan
I guess I would definitely like to learn more about this, then, as it seems like this, per Mike's comment, would require all the automation functions to be implemented, and I wouldn't mind to keep working on this as I've already got a good tempo going with it and it is kind of nice to make/design a whole part together like this. Plus I feel like I'm catching a fair number of msi bugs in other areas (mostly registry.c) through my conformance tests for automation.
But I would definitely like to know more about it, as right now I don't really see how this separate custom action queue would be calling automation objects or why...
Misha
On Mon, 2007-05-21 at 10:05 -0700, Dan Kegel wrote:
On 5/21/07, Misha Koshelev mk144210@bcm.edu wrote:
I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff:
The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it.
Now I really don't understand this or whether this is still the plan for custom actions (James?)
It's still the plan, and James is going to be working on it.
or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else...
I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.)
- Dan
I guess the bottom line is I don't mind eventually implementing _all_ the automation functions as long as I know that I'm not just wasting my time (i.e., if these actions are only required by installer scripts, and I bet most installer scripts do not even use most of the functions).
Misha
On 5/21/07, Misha Koshelev mk144210@bcm.edu wrote:
I guess the bottom line is I don't mind eventually implementing _all_ the automation functions as long as I know that I'm not just wasting my time ...
I doubt anyone knows the complete set of those functions that actually get used by real-world installers.
I think your choice is either a) keep plugging along on msi automation on the theory that it's good for msi in general and might help a few as yet unknown apps, or b) put this on the back burner and go work on something known to be blocking some app you care about. - Dan
On Mon, 2007-05-21 at 13:49 -0700, Dan Kegel wrote:
I doubt anyone knows the complete set of those functions that actually get used by real-world installers.
I think your choice is either a) keep plugging along on msi automation on the theory that it's good for msi in general and might help a few as yet unknown apps, or b) put this on the back burner and go work on something known to be blocking some app you care about.
- Dan
Thanks Dan.
One more question: Will the COMification of msi somehow require OLE automation, as Mike's email excerpt seems to suggest (this would be another reason then to continue implementing it)? If so, how?
It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process.
(from Mike's email)
Thanks Misha
p.s. meanwhile, I hope to submit a few shlexec.c patches in the next couple of days/week as some of the DDE stuff does not seem to work as native and this leads to a very minor Vector NTI problem
On 5/22/07, Misha Koshelev mk144210@bcm.edu wrote:
One more question: Will the COMification of msi somehow require OLE automation, as Mike's email excerpt seems to suggest (this would be another reason then to continue implementing it)? If so, how?
It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process.
(from Mike's email)
Shucks, I don't know, you'd have to ask Rob / James / Mike.
p.s. meanwhile, I hope to submit a few shlexec.c patches in the next couple of days/week as some of the DDE stuff does not seem to work as native and this leads to a very minor Vector NTI problem
Sounds good to me. - Dan
Misha Koshelev wrote:
One more question: Will the COMification of msi somehow require OLE automation, as Mike's email excerpt seems to suggest (this would be another reason then to continue implementing it)? If so, how?
I believe James is planning to implement it, but it doesn't really make sense to use the OLE automation objects because: 1. There is no Package object. 2. The methods have to closely resemble those of the C interface to avoid different behaviour.
On Tue, 2007-05-22 at 16:06 +0100, Robert Shearman wrote:
Misha Koshelev wrote:
One more question: Will the COMification of msi somehow require OLE automation, as Mike's email excerpt seems to suggest (this would be another reason then to continue implementing it)? If so, how?
I believe James is planning to implement it, but it doesn't really make sense to use the OLE automation objects because:
- There is no Package object.
- The methods have to closely resemble those of the C interface to
avoid different behaviour.
Ok, this is what I thought... that is why I had the hardest time trying to figure out what Mike meant in his email.
Misha
-
Dan Kegel -
Misha Koshelev -
Robert Shearman