Application Parameters

There are many ways to customize application performance.

Command-Line Parameters

One of the main uses of the command-line parameters is to specify an alternate INI file. This is especially useful when different users want custom parameters.

These examples copy the command-line parameters to the clipboard.

Examples from unix man pages or the result of entering an illegal option.
     ls [ -aAbcCdfFgilLmnopqrRstux1 ] [ file...  ] 

     ps [ -aAcdefjlLPy ] [ -g grplist ] [ -n namelist ]
          [[ -o format ] ... ] [ -p proclist ]
          [ -s sidlist ] [ -t term ] [ -u uidlist ]
          [ -U uidlist ] [ -G gidlist ]

     ps: illegal option -- f
     usage: ps [ -aceglnrSuUvwx ] [ -t term ] [ num ] 
Notice that some parameters are flags and that others are associated with values.

INI Files

Originally, we had CFG (Configuration) files with many different data formats. Then M$ had a better idea - The INI file with a single format. Unfortunately, the tools which allowed reading these files required that you know the names of all the keys. As a result, it is very difficult to have a variable number of values under a specific heading. (This was fixed in later versions.)

Therefore, I suggest NOT using the M$ Windows 3.1 INI read routines. The 32-bit operating systems provide section access (which appears to have fixed the problem). But these commands are not mapped for Visual Basic 6.0. Instead, I use these routines

Delphi provides an INIFiles unit. You can read and write individual strings, integers, and booleans, as well as entire sections. I use TMemIniFiles. It provides most of the functionality of the VB routines mentioned above.

Netscape uses a similar method - each user has a profile stored in prefs.js (JavaScript) which stores data as

    user_pref("parameterName", "value")

Windows Registry

In the Windows Registry, most application parameters appear in one or both of these sections However, there are a number of issues

Environment Variables

This technique (though almost obsolete under MS Windows) is supported by UNIX, MS DOS, and MS Windows. Under MS DOS, this technique suffered from not having enough memory allocated. This is no longer a problem under the various 32-bit Windows products (64 Kb is now available).

Under Windows 95, the most important non-operating system use of Environment Variables is to specify the location of the temporary file. However, if your application ever needs more than 1 Mb of temporary storage, I strongly suggest allowing the user to override this value. (My video capture board came with a program which can capture only 10 sec of video because there is no way to move the temporary file from a full C-drive to my empty 2 Gb partition.)


Apparently, Microsoft has finally decided that placing all the parameters in the registry is a very bad idea. Ignoring the fact that the registry was their idea, and that they required developers to abandon ini files in order to be certified as "Windows xx complient", MS has "discovered" that the problem is their operating system.

(It has always been my position that the only reason for most of the registry was to aid in copy protection. In the olde days, you could just copy a directory to a floppy and use that to install an application on another machine. The registry was created to make this impossible. However, now that CD-RW is cheap, people just copy the entire CD. As a result, the registry is no longer necessary. Since ini files were always better, MS has discovered a problem in "the way things work" and they are going to save the world by removing the copy protection that they required everyone to use. What really bothers me is that they have the gaul to claim that this is their idea and that they are saving the world.)


BTW, .net programs are distributed as intermediate language (IL) code (aka p-code) in much the same way as Java. Therefore, a local run-time/interpreter (Common Language Runtime) is required (like Java, VisualBasic, and Visual C++). By itself, this guarantees the continuation of DLL Hell, despite their claims to the contrary. (I guess that it is possible to store 30 copies of the run-time on your system since that's the only way that this can possibly work.) Oh, there is also a disassembler which means that your code is visible to anyone.


Unix uses several methods to get parameters into programs.


In the olde dayz, everything was hard coded - including Pretty user hostile, huh.

It is better to allow the user to customize the application.

With data-driven applications, parameters are customized at runtime.

In general, you want to provide configuration control on both a per user and a per system basis. For instance

This can be accomplished by providing 2 INI files or by using 2 sections of the registry (HKLM & HKCU).

There are frequent cases where it is desired that command-line parameters can over-ride the configuration files and built-in default parameters. For instance, a command-line parameter that over-rides the hard coded INI file selection allows each user to define an icon which is customized for them.

The program structure needs to allow a variable number of command-line and INI file parameters. In order to use a common subroutine library in multiple applications, the code needs to store the parameter names and values as strings. The basic syntax is

  PValueStr = Get_Param("Param Name", "Default Value")  
where the default value is returned if the parameter does not have a value.

Depending on the language, the data can be stored in a variable length array, a linked list of objects, or a table.

A set of similar data records and the subroutines associated with them are generically known as an object.

In general, the command-line parameters must be read first in case the user wants to specify an alternate INI file. Otherwise, the command-line values should take precedence over the same parameters in an INI file.

Hierarchical Data

Most simple programs only need a single level hierarchy - ParamName=Value

The MS INI file standard permits only a 2-level hierarchy - Key.paramName=Value

The MS Registry allows an n-level hierarchy. - Key1.Key2.Key3.paramName=Value

Netscape Communicator uses several sections in the registry and C:\Program Files\Netscape\Users\userName\prefs.js

where the value is either a string, Boolean, or number.

In order to implement an n-level hierarchy you either have to build key names which contain all the pieces of the hierarchy, or you need to build a tree structure where any node can point to additional levels.

Security Issues

There are situations where you might want to make c:\Program Files read-only by average users. In effect, this makes an ini file in the install directory off limits for user preferences. (This may also simplify backups if there is a very large directory tree with no user modifyable data.)

The ideal solution is a method which does not need to be customized for each user or for each application.

The registry provides one possibility - user preferences should be under

(At work, system policies (special software which limits user freedom) prevent users from modifying HKCU!)

A similar naming convention can be used to store ini files, but be sure to include the identifiers in the filename, not the path. (Even empty directories can require about 64K each.) The problem is how to identify an appropriate base directory which is unique for each user.

Some applications may have multiple ini files for each user.


For Visual Basic 6, I use these 3 files (libraries) to implement the command-line and ini interfaces.

Delphi 5 has a rich ini file interface - I like TMemIniFile. It is easy to use, but

At least

Author: Robert Clemenzi -
URL: http:// / user / clemenzi / technical / Languages / ApplicationParameters.htm