[try3, 4/4] msi: Add full JScript/VBScript support.

[James Hawkins]

On 3/1/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> On Thu, 2007-03-01 at 15:04 -0800, James Hawkins wrote:
> > On 3/1/07, Misha Koshelev <mk144210 at bcm.tmc.edu> wrote:
> > > No changes from previous version.
> > >
> > > Implements the IActiveScriptSite interface which links with the session
> > > object implemented in patch #3 and then adds a call to the script
> > > handler from the common script handling function implemented in patch
> > > #1. This fixes bug #7357 and possibly others.
> > >
> > > Changelog:
> > >
> > >         * msi: Add full JScript/VBScript support.
> > >
> >
> > +static HRESULT ASS_create(IUnknown *pUnkOuter, LPVOID *ppObj)
> > +{
> >
> > I'm not trying to be immature, but you should probably come up with a
> > better prefix.
> >
> > + * Call a script. This is our meat and potatoes.
> > + *     - Currently, since the function is relatively new, it will
> > always end up returning S_OK.
> > + *       Think of it like a bonus feature, we can run the script -
> > great. If we have a problem,
> > + *       we are no worse off than if this function had not been called.
> > + */
> > +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR script,
> > LPCWSTR function, LPCWSTR action)
> > +{
> > ...
> > +/*    return ret;  */
> > +    return ERROR_SUCCESS;       /* FIXME: Until thoroughly tested,
> > always return success */
> >
> > This is wrong...and a hack.  Don't be afraid of bugs.  By always
> > returning ERROR_SUCCESS, you're just hiding the bugs.  What testing
> > are you referring to?  If a user runs an installer and the script
> > fails, yet we return ERROR_SUCCESS, how are we going to know that the
> > script is the problem?
> Well for one thing, until the entire OLE automation interface is
> implemented and not just a partial implementation, scripts might fail
> because a method has not been implemented yet. Plus, the current
> behavior of the installer is to just make a FIXME with an unhandled
> custom action but it continues anyhow without just stopping the
> installation. It seems like this would be the analogous thing to do
> until the whole OLE automation interface is implemented. What do you
> think?
>

The number of installers with scripted custom actions is limited
compared to those without.  I also don't know of any installer that
requires scripting but will succeed if the scripting is not
implemented.  This should be implemented correctly the first time, and
if a certain installer doesn't work because of an unimplemented
function/object, then we implement the function/object.  You're
missing the point that we hide bugs with hacks like this.

-- 
James Hawkins