neverblog.net

InstallShield 11.5 provides an easy way to search the registry for a desired value

Oftentimes when creating a new installer, it is necessary to provide for the contingency of previously installed software that will need to be removed. This can be a previous version of the same software (although those modules should maintain the same unique IDs, making this extra procedure unnecessary) or it can be a piece of software that will conflict with the software you’re trying to install (i.e. an old anti-virus program). Either way, in order to effectively remove the software, you’re going to need to:

1) Search for the program’s existence, and
2) Run its UninstallString from the registry.

Thankfully, InstallShield provides a couple of easy ways to accomplish this. The first (ideal) way to run the other software’s uninstaller is to do a simple system search for the registry key UninstallString for the program you wish to remove. The advantage to this method is that the search is very specific–it only looks within a particular key–so you can easily do 100 of these searches in the course of an install. In order to create the appropriate Custom Action within your MSI in this manner, do the following:

1) In the ‘System Search’ screen, add a new search by right-clicking and choosing ‘Add…’ (or hit Ins).
2) Choose ‘File Path, as specified by a registry entry’ at the next screen.
3) For the Registry Root choose ‘HKEY_LOCAL_MACHINE’
4) For the Registry Path type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\**ProgramName**’ (in other words, to uninstall Macromedia Flash, type ‘SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Macromedia Shockwave Player’
5) Under the optional Registry Value field, type ‘UninstallString’
6) Pick a memorable name for your new file-path variable like FLASH8PATH, then choose the top option to only store it in the tables, not use it as an install condition (you will attach the custom action later).

Your System Search is now complete, and will look for the UninstallString for Flash Player, then store that value to the variable FLASH8PATH. If you wish, you can immediately use this variable to create Install Conditions for different Custom Actions, either as an exists/does not exist check that launches an .exe or something, or by using the actual path contained in the variable. To launch the uninstaller, create the following Custom Action:

Working Directory: SystemFolder
Filename & Command Line: FLASH8PATH
Return Processing: Synchronous (Ignores exit code)
In-Script Execution: Immediate Execution

NB: You need to schedule the Custom Action after the AppSearch action in the InstallExecute sequence, because that’s when the MSI checks the registry for the key…it will fail otherwise.

systemfolder, custom action, msi, windows installer, previously installed, anti-virus, installshield 11.5, installshield, search registry, registry, installer, appsearch, installexecute, .msi, uninstallstring, variable, install conditions, uninstaller

Hiding JavaScript so that visitors can’t see it might not seem like a necessary precaution to take in most web programming situations. After all, a server-side language like PHP automatically prevents users from seeing your source code, and increasing functionality is quickly rendering the client-side advantages of JavaScript less significant by the day. However, there are many practical reasons to take the PHP-hidden-JavaScript approach, especially if you have long and complicated scripts that already exist and are in use, which would take a significant time commitment to revamp in PHP.
The key to this approach is to encapsulate your JavaScript in a separate PHP file, and to use a PHP session to restrict access to those scripts except when you want it to be explicitly permitted (i.e. when you want to run them from a specific page). To accomplish this, we first create a PHP session on the page from which we want to run the JavaScript.

< ?php
session_cache_limiter('none');
session_start();
if(!$_SESSION['allow_script'])
{
$_SESSION['allow_script'] = true;
}
?>

Placing this PHP at the top of your page opens a session and registers the variable ‘allow_script’ to that session, with a value of ‘true.’
The next step is to move whatever JavaScript you want to execute over to another file called ’script.php’ This file should contain your JavaScript wrapped in a PHP tag, along these lines:


< ?php
if(!$_GET['allow_script'])
{
session_start(); //restart the session from the previous page
}
if($_SESSION['allow_script']) //execute the javascript only if the variable is passed
{
header("Content-type: text/javascript");
?>
alert(”Hello World! JavaScript executed.”);

This portion of the PHP guarantees that the JavaScript generated by it does not appear to the end user, even if they navigate directly to script.php. The $_GET['allow_script'] check insures that the user is not trying to do an end-around by passing the allow_script variable with a value of ‘true’ directly to the script.php page, which would obviously allow them to view the JavaScript source.
Finally, you need to unregister the variable and close the session:


< ?php
$allow_script = false;
session_unregister('allow_script'); //delete the variable from the session
session_unset(); //make the session inactive
session_destroy(); //and toast it for IE
}
?>

NB: session_destroy() is not necessary for Firefox or Internet Explorer 6 or better, but leaving it out means that IE 5 users will be unable to reuse the script.php page without closing and re-opening the browser.
The end result of this simple process is a nicely hidden, encapsulated JavaScript that can be called with the simple line:

<script language="JavaScript" src="script.php">

Now your existing JavaScript (with all its client-side capability) can be easily referenced within your code, without leaving it vulnerable to the malicious efforts of prying eyes.