Date: Mon, 7 Oct 1996 08:22:27 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "John M. Aldrich" <fighteer AT cs DOT com>
Cc: DJGPP Workers Mailing List <djgpp-workers AT delorie DOT com>
Subject: Re: DJVERIFY 0.1a uploaded
In-Reply-To: <32582106.2174@cs.com>
Message-Id: <Pine.SUN.3.91.961007080557.2485O-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Sun, 6 Oct 1996, John M. Aldrich wrote:

> Agreed.  When I finish I intend to stand them out not only with
> separation but with making them appear "high-intensity" on the screen. 
> I _know_ that all monitors support that!

That is true, but I suspect there are people who make high intensity 
their default, especially those who play with 4DOS/NDOS.

> if they are called explicitly.  So if I had DJVERIFY.EXE and
> DJVERIFY.BAT in the same directory, typing 'djverify' would _always_
> invoke the .EXE.

Well, of course!  But I never said that you should call them by the same 
basename.  What I mean is that users should call the batch file instead 
of the .exe; and the .exe should be called by some other name.

In my experience, if people get 2 programs to invoke, they become 
confused as to which one should they call.  If `djverify' is the .exe, 
you will end up with a wasted effort of writing that batch file, and with 
people that keep asking "What's that ``Cannot load'' message?"  Just call 
the batch file DJVERIFY.BAT and tell people to call it.

If there are reasons to let the batch call programs other than yours, as 
DJ pointed out, make the batch file be able to do this like so:

		djverify myprog

and look at %1 inside the batch to see how was it called.  You can for 
instance check if %1 is either empty or one of the known switches to 
your program (-s, -q, etc.), then reinvoke the batch with the name of 
your program as the first arg.

> Faced with this dilemma, the only solution is to call the batch file
> something else, and try to make it intuitive enough so that users will
> be able to figure it out for themselves.

Shouldn't assume anything about user intuition when writing fool-proof 
(well, diagnostics, anyway) programs.

> Thanks for your help!

Thanks for making it happen!