In the moment when, during our “career” of QL programmer, we overcome the step from creating simple softwares to more complex products, one of the problem we face is the necessity to make our softwares configurable.

The kind of configuration we want to upgrade is unrelevant if compared to the goals of the problems, starting from the colours of the window in which the software works or security settings, the way to solve that problem doesn’t change.
We have obviously different solutions, all effective but with strong and weak points very different from each other.
It is a programmer’s duty to orientate himself toward those different philosofic choices linked to his needs.
In fact, to different needs can match different solutions to the same problem
Let’s analyze now those needs We thougth a serie of a six main needs of a software programmer and we will subsequently apply to the different methods that we will analyze.

Maintain settings during the upgrade

Is the user’s needs to not reconfigure its software everytime he installs a new release. We often forget both how the configuration software works (because is used only one time) both which parareters were setted.
The main difficulties in remembering those particulars come from the sporadic use of this options

Intercommunicability between applications

Evolved applications are able to open automatically other softwares to do different operations or to use specific functions
For example I think at The Reader, which uses an editor decided by the user to write the messages.

Multiple configurations

Differently from working environments, where every user has a dedicated station, in private enviroment is normal that more persons have the access to the same computer.
Is not told that the optimal settings for one use is good also for the others: often happens the opposite and every user would like to have its own settings.
The most common result is to create an infinite serie of small discussions and after a “intermediate” setting wich in reality nobody likes at all.

Portability between OS

To the most evolved developers can be important that their application works with different operational systems. Normally, this is a not real important issue in our world. We are more oriented to import softwares from systems more and more evolved and widesrpead (mainly from linux) rather than export our applications to other platforms, where with good probability exists similar and more complete competitors.
But i find right to consider also this hypotesis, even if is secondary, in order to have a complete view of the situation.
Let’s now make a quick view of the most used methods both on our platform and not, and let’s try to relate them to the already described needs.

Executable’s alterations

Alterate the executable code using an external software is the first method appeared on our platorm.
Do you remember the four almighty PSION managment softwares?
They were setted right in that way thanks to a SuperBASIC’s software supplied toghether with the package. Let’s tell already that is not a good system.
First, everytime has to be changed some setting it was necessary to access to the configuration program (usally uninstalled due to space reasons). Then remember how it works and then act.
To the limits of this method can be added eventual limits of the configuration program.
The same can be told to the access of settings informations: it is always required to look inside the executable.
It is not told that different releases of the same programs the parts of the executable to be patched are the same. This requires results in rewriting the configuration program.

Fileconfig

Fileconfig represents the evolution on QL platforms of the system described above.
It is a block of datas written in a standard format that is inserted in head of the executable code. That block not only contains the parameters to be setted but also their description in form of question.
Let’s make an example of a pararmeter which contains the pathname of the help file. I twill have the description of the file itself in form of question or request “indiceate help’s file path”.
In order to act on the configuration’s block exsist an unique software that while analyse the block is able to adapt automatically to the specifics contained in the entire block.
This system is definetely more “user friendly” than the previous system.
Learning to use this system is not neither a big work; once selected the executable to be modified, it will be the program itself that queries the configuration block and give the question to be answered.
Compared to the first method is an enormous further step. However remanis problems connected to setting’s maintenance.
We must say that the configurator’s commercial settings, delivered by Jochen Merz (www.jms.com) is able to read the configuration block and save it on a separated file. Once installed the new release, it can insert in the new software the data already saved.

Environments variables

A totally different method from the previous is the use of environment variables. To each setting is assigned a different environment variable which is read by the software
This systems allows us to have a different serie of advantages compared to the previous solutions.
First of all, to every software’s upgrade we will not have to worry anymore of the reconfiguration. The software will configure itself automatically reading the variables.
Environment variables are public, so also the applications can read the content
To what will be useful this?
Let’s make a pratical example.
Before we named The Reader, which uses an external editor to create the messages. We have also other softwares which makes the same thing, for example C68Tools.
If both programs can read the same environment variable, and we have to change just the editor with another (for example from QD to MicroEMACS), it would be just necessary to act in only one point to upgrade both applications.
Another advantage of environment variable is that different user’s profiles, working on the same station, could have different values. Every user will have their own personal settings without interfere with other profiles.

Separated configuration file

In the situation in which the settings begin to become too much is a good idea to evolve the previously described method.
In this way the software can equally access to informations, maintaining the advantage of the previous system, without block too much the list of environment variables.
This means on the contrary that an external software in order to act on this archive must know before both the format and the content.

Configuration register

Another further step is the creation of an unique archive, managed from the system, which contain in a standard format all the information regarding every software installed on the machine.
Is the solution used by Windows.
Every application should use this regisiter (I repeat SHOULD HAVE) in order to add its parameters and make them easily accessible.
The controindication is that this register should be managed by the operating system; this actualy neither SMSQ/E doesn’t do.
Exists also softwares that manages multiple settings, where the user can decide what kind of settings adopts.
Technically speaking each configuration has its own priorities, so the software can freely decide which of those methods use.
In this case, to avoid duplicates and/or unwanted effects is always suggested to valorize only one configuration, so we have the certainty that the program reads only this.
As you can see there are a lot of possible choices, every one with pros and cons; now the choice is only yours.

Giorgio Garabello
(Translation by Stefano Baccella)