🚀 go-pugleaf

In article <1991Apr26.002159.23869@athena.mit.edu>,
mmshah@athena.mit.edu (Milan M Shah) writes:

> I would like to say that the best way to attack the problem
> is to prevent it. Win 3.0 has excellent facilities for each program to 
> maintain its own .ini file. Thus most programs should not touch win.ini at
> all. In fact, using your own private .ini file is as simple as modifying
> just a couple of function calls. An added benefit is that these .ini files
> are much shorter, so finding key-value pairs is much faster.
> 
> Unfortunately, this requires work from the programmer, and the user can do
> little about it. If a commercial program did this cloberring up of win.ini,
> I would definitely complain to the manufacturer. At this point, I can see
> no need for an application to use win.ini at all.

I strongly agree with the above and urge programmers to follow Milan's 
advice. (as I do)

However, I disagree with the following:

> Moreover, the private
> .ini file should reside with the program module, and not require that it
> be present in the windows directory. This can be implemented with just a
> couple of extra system calls (to determine where the program was launched
> from).

Doing this would prevent the program from being used from a network drive
and would prevent multiple users of the same PC from maintaining different
configurations. So ... use private .ini files but use windows default
directory placement. 

Finally, I would suggest that the full path of a programs .ini file should
be a "command line" parameter. This allows for individual preferences on
.ini file placement and multiple configurations by clicking different icons.

Les Moss                      moss@tti.com
Citicorp TTI
3100 Ocean Park Blvd.   (213) 450-9111, ext. 2982
Santa Monica, CA  90405