Date:	Thu, 12 Sep 1996 21:24:05 -0400
From:	dj (DJ Delorie)
Message-Id:	<199609130124.VAA20839@delorie.com>
To:	fighteer AT cs DOT com
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<3238BCDA.A78@cs.com> (fighteer@cs.com)
Subject:	Re: DJGPP Installation Diagnostic Program

We have a unix program like this at work called "verify-workstation".
Over the years, we've taught it how to detect and suggest corrections
for *ALL* known configuration issues that cause problems with the
common software we use.  I think such a program for djgpp would be of
great value.

> 1) Would it be better to design the program as a plain text program or
> using some sort of windowing interface?  The latter would be more familiar
> to many users, but I have far less experience with it.  If you think this
> is a good idea, I would welcome pointers to sample code to implement a
> text-based windowing system (using conio functions or whatever).

Plain text makes less demands on the system, and thus is more likely
to run.  I think it should operate in three modes:

* The user runs it and it prints out a summary of their system, what's
  available to djgpp, and a list of stuff that needs to be fixed.

* The user puts it at the end of their autoexec.bat, and it prints a
  warning if something changes that might cause a problem, else it's
  silent.

* The user wants a summary of their configuration to post to the 'net

Perhaps the default (no parameters) would be to print a screen full of
options for what they are trying to use djgpp for (C, C++, Quake, Ada,
graphics, sound, performance, etc).

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

I think you can write it with djgpp IF you modify the stub to include
verbose error messages with instructions on correcting the errors.

> 3) As an alternative to #2, I could use the 'pmode' stub to make the
> program standalone.  Is this a good solution?

Not if there are errors that prevent pmode programs from running.
This program *must* be useful on all systems.

>  - DJGPP files present

The basic development ones, at least.  With V2 there aren't any
runtime files (like go32.exe).  The minimum would be libc, gcc, cpp,
cc1, as, ld, specs, stdio.h.

>  - DJGPP files installed in the correct directory structure

DJGPP unzipped with pkunzip and without -d.

>  - Environment variables set

Set to meaningful values, to!

>  - DJGPP version

Hard to detect, but libc does have a version stamp in it.  Printing
this would be useful.

>  - Available memory

and what type of memory it is.

>  - Evaluate PATH to look for other compilers' progs

And what type of program "make.exe" turns out to be.

>  - Trivial program compilation

V1 had one of these also.

>   Recommendations on the ordering of these tests?

(1) Can the system run djgpp?
(2) Is the system configured according to the directions?
(3) Stuff that might cause problems (bcc, etc)
(4) performance issues.

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

make, ld, and gcc at least.

>  - Check Windows 95 LFN support (I don't have Win95 to test this...)

Perhaps as part of the status dump, but I don't know of too many
problems that depend on LFN (emacs?)

>  - Checklist for necessary djgpp tools/packages

This is where that screen full of options comes into play.

>  - Refer problem areas to relevant FAQ sections

I'd recommend limiting this to mentioning
http://www.delorie.com/djgpp/ The FAQ has already changed URLs once
(from V1 to V2).

>  - Debug autoexec.bat/config.sys

Tricky.

>  - Debug DJGPP.ENV

Useful, but keep in mind that just relying on environment settings
within your program will skip all the other sections.  Make sure
that $DJGPP points to the installation area, and that it points
to djgpp.env, and that the $DJGPP and $DIDIR set within djgpp.env
haven't been tampered with.

>  - Implement recommended changes to system files

This scares me.  I never let programs mess with my system files.
However, an option to produce a log file with the changes in it is a
good idea.

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

Hee hee.  For packages, at least, I reserve dj*.  Good names...

	djverify	djcheck		djgpp_ok	djpcscan

They all seem to start with dj, don't they?  I think it's important to
have a name that definitely ties it to djgpp, so that people don't
confuse it with the myriad other system checkers out there.

- Raw text -