Message-ID:	<325F0CDF.2611@cs.com>
Date:	Fri, 11 Oct 1996 20:13:35 -0700
From:	"John M. Aldrich" <fighteer AT cs DOT com>
Reply-To:	fighteer AT cs DOT com
Organization:	Three pounds of chaos and a pinch of salt
MIME-Version:	1.0
To:	grendel AT ananke DOT amu DOT edu DOT pl
CC:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>,
	djgpp-workers AT delorie DOT com
Subject:	Re: Install thingy
References:	<Pine DOT NEB DOT 3 DOT 95 DOT 961011141720 DOT 29964B-100000 AT ananke DOT amu DOT edu DOT pl>

Mark Habersack wrote:
> 
> I decided, following advices, to make the installed a real mode program. It
> assures it will run everytime on any system.  So the idea with stubify falls
> apart.  But I thought about another way of invoking djverify.  Installer might
> call it with different argv[0] (just as DJGPP 'links' do). djverify seeing it
> is being run from within the installer might tune its output to contain ONLY
> data necessary for the installer.

Easy enough to do, but you may still not be able to run djverify.  One
possible solution to this problem is to have your program read the
return codes from the djverify stub and analyze them in the same way as
my batch file.  It's real simple - if your system() call returns a code
in the 100...110 range, djverify was unable to run due to a stub error. 
Take a look at the 'stubtest.bat' file in my 0.1 upload of djverify to
DJ's ftp site to see how the codes are used.  (The next upload will
include the renamed files.)

> I'm not sure, however, whether TC 2.0 will allow me to modify argv[0].  AFAIK,
> TC uses DOS calls to invoke external programs and this means that they are
> ALWAYS passed path\myname.exe as argv[0].  If this is true, install might use
> another approach to notify djverify it is run as its child.  I could hook INT
> 2Fh and install a callback known to djverify.  The latter would check if
> installer is in memory and behave according to the result.

Yuck - I had hoped to avoid having to use interrupt handlers in my code,
because I have never learned much about them.  If you could write the
code I could include it in my program, though.  :)

> A thought has just crossed my mind.  Would it be possible for you to generate
> a BINARY report file to be used by install only?  djverify would generate it
> only if the conditions described above would be true.

Easily possible to do.  However, you'd run into the old packing
structures problem that has always plagued RM-PM data conversions.  We'd
have to coordinate our structures _most_ carefully.

The other possibility is to specially format the djverify output so that
install can recognize it.  What I have in mind is something like this:

		DJVERIFY output format:

Normal messages
 * [XXX] Informational messages (XXX = code for the specific message)
 ** [XXX] Warning/error messages (XXX = code for the specific message)

The codes could be standardized by a header file that is shared between
the two programs, using #defined constants for the numerical codes and
an array of strings for the actual messages.  This way neither of us
would have to create some elaborate data structure to transmit the
information in and the user wouldn't be confused with strange output
options.  :)

-- 
John M. Aldrich <fighteer AT cs DOT com>                      

* Anything that happens, happens.
* Anything that, in happening, causes something else to happen,
  causes something else to happen.
* Anything that, in happening, causes itself to happen again, happens
  again.
* It doesn't necessarily do it in chronological order, though.
 
                                       --- Douglas Adams

- Raw text -