tag:blogger.com,1999:blog-985159635193633235.post1732595537621762016..comments2024-03-25T00:30:02.127-07:00Comments on ISWIX: More Interesting and Uninteresting CommentsChristopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-985159635193633235.post-23163145252799218072007-11-30T06:30:00.000-08:002007-11-30T06:30:00.000-08:00Hi Carl- I'm the first to acknowledge that th...Hi Carl-<br> I'm the first to acknowledge that the *old* InstallScript engine had major DCOM/ROT problems. I wrote a blog on this subject where I pointed out that the problems were so bad that they created a support site on their own. But I feel it's a bit dishonest to use this as a reason to hate InstallScript considering that the complete redesign that occurred in IS12 was nearly 2 years ago. I'm sorry, but mentioning this and IS7 suggests to me that you are living in the past.<br>Rob's comments have to do with design. It's not InstallShield's fault if a developer writes anti patterns. ( See OMG, InstallShield Killed Kennedy ) A developer could just as easily write an MSI anti pattern in C++, VBScript, and/or Installer Class CAs.<br>Now about your comment of `MSIs are open format database`. That is correct, the database and only the database are open. The standard actions that process the data are completely closed source. You have no idea how they do what they do other then what the contract with the data tables suggest that they will do for you.<br>Nothing stops you from writing a data driven CA in InstallScript that is essentially the same as above. You can expose the points of variability as data tables and document them to your customer as to which action processes the table and what the rows mean. This is the interface or contract if you would. The implementation ( InstallScript and/or C++ source code ) does not need to be exposed to live up to the same standards as MSI itself. <br>If you feel you need to expose the actual implementation source, then write in VBScript. The only problem there is Script CAs are every bit as unreliable as the old InstallScript CAs so I find it interesting that you would accept this risk while holding InstallShield to the fire.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-74896431599106384012007-11-30T12:35:00.000-08:002007-11-30T12:35:00.000-08:00Chris,I'm not weighing in on the InstallScript...Chris,<br>I'm not weighing in on the InstallScript CA issue per se (you already know I don't like them, for many of the same reasons Carl listed). I just wanted to point out your reply to Stefan's size issue is really only valid for large packages (as you said). However, consider the upcoming MSI 4.5 chaining ablities. You will now be able to write an external UI handler to process multiple MSI installations, which (IMHO) would lead to [multiple] small size MSI packages being used to contain the components associated with specific features (see the MS Office 2007 install for an example). Assuming that is correct, now the overhead of InstallScript does come into play because the InstallScript engine is in multiple packages (unless Macrovision does something to counter this like providing an IScript Engine redistributable MSI that can be installed as a pre-req). Just my 2¢Colby Ringeisenhttp://www.blogger.com/profile/08696301684260588101noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-43013840193355922882007-11-30T13:52:00.000-08:002007-11-30T13:52:00.000-08:00I agree, in a micropackaged chained setup environm...I agree, in a micropackaged chained setup environment, the cummulative overhead could be considerable.<br><br>But consider this, C++ Type 1 CA's written in Visual Studio 2005 have the same problem. The general consensus now is to statically link the CRT libs into your DLL to avoid dependency problems at runtime. This add's about 1MB to the CA DLL.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.com