Or a slightly modified version of this could be that the user's installed shortcut simply points to a "boot-strap" program which checks an ini file for which executable to run and launches that program. New updates simply modify the ini file to point to the latest exe. You would have to go though and clean out old executables at a later date when you are sure no-one is running them.
You could even have the executables themselves check the ini file and give a message such as "a newer version of this program is available, please close down this application and restart it to run the latest version". regards, Phil. ----- Original Message ----- From: "Paul Heinz" <[EMAIL PROTECTED]> To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> Sent: Monday, September 02, 2002 12:41 PM Subject: RE: [DUG]: Location of EXE > Eion wrote: > > > We have done that here with a couple of apps. The only things you > > have to look out for is when trying to update it with a new version, > > no user can have it running at the time. > > > Mark wrote: > > > > > Are there any Gotcha's in putting a single application .exe file on > > > a server and allowing multiple users to fire it up from there? > > That last issue can be a real hassle, especially as the user count climbs. > Also, you have the issue that the code pages are moving across the network > and consuming precious bandwidth (if only every client had switched 100BaseT > with GigE from switch to Fast Wide Ultra SCSI-3 servers :-) and also > consuming file memory cache on the server which could otherwise cache > valuable data. We try to keep our applications fairly slim and svelte but > nothing beats the performance of I/O you didn't have to do :-) > > So, in response to your resllers comments, we developed a utility called > LaunchGuard which offers a hybrid approach combining the best of both worlds > IMO (i.e. centralised updates but local cacheing). > > The core idea is that on launch the application checks a central location > (i.e. the server) for any updates and pulls them down to a cached client > copy. The up-to-date client copy is then launched. This is all largely > invisible to the user - they just click the application shortcut as usual. > Also, all the LaunchGuard infrastructure is put in place automatically as > part of the initial (and only!) client application installation and the > server application installation. > > Now, I'm not claiming this is a radical or new idea - the internet update > checks many modern applications use (e.g. some net games, anti virus > software) is the same technique. As always, the devil is in the fiddly > little details (as Wil, the main developer can confirm at length :-), but > that's the basic concept. > > It makes it very easy now for our resellers to update client sites, > especially when there is in excess of 30 possible PCs accessing the > application (including the ones that got added without their knowledge :-) > Each client cached copy will automatically update as the user goes to launch > the application. You can't get 'stale' or mismatched clients (often the bane > of database applications). > > For anyone deploying applications where they expect regular updates to be > supplied (due to either new features, requirements changes, or even <gasp> > bugfixes) and user counts are expected to often exceed 3 or so, I'd really > recommend exploring this technique. > > TTFN, > Paul. > > > -------------------------------------------------------------------------- - > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
