tag:blogger.com,1999:blog-9537945.post8083207598809533436..comments2007-11-02T20:55:50.790-05:00Christopher Painterhttp://www.blogger.com/profile/12167478740431444267chrpai@yahoo.comBlogger6125tag:blogger.com,1999:blog-9537945.post-70289299647700038562007-11-02T20:55:00.000-05:002007-11-02T20:55:00.000-05:00InstallScript mostly looks like C to me, although you are right there are aspects that look like Pascal and later VB and C#. I guess it all looks the same to me after awhile. ( I've done C,VB/Script,Powerbuilder,Deplhi,C#/VB.NET over the years... )<BR/><BR/>Being a Domain Specific Language, InstallScript does lack certain capabilities. For example, there is no concept of function pointers and as you point out callback patterns ( although the LaunchAppAndWait does have a callback mechanism for calling EXE's ).<BR/><BR/>I've never actually had the need for this, but I suppose if you did, you could write a Type 1 CA in C++ and invoke it passing the MSI Handle. Once inside your C++ you could do the callback and pump messages back to the UI via the installer handle.<BR/><BR/>Do you have a use case for this or was it just an observation?Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-9537945.post-12856544270733806032007-11-02T19:46:00.000-05:002007-11-02T19:46:00.000-05:00Hmmm, I always thought InstallScript resembled Pascal...<BR/><BR/>Some interesting points were raised, however, remember that even InstallScript has 'UseDLL()'. If you have to interact with the system, then there are many parts of the Windows API that IS cannot properly deal with (callback functions?).Presuttihttp://www.blogger.com/profile/02039722574801193427noreply@blogger.comtag:blogger.com,1999:blog-9537945.post-18334567540668941402007-10-31T09:50:00.000-05:002007-10-31T09:50:00.000-05:00Don't forget that it's easier to debug (Build -> Debug versus set environment variable, launch installer, attach debugger, debug installation, forget to remove environment variable, cancel installation, delete environment variable, need it later, blah blah blah) and the language has patterns for almost any imaginable situation including leveraging .NET Custom code.<BR/><BR/>That said, it's been nearly impossible to decompile the bytecode for quite a long time.ShadowWolfhttp://www.blogger.com/profile/17170306422408594103noreply@blogger.comtag:blogger.com,1999:blog-9537945.post-9763516416052547562007-10-25T23:48:00.000-05:002007-10-25T23:48:00.000-05:00Right. I only do C++ custom actions as they are easy. I was wondering if your CA logic is out in the open with Installscript. Probably just a mater of time before Installshield or someone else releases a decompiler.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9537945.post-42671341471813940752007-10-25T06:13:00.000-05:002007-10-25T06:13:00.000-05:00In the old days there used to be an InstallScript decompiler but as far as I know, there isn't these days.<BR/><BR/>Some people like obfusacated code and some people like transparent code. InstallShield ( and C++ ) leans towards the first while scripting languages and .NET lean towards the latter.<BR/><BR/>If you make your CA data driven, you can somewhat expose the behavior via the table data, but the implementation is still private inside the CA.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-9537945.post-42109519084578806302007-10-24T23:40:00.000-05:002007-10-24T23:40:00.000-05:00is it possible to extract the original InstallScript out of a compiled InstallScript CA?Anonymousnoreply@blogger.com