Mail Archives: djgpp-workers/1996/10/13/14:31:56
On Fri, 11 Oct 1996, John M. Aldrich wrote:
>> 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.)
That would be easy.
>> 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. :)
No need for interrupt handlers! You'd just call int 2Fh to see whether a
program with a specific code is in memory. Just like you check for presence of
MSCDEX.
>> 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.
Well, that might be taken care of by forcing ALL integer fields to be 32 bit
(hell with space ;-)) and possibly use padding where necessary.
>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. :)
That's better idea! This way there won't be any fuss with structure packing
and handling.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Decriminalised genocide provided door to door Belsens. Pandora's box of
Holocausts gracefully cruising satellite infested heavens.
Waiting, the season of the button, the penultimate migration. Radioactive
perfumes, for the fashionably, for the terminally insane, insane
Do you realise, do you realise, do you realise?
This world is totally FUGAZI!
_-_-_-_-_-_-_-_-_-_- http://ananke.amu.edu.pl/~grendel -_-_-_-_-_-_-_-_-_
- Raw text -