Software for professional use should have provisions for re-installation - apparently that fact is being overlooked by most software manufacturers. Virtually no user documentation of a software has a section on re-installation these days.

It's not enough to make a software "technically perfect". It's not even enough to deliver it along with a one-time installation "once and forever". A software also needs to be designed and installed in a way that it can be made practically useful (with all the old settings!) even after a system crash or after moving to another computer.

This article can give you but a few hints what to watch out for in order to be prepared for re-installation. All I can do here is presenting you a few examples. Alas, in your individual case you will have to learn a good deal from your own experience.

MOVING TO ANOTHER COMPUTER or SYSTEM CRASH

It's quite an easy calculation: Nowadays you will have to upgrade your computer to the next hardware generation in periods of some 2-3 years. Whereas, with a good software you might well be happy for some 10 years. Logical consequence: you will have to re-install it some 3-5 times when moving to a new computer. Let alone the some 5-10 times in between you will have a system crash, calling for a fresh installation of the complete system in which your "good software" is installed.

That's not meant to be a critique of the seemingly slow succession of software generations. It's quite natural: What makes a software a "good software" is not so much what the manufacturer has built in before delivery - that's just the prerequisites. What makes it "good" (to the *individual* user!) is all the effort put in for customization, for developing user-specific macros, etc.

The need for customization turns out only over the years. When you're installing a software for the first time that's leaving some latitude for customization, you don't know what new functionality you will have added in ten years from now. Only one thing is clear: in ten years from now you will be thinking you cannot do without it anymore. If you will have to re-install the software from scratch, just as it came when you bought it, you will have the feeling: "What shall I do with such a 'dumb piece of software'?"

I for one, I'm writing this article on a software Winword 95. I'm using Winword for about ten years now, starting with  Winword 2  in the early 1990's. You might tend to think disparagingly now: "What a dull guy! Meanwhile there are much more modern text processors on the market!" Yes - every time I have to work on a text file in e.g.  Winword 97  format, I'm using a   Winword 97 reader   to convert it back to  Winword 95.  Thus I can work on it in a familiar setting, where I have right at hand all the customization, macros, etc. that I developed in the course of almost ten years. I added one after the other, from one Winword generation to the next. When I moved to a fresh hardware platform, I re-installed the latest version - and then always I had the problem to move my customization, macros, etc. along. Ok, meanwhile I know how to do that without loosing too much. Still, I dread the time when I will have to do it again - it will be at least an enormous "game of patience", to say the least.

INI-FILES

Unfortunately, today there is a hotchpotch of rules for re-installation. So far we have not even de-facto standards for software manufacturers how to implement customization, macros, etc. Each manufacturer has his own recipe of how to do that. Each one is rather strictly guarding his tongue. And if someone comes along who wants to know details, he is not very welcomed (as I know from many experiences).

The greater part of software manufacturers implement customization in a file of type INI. Usually it's located in the Windows-directory (e.g. C:\Windows) or in any of its sub-directories (e.g. C:\Windows\system or C:\Windows\system32). Many a software has its INI-file in its installation directory (e.g. C:\Program files\xyz, with xyz being the name of the software).

Most ini-files are plain ascii-files. You can look into them by any simple text processor, e.g. NotePad or WordPad as it comes along with your Windows system. Usually their entries are of the form:

	[section_name]
	keyword=argument1[,argument2 ... ]]

Most entries have only one argument per keyword but they can have any number of arguments. Many keywords are pretty self-explaining, so you might be tempted to tamper with the arguments. Don't do that! At least not before you have made a copy of that ini-file. So you can easily restore the latest valid state, if you should end up in a chaos. (Normally it should not be necessary for a user to intervene in the ini-settings. Well-designed software should provide a way of user-interaction for any setting.) Ok, in every software there are settings that are not supposed to be modified by the user. In a well-designed software they will frequently be marked in the ini-file by something like "Should not be modified". If you find anything like that in an ini-file, or if an entry looks different from the scheme mentioned above, you better don't modify it - you would be in for a lot of trouble then!

Alas, there are many types of files with a similar functionality like ini-files but with all kinds of names. More on that in the next sequel of this article series.