Message-ID:	<3238C47B.3F7A@gbrmpa.gov.au>
Date:	Fri, 13 Sep 1996 10:18:33 +0800
From:	Leath Muller <leathm AT gbrmpa DOT gov DOT au>
Reply-To:	leathm AT gbrmpa DOT gov DOT au
MIME-Version:	1.0
To:	"John M. Aldrich" <fighteer AT cs DOT com>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP Installation Diagnostic Program
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 960912081407 DOT 15096C-100000 AT is> <3238BCDA DOT A78 AT cs DOT com>

John and co.,

I would be happy to help anyway I can with this, but hang with me, I am
new to this development environment... :)

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

You should use a window interface simply for the reason you stated. Its
also generally easier if someone running the diag program can follow
what is going on easily.
 
> 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.
> 3) As an alternative to #2, I could use the 'pmode' stub to make the
> program standalone.  Is this a good solution?

You should include the stub. The only other option is to make the
program
real mode... ;) But how much would this bloat the program? Are you
looking
at a maximum size for this diagnostic program? Is including cwsdpmi with
the DIAG program an option?

> 4) Obviously the first things to check for would be the following:
>  - 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

Looks cool...

>   Recommendations on the ordering of these tests?
> 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

You could always make the program v2 only, and thus 'encourage' people
to
upgrade to v2. If you look for v1.x programs, wouldn't this mean you are
supporting it (in a fashion)?

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

If have Win95 so I can check this, but would there be a point in
implementing
this? Sure, you can check to see if it is supported, but would it matter
if the djgpp programs themselves didn't?

>  - Checklist for necessary djgpp tools/packages

A definate I think...let the person know they have the tools to compile
basic C progs, but not C++ etc...

>  - Refer problem areas to relevant FAQ sections

Yep...

>  - Debug autoexec.bat/config.sys
>  - Debug DJGPP.ENV
>  - Implement recommended changes to system files
>   Comments?

Looks cool...
 
> 6) Any other ideas for features to include?
> 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.

JADIAG... :)

> With suitable feedback I should be able to start on the project by this
> weekend.

I think most of what you want to implement would depend pretty much on
how much detail you want to go into. The more detail the better, but
what about time constraints? etc...

Leathal.

- Raw text -