On 3/1/07, Misha Koshelev mk144210@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?
+static HRESULT WINAPI MsiActiveScriptSite_GetLCID(IActiveScriptSite* iface, LCID* plcid) +{ + MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface; + TRACE("(%p/%p)->(%p) stub!\n", This, iface, plcid); + return E_NOTIMPL; +}
If it's a stub, it needs to be marked with a FIXME.
On Thu, 2007-03-01 at 15:04 -0800, James Hawkins wrote:
On 3/1/07, Misha Koshelev mk144210@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 willalways 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?
+static HRESULT WINAPI MsiActiveScriptSite_GetLCID(IActiveScriptSite* iface, LCID* plcid) +{
- MsiActiveScriptSite *This = (MsiActiveScriptSite *)iface;
- TRACE("(%p/%p)->(%p) stub!\n", This, iface, plcid);
- return E_NOTIMPL;
+}
If it's a stub, it needs to be marked with a FIXME.
Misha
On 3/1/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Thu, 2007-03-01 at 15:04 -0800, James Hawkins wrote:
On 3/1/07, Misha Koshelev mk144210@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 willalways 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.
On Thu, 2007-03-01 at 15:36 -0800, James Hawkins wrote:
On 3/1/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Thu, 2007-03-01 at 15:04 -0800, James Hawkins wrote:
On 3/1/07, Misha Koshelev mk144210@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 willalways 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
-
James Hawkins -
Misha Koshelev