delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1996/09/13/05:41:06

Date: Fri, 13 Sep 1996 12:31:15 +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: DJGPP Installation Diagnostic Program
In-Reply-To: <3238BCDA.A78@cs.com>
Message-Id: <Pine.SUN.3.91.960913121351.17978M-100000@is>
Mime-Version: 1.0

On Thu, 12 Sep 1996, John M. Aldrich wrote:

> 1) Would it be better to design the program as a plain text program or
> using some sort of windowing interface?

I vote for plain text, at least at first.  What I had in mind was a 
program that produces simple text report, that should be easily 
redirected into a file (to be posted later together with a problem 
report).

> is a good idea, I would welcome pointers to sample code to implement a
> text-based windowing system (using conio functions or whatever).

If you do decide to go fancy, use PDCurses: why reinvent the wheel?

> 2) Should I even write the program with djgpp?  A significant number of
> users fail to install a DPMI host when they install their files, yet the
> program would require DPMI to run.

As DJ pointed out, you will have to make sure that DPMI-related errors 
detected early on by the stub should print human-understandable error 
messages.  Maybe the easiest way to do so is to change the stub slightly 
so that it returns different exit codes for different problems.  Then you 
could write a batch file that will print the actual messages.  It's ugly, 
but it will work for everybody, and doesn't require a special stub.  
*Then* you can bind the program with PMODE to get a stand-alone 
executable.

>  - DJGPP files present
>  - DJGPP files installed in the correct directory structure
>  - Environment variables set
>  - DJGPP version
>  - Available memory
>  - Evaluate PATH to look for other compilers' progs
>  - Trivial program compilation

Seems enough for the first cut.

>   Recommendations on the ordering of these tests?

Env vars (DJGPP and DJDIR), then the directory structure and required 
files existence, then compile a test proggy (you can make it return a 
code that tells you what version of DJGPP is installed: just look at 
__DJGPP__ and __DJGPP_MINOR__), then look at memory, then PATH.

> 5) Here are some additional ideas for things to look at, but I'm not sure
> how workable/necessary they would be:

I'd say the above is enough for the first version.  Additions may be done 
later.

>  - Debug DJGPP.ENV

Add this to the list above.  I suggest to look for these problems:

	- Changes from the original contents distributed with DJGPP (you 
can encode a CRC of it inside the program)
	- Trailing ^Z or whitespace
	- Butchered DJDIR line

>  - Implement recommended changes to system files

Never.  Just tell them what do you suggest and let them do it.
 
> 6) Any other ideas for features to include?

Later, as the program gains experience.

> 7) What should I call it?  ;)  "DJDIAG" comes to mind, but I understand
> that only DJ himself is allowed to write programs starting with his initials.

He can grant you a one-time license to do that ;-).

I vote for `djverify' or `djtest'.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019