>>I've reviewed both Doug's and Nick's applauncher files but want to ask some general questions about app launchers at the risk of asking the obvious.
>>
>>Typing out loud here.....
>>
>>---------
>>
>>Lets say my 'real' EXE is called MY.EXE. The launcher exe is called LAUNCHMY.EXE.
>>
>>During the FIRSTTIME app install, i would want to install:
>>
>>- MY.EXE into "MyApp\Source" folder (granted it could be anything)
>>- LAUNCHMY.EXE into "MyApp\LatestExe" folder.
>>
>>Any future releases of the program get installed into the "MyApp\LatestExe" folder (including other files like the DBC files, new DBFs, SDT stuff, help files, ...).
>
>>
>>Instead of the users running MY.EXE, they run LAUNCHMY.EXE instead. So installshield needs to build an app icon for LAUNCHMY.EXE instead.
>
>
>CORRECT.
>
>>
>>When LAUNCHMY.EXE is run, it compares the following 2 files (maybe others):
>>
>>MyApp\Source\MY.EXE
>>MyApp\LatestExe\MY.EXE
>>
>>and copies the newer files from the "MyApp\LatestExe" folder to the "MyApp\Source" folder. And finally, LAUNCHMY.EXE runs MY.EXE.
>>
>
>I think you're making this harder than it needs to be. There's no benefit to copying the files from the server to a local drive and THEN performing a comparison. I'm familiar with Nick's launcher, and with it the comparison is performed directly between the "latest" files on the server and the local files in MyApp\Source. This fast and simpler than what you're proposing.
>
>>=========
>>Questions
>>=========
>>1) are there any SDT issues with this setup?
>>2) is there a way to prevent users from running MY.EXE when they should be running LAUNCHMY.EXE instead? Can the program stack be checked?
>
>The launcher won't be in the program stack, so you can't check for that. My users don't intentionally pick a harder way when I've shown them the easy/right way, but yours may be more ornery than mine. You might try naming MyApp.exe something like MyApp.ex_, and renaming it in your launcher. That way, users could set a shortcut to MyApp.Ex_ but it wouldn't run.
>
>>3) what performance improvements are common when users have the EXE local on their drive?
>
>Depends on network speed, network traffic and the size of the EXE their running. It can make a big difference, depending on those variables. Local storage is a big benefit if users start/quit/restart the same app repeatedly during the day. If they have enough RAM, the local EXE can remain in cache and therefore reload very quickly. It's easy for you to test in your particular situation. Just use a stopwatch to time it both ways.
>
>
>>4) if a user is running LAUNCHMY.EXE (which runs MY.EXE), does the "START IN" value of the program shortcut suffice for "locating" the user to the correct path?
>
>"Start In" won't matter unless the launcher goes to the local hard disk looking for files, such as an INI file. If the only files it looks for are on the server, "start in" doesn't matter. Of course, this is dependent on which launcher you use and it's particular implementation.

I agree with all that. In general it is very easy for EXE to check how it was run. You may add another parameter to it which will be passed if it is run from the Launcher, and not there if the user directly runs EXE from Windows Explorer.
Of course, there may be a smart user which will pass the parameters (if he knows what they are) manually from his own shortcut. I myself do this sometimes in testing purposes.

My latest launcher version (not posted yet) also passes another optional parameter which is the name of INI file. Then diferent versions of EXE (and different sets of other files) may be copied/checked. This allows to run several applications from the same directory with one launcher.

Also, the Launcher now checks for certain file (i.e. SHUTDOWN.TXT) presence and may prevent application from launching, if there the maintenance has to be done on the app. The app itself contains the timer which checks for the same files but in another directory. That allows to selectively prevent new users access and/or shutdown the application and kick all users out if necessary.