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

Date: Fri, 13 Sep 1996 12:09:19 +0200 (MET DST)
From: Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl>
Reply-To: grendel AT ananke DOT amu DOT edu DOT pl
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.NEB.3.95.960913114923.7351B-100000@ananke.amu.edu.pl>
MIME-Version: 1.0

>I think this is a great idea and would be glad to try to design such a
>beastie.  However, I have a few questions before I get started:
You can count on my help, if you need any ;-))

>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 is easier but, you're right, most novices are UI-sensitive and they
feel confused seeing UNIX-like program with no interface, just bare messages.
As to windowing system, I think using Robert's port of TV wouldn't be bad
idea. You'll find it in the same place you downloaded DJGPP.

>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 imagine that the program will be a part of basic DJGPP distribution? If so
then it will be installed as one of the first. The only thing left to do is to
make sure CWSDPMI is also installed alongside. Even if the user fails to
install DJGPP properly s/he wil be able to run the proggy from the dir DJGPP
was unzipped to.

 >
>3) As an alternative to #2, I could use the 'pmode' stub to make the
>program standalone.  Is this a good solution?
It's certainly more fool-proof ;-))

>4) Obviously the first things to check for would be the following:
>
1.> - DJGPP files present
4.> - DJGPP files installed in the correct directory structure
3.> - Environment variables set
2.> - DJGPP version
6.> - Available memory
5.> - Evaluate PATH to look for other compilers' progs
7.> - Trivial program compilation
>
>  Recommendations on the ordering of these tests?
Suggested ordering above

>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
Don't think it's necessary. Majority (if not all) new users will D/Load V2 and
newer versions so it would be just a waste of time to check for oldies. (I
imagine that this program is meant to be used mainly by newbies)

> - Check Windows 95 LFN support (I don't have Win95 to test this...)
I can test this. Checking for it is, however, a purely informational matter.
You can't assume user will be running in Win95 DOS box. And since you can't
hold it for sure, you can't report "Your system doesn't suppor LFNs". User
that has Win95 installed will at once post a message to djgpp newsgroup(s):
"What's wrong with my Win95 installation. Your diagnostic program reports that
it doesn't support LFNs. And only yesterday I created
a_very_long_file.with_even_longer_extension" ;-))). No, you may just say that
at the installation time LFNs were unavailable.

 > - Checklist for necessary djgpp tools/packages
That for sure. I think it should be part of the primary checks.

> - Refer problem areas to relevant FAQ sections
Yup. It might even try to show these sections, if the FAQ files are available
(or include snippets of it with diag program distribution)

> - Debug autoexec.bat/config.sys
In what sense? DJGPP installation generally requires adding just one line to
AUTOEXEC.BAT.
> - Debug DJGPP.ENV
Certainly, since it is not well-documented it wouldn't hurt to correct too
inquisitive users with not enough experience... ;-))

> - Implement recommended changes to system files
I think that the way it is now (i.e. setdjgpp.bat) is OK. Program should look
for this batch, and implement changes inside (unless you want to alter
cache/ramdisk configuration which I suppose is not a very good idea) the file.

>6) Any other ideas for features to include?
Maybe creating a "snapshot" of current features installed, along with an ASCII
log file to contain all the data that might be needed with bug/error reports?
You might even include system-detection features (like , for example, in
tell386.exe that comes with Pharlap extenders)

>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.
Name it with your initials! JADIAG sounds good for me!

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

If I can help in anything...

**********************************************************************
So if you ask me how do I feel inside, I could honestly tell you we've
been taken on a very long ride. And if my owners let me have free time
some day, with all good intention I would probably run away!
Clutching the short straw...
******************* http://ananke.amu.edu.pl/~grendel ****************

- Raw text -


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