Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!agate!linus!linus!mwunix.mitre.org!jcmorris
From: jcmorris@mwunix.mitre.org (Joe Morris)
Newsgroups: comp.windows.ms
Subject: Re: Editor...
Message-ID: <122816@linus.mitre.org>
Date: 10 Oct 90 18:33:06 GMT
References: <90280.143318CC65MGTW@MIAMIU.BITNET> <kF5sq3w163w@zooid.UUCP>
Sender: usenet@linus.mitre.org
Reply-To: jcmorris@mwunix.mitre.org (Joe Morris)
Organization: The Mitre Corporation
Lines: 63

In article <kF5sq3w163w@zooid.UUCP> dve@zooid.UUCP (David Mason) writes:
>CC65MGTW@MIAMIU.BITNET writes:
 
>> It would be virtually impossible.
>> Every Windows app you install has its own unique parameters it puts into
>> WIN.INI. These parameters are found by a simple search of the file, and
>> the parameters are read in.
>> Since there are hundreds of applications, and each application can have any
>> number of parameters, there is virtually no way to have ae editor any more
>> efficient than the undocumented SYSEDIT.EXE.
 
>I don't agree. Perhaps Microsoft could design an editor for WIN.INI that 
>could have parameters by a new program. Admittedly it would be complex, but 
>it would be better than the current solution. 

I think I've posted this comment before, but a major design flaw (IMHO) in
the WIN.INI concept as currently implemented is that there is no protection
against typos in the file except where file names are incorrectly entered.
For example, our old favorite which has been tossed around in several
threads over the past few months is:

   VirtualHDRIQ=false

which must be spelled correctly or the system will simply ignore it, causing
all sorts of interesting problems with DMA and SCSI interfaces.

OK, how many of you readers noticed the transposition in the parameter?  It's
virtualhdIRq, not virtualhdRIq as I typed it.  You can put your hand down now;
you've proved yourself better than Windows at finding an error.

It's not just the name of the parameter that isn't checked; you can also type:

   VirtualHDIRQ=flase

and the system doesn't complain.  I have no idea what value Windows is actually
assigning to the parameter.

It shouldn't be too difficult to write a semi-intelligent editor which just
presented the parameter name, the choices, and maybe a few lines of comments.
The syntax could even be compatible with the current system:

; %% VirtualHDIRQ=<boolean>
; %d On
; %h Allows Windows in 386 enhanced mode to terminate...
   ...
VirtualHDIRQ=on

where 'boolean' is recognized as meaning the set {1,0,true,false,on,off...}

The program doesn't *have* to be able to handle the entire file, although
that would be nice.  If Microsoft provided the necessary parameter lines
for its part of the file then the program could revert to dumbo mode for
the rest if a vendor didn't provide matching parameters.

The main problem is that without any validation procedure the user can 
change the WIN.INI or SYSTEM.INI file and be unaware that the intended
behavior change may not have occurred.  Some kind of checking is mandatory
for a reliable system for any file which is subject to arbitrary editing.
However frustrating they may be at times this is a distinct advantage to
using binary configuration files: the users keep their fingers out and
modify them only through (supposedly) bullet-proof application interfaces.

Joe Morris