Application Parameters

There are many ways to customize application performance.

Command-line parameters
Read an INI file
Use the registry
Environment Variables
.Net
Discussion - Hierarchical Data Security Issues
Examples

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.

Visual Basic		Command()- Returns all the parameters in a single string
Delphi		CmdLine - Returns the entire command line, including the program name and all the parameters ParamStr (n) returns the n_th parameter
C++ Builder		WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR lpCmdLine, int) lpCmdLine - This points to the command-line parameters
Console C++		int main(int argc, char **argv) argc is the number of parameters argv[i] is the i_th parameter

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

Simplifies moving/copying the application if the INI file is in the same directory as the application.
Can automatically move with the user if it is stored in the user's home/private directory on a central file server.
When the INI file is not in its default location (i.e. the directory which has the application), then a command-line parameter must point to it.
Can be edited using notepad.
Can contain comments describing its usage.
Concepts are portable to non-Microsoft operating systems.

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

HKLM - Local Machine - applies to all users
HKCU - Current User - allows each user to have a different customization. On an NT Domain, this data is usually available at every machine that the user logs on to.

However, there are a number of issues

Proprietary, non-portable database.
This mechanism suffers from slow bloated access. On my Windows 95 system, user.dat = 500 Kb, System.dat = 3,650 Kb.
This is very useful if several applications need to share the same data.
Usually makes it difficult to move/copy an application.
Requires special software to just delete the application.
Adding comments slows down every application on that system. As a result, no applications currently include comments.

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.)

.Net

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.)

References:

Simplifying Deployment and Solving DLL Hell with the .NET Framework

The separation between the entries in the registry and the files on disk makes it very difficult to replicate applications and to uninstall them.
[The] registry ... drastically complicates the process of deploying distributed applications ... [As a result] applications are neither self-describing nor self-contained.
Applications that are self-describing remove the dependency on the registry, ... simplifying uninstall and replication.

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

Unix uses several methods to get parameters into programs.

qpopper (an email pop3 server) provides a program (./configure) which allows you to set configuration parameters before you compile the program, thus removing the necessity of a configuration file.
Many programs use resource files - .namerc - sometimes these are read like ini files, othertimes (such as .cshrc and .bashrc) they can contain commands that are executed.

the following text is from the beginning of pine.conf

#      /usr/local/lib/pine.conf -- system wide pine configuration
#
# Values here affect all pine users unless they've overidden the values
# in their .pinerc files.  A copy of this file with current comments may
# be obtained by running "pine -conf". It will be printed to standard output.
#
# For a variable to be unset its value must be null/blank.  This is not the
# same as the value of "empty string", which can be used to effectively
# "unset" a variable that has a default or previously assigned value.
# To set a variable to the empty string its value should be "".
# Switch variables are set to either "yes" or "no", and default to "no".
# Except for feature-list items, which are additive, values set in the
# .pinerc file replace those in pine.conf, and those in pine.conf.fixed
# over-ride all others.  Features can be over-ridden in .pinerc or
# pine.conf.fixed by pre-pending the feature name with "no-".
#
# (These comments are automatically inserted.)

# Sets domain part of From: and local addresses in outgoing mail.
user-domain=

# List of SMTP servers for sending mail. If blank: Unix Pine uses sendmail.
smtp-server=

# NNTP server for posting news. Also sets news-collections for news reading.
nntp-server=newsreader.digex.net

As you can see, this is similar to an ini file except that comments start with a pound sign (#). .pinerc and pine.conf.fixed use the same format. (pine is an email client.)

Discussion

In the olde dayz, everything was hard coded - including

The directory where the application was stored
The floppy drive letter that the code must be installed from
Which COM port to use

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

Background color - each user may want a different choice.
Location of the CD-ROM drive - each computer may have a different value.

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

user_pref("editor.html_editor", "C:\\WINDOWS\\Notepad.exe");
user_pref("Key1.Key2.Key3.paramName",Value);

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

   HKCU\Software\CompanyName\Product\Version\

(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.

The availability of a private read/write profile directory is dependent on the particular operating system and on local system policies.
It is possible is to use one of the aliases defined under
```
   HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
```
Both AppData and Personal (aka My Documents) are good possibilities.
Place the fully qualified ini filename in the registry (HKCU)
Place the fully qualified ini filename on the icon's command-line (usually in the Start menu).

Some applications may have multiple ini files for each user.

Examples

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

GlobalRoutines.bas: ConvertColor - Converts an ini-file string into a color
RemoveDoubleQuotes - Removes double quotes from a string
Set_UICombo - Converts an ini-file string into a picklist
ini_code.bas: Reads and writes ini files, maintains a list of parameters
Process_Command_Line_code.bas: Reads and parses command-line parameters

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

It does not preserve comments before the first key
It removes blank lines
You must not have spaces before or after the equals signs

At least

It is not case sensitive

Author: Robert Clemenzi - clemenzi@cpcug.org