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

[Misha Koshelev]

On Thu, 2007-03-01 at 15:36 -0800, James Hawkins wrote:
> 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.
> 

Ok, I'll do it this way. Thanks for the comments about the info leak and
strdupAtoW, that makes my first patch a lot shorter. I posted the new
set on wine-patches, if you have any more comments please let me know.

Thanks
Misha