Image of Navigational Map linked to Home / Contents / Search An Application Distribution Engine

by Stephan Grieger - GUI Computing
Image of Line Break

The greatest thing to hit the Developers desk in the last year or so would have to be DCOM. With it, you can have your application and OLE Servers residing on a server. It basically eliminates the need for your application to be installed on every desktop that is going to use it.

However, having said that, the conditions needed for this are often far out of reach. For example. Each PC must be running Win '95 or better. You must have access to VB 4 32bit or VB 5. You can't use any DLLs or VBXs or OCXs that need to be in the System directory or that require a license file on the user's desktop. There are a heap of others but you get the nightmare.

So, were back to the problem of, 'OK, I've made a significant change to the application...' or 'OK, that 2000 bug is now fixed...' '... how do I distribute the new version to everyone using my software?'.

The traditional approach is to create a setup disk using something like WISE-Is-Choice, and making that Setup available to other users. There are two hundred of them.

The problems with that are that you may have made a database change and the users need to install your setup before they can continue using your app, or not every user is going to apply your patch and so client versions are going to get out of date. Add to that the fact that this may happen more than once or the user isn't really that computer literate, and you have a real danger of the users attacking your software as rubbish or at best unusable. You really don't need that kind of advertising.

So, what do you do?

Well, we came up with a methodology that actually works very, very well indeed. It's a little complex to explain, but well worth it.

Let's make a few assumptions to begin with :

The idea is that you have a small application called Version.Exe installed onto the user's desktop. Your application icon points to that .exe rather than the main one.

When the user double clicks your application icon, Version fires up, checks a certain table in the database and verifies if any updates are to be made on the main client system. If there are, it makes the changes, logs the changes as being made and then launches the main executable. Simple.

The way we did this was to emulate Wise. Yes, that's right, we took the syntax that Wise generates and saves into its .WSE file and created an engine which can read and process it. We call this the 'Script'. Original name yes?

We then place that script in a table called 'ServiceScripts' in the main database. The script has a unique number assigned to it. Version checks that table, checks its own INI file and dertermines which scripts have not been run. It then processes those and logs them in the INI file as being run.

The scripts that we generate do everything from Edit INI files, Install files, show messages & graphics, delete files, execute programs etc etc etc. Basically, it has the capability to do pretty much everything you need to upgrade the client system.

The code for this has been included with this article as well as the help file for making your own scripts and the ServiceScripts table.

Now we are the first to admit that this Version application is not perfect. Far from it actually. If there is a problem with the syntax of the script itself, Version will probably die a tragic death. But, let's face it, the only people changing scripts are programmers so end of problem really.

All right, maybe not a great attitude. For this reason, the Version application is also an OLE Server which has an API called iClose. Calling this closes the Version application down.

The reason for this is that we may actually want to update the Version program itself at some time. So,

All this is probably very confusing. Indeed, it took us a couple of hours to come up with the concept and to understand it properly. It then took several scotches to clear the headache the concept caused.

The best thing to do is dive into the code and look at the examples to get an understanding of what is happening. Be gentle with the code analysis as it was designed for a particular application and it was assumed that the scripts be written by a programmer or at least someone who knows what they were doing.

One more thing. Your main application must be an OLE server which exposes a version number API.

Each script must have an app version as its first line. The Version program gets the client's version number and checks it against the script's version. If the script version >= clients version, and the script has not been run, then the script is executed, otherwise it's ignored.



Written by: Stephan Grieger
July '97

Image of Arrow linked to Previous Article Image of Arrow linked to Next Article
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]