Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

InstallScript. What impact on the target machine?


5 replies to this topic

rosario100

rosario100
  • Members
  • 15 posts

Posted 28 February 2006 - 16:49

Hi

Can someone please explain what impact has writing CA in InstallScript, VBScript or JScript using InstallShield. I suspect that probably the target machine needs to have the corresponding engine installed but I can't find any documentation on the web.

I have written a lot of CA with InstallScript as I am converting an already existing app from an InstallScript project to an MSI, but I'd like to make my APP quite standard, I mean I'd like the msi worked also on machine where no previous InstallShield setup has run, what I need to include in my setup to get that avoiding to translate all the scripts in VBScript (which should always be enabled on the target machine)?

Thanks

Rosario

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 28 February 2006 - 18:41

Yes you would need the corresponding scripting engine on the target machine. InstallShield will automatically install the InstallScript engine is needed, which adds overhead to your setup, sometimes causes errors, and may require admin privileges. VBScript and JScript engines are typically present on Windows but might be disabled to protect against scripting viruses. Also some anti-virus programs (Norton) might block VBScript 8and probably also JScript) custom actions.
The best way is a DLL written in C. This has the least overhead, least dependencies and is most robust.

rosario100

rosario100
  • Members
  • 15 posts

Posted 28 February 2006 - 18:51

Thank you

I'd like to take the overheads off of my setup but I find very quick (I have an impossible deadline) to write CA in InstallScript but I suppose I have to add the "InstallShield scripting engine ver ...." (merge module) to my redistributable do I? Which add other overheads, but I can change the scripting at a later stage.

Why the dll's have to be in C? What about Delphi?

Rosario

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 28 February 2006 - 21:13

If you are not using setup.exe then you would need the merge module.

I'm not too familiar with Delphi. You will need a DLL that exports callable functions, so DLLs created with VisualBasic for instance won't work because they are really ActiveX.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 28 February 2006 - 21:33

Delphi is OK. I prefer "Windows Installer DLL" over "Standard DLL", because you get much more control. (The distinction is made by InstallShield, you can select either type).
When choosing Windows Installer DLL, you need translated headers of Msi.h, Msiquery.h etc. Project Jedi has these in the Platform SDK project. Every exported function in your DLL should look like:

function MyFunction(hInstall: MSIHANDLE): UINT; stdcall;

Note the parameters and the calling convention.

rosario100

rosario100
  • Members
  • 15 posts

Posted 01 March 2006 - 11:13

Thanks Zweitze and Stefan

I am quite familiar with Delphi, not much in C or C++. Problem is you need an extra compiler anyway and I suppose debugging is going to be more difficult I appreciate that this take off several scriptin overheads.

Rosario