bill@meadow.UUCP (Bill Foster) (05/29/89)
I have a question about intercepting the GEM dialog box that says
"The data on drive E may be damaged, Cancel or Retry". What I would
like to to is temporarily replace this with an automatic 3-time attempt
after which it would automatically cancel and send an error to Rwabs.
Is this the critical error handler vector (etv_critic = 0x404)? If I call
hdv_rw (0x476) and skip the call to Bios Rwabs what will happen (suppose I
should try first)?
What is the format and return values for the critical error handler
routine?
I am using this info to improve the read-only disc scan program scan.ttp
(free to all apon registration).
BFOSTER = GEnie, WHTB33B = Prodigy
{~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~}
{~} <> Bill Foster <> | {~}
{~} | {~}
{~} | Vegetarians 4-ever {~}
{~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~}
{amdahl,hplabs,decwrl}!pacbell!cpro!meadow!billroeder@sbsvax.UUCP (Edgar Roeder) (06/01/89)
In article <26@meadow.UUCP>, bill@meadow.UUCP (Bill Foster) writes: > > Is this the critical error handler vector (etv_critic = 0x404)? If I call Yes it is. > What is the format and return values for the critical error handler > routine? The routine is called with 2 arguments: - the bios error number of the event causing the handler to be called - the drive which caused this error The return value should be one of: 0L - ignore the error 0x10000L - retry (possibly this gives the same error again) any other value - return with this value as error (i.e. ABORT) You can install a normal C-routine as the error handler. But you can only call Bios-functions for terminal output, since the handler may be called from a GEMDOS-function and since GEMDOS is not reentrant (*), you can't use GEMDOS-functions like Cconout() (and most printf()'s in C-Compilers). Also make sure that your C-compiler has a reentrant bios() binding - this means that it uses a stack for the return-code from the bios()-function and eventually saved registers and not a static storage location. Otherwise you would have to use inline-assembler (like in MEGAMAX C, Laser C or GNU-C) or a seperate assembler routine to call trap #13. Hope this helps. - Edgar (*) GEMDOS is not reentrant when called by the Bios because it uses a static (and undocumented (!)) storage location for the return address when it calls a Bios-function like for example Rwabs() from inside Fwrite() which eventually calls the critical error handler.
apratt@atari.UUCP (Allan Pratt) (06/03/89)
In article <757@sbsvax.UUCP> roeder@sbsvax.UUCP (Edgar Roeder) writes: > You can install a normal C-routine as the error handler. But you can only > call Bios-functions for terminal output, since the handler may be called > from a GEMDOS-function and since GEMDOS is not reentrant (*), you can't use > GEMDOS-functions like Cconout() (and most printf()'s in C-Compilers). > > (*) GEMDOS is not reentrant when called by the Bios because it uses a static > (and undocumented (!)) storage location for the return address when it calls > a Bios-function like for example Rwabs() from inside Fwrite() which > eventually calls the critical error handler. Give me a break! GEMDOS is not reentrant for more reasons than that! And you don't expect us to document EVERY VARIABLE that GEMDOS uses, do you? GEMDOS is not reentrant because (A) it sets SSP to the same address every time it's called, and (B) it uses the basepage of the current process to store the context (the registers, incl. PC). If you make a GEMDOS call from within a GEMDOS call, the second one overwrites the stack of the first one and overwrites the first caller's context. NOw that's what *I* call non-reentrant! Given those two reasons, finding other reasons for non-reentrancy in GEMDOS is little more than vanity or folly. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt