installation of applications

The installation of programs will probably be improved when the RLL system becomes available. Most of us who have ever used a PC will have noticed that installing programs on these systems have some serious defects. There are many reasons for that, which we will try to avoid in ProWesS. The installation of programs is handled by an installation program. In theory this can do what it wants, but there are some general guidelines.

Several problems have to be addressed when installing programs. For starters it has to be easy to find a program, and installing a new program should affect as little as possible in your system. In ProWesS this means that all files which are needed for an application should be positioned in the programs directory. The programs directory normally is "win1_prg_XXX" where XXX indicates the program. The installation program is only allowed to add lines in the "mine_personal_ldr" file in the ProWesS directory. These lines normally define a global (or environment) variable so that the program can be found, and possibly create a button for the program. The installation is also allowed to add a "_mbt" file or add lines to load the program in a "_mbt" file in the "mine" sub directory of ProWesS. The ProWesS directory itself can be found using the "PWSDIR" global variable.

In many cases the program will also rely on some RLLs. Except in some approved cases, all RLLs should be in the programs directory. The approved cases are libraries which are general, have some marshaling in the names and are controlled by one source (so the build date is not more recent because you just rebuilt an old version). RLLs will contain version and build date info which will be used to decide whether a RLL has to be replaced. An RLL will only be replaced when it is more recent and when the interface has not changed. RLLs with different interfaces can be used by different programs at the same time. This assumes that newer versions may contain extra functionality and bug fixes. It also assumes that no new bugs are introduced. I know that this last assumption may be invalid, but things would be impossible without it.

Obviously, when a program is installed it may replace a RLL by a newer compatible version. To make sure that the program can run without resetting the system, it will be possible to flag the RLL system that a newer version of the RLL is now available, so that the new version will be used the next time the RLL is requested by a program. In theory this means that your system never has to be reset again (although of course an old version of the RLL will not be freed from memory until all users have stopped executing - which can sometimes be unlikely, for example when replacing ProWesS, PROforma or syslib, the old version will probably hang around as the old version is still used in the button programs).

The major advantage of the RLL system compared with DLLs is that RLLs are loaded on demand. The DLL system relies on the thing system and can dynamically link to routines in the thing (the thing handles that itself), but does not load the library when necessary. Though this can be solved by using a loader program, it is not ideal as the library remains available when the user has finished. In this respect RLLs are much more flexible.