int 24h handler (abort, retry, fail, ignore)

[mateuszviste]

This is about adding an INT 24h handler to SvarCOM. This handler should probably be placed within the RMOD part (resident part) as it needs to be active not only during command prompt operations but also at application runtime when SvarCOM is "swapped out".

[mateuszviste]

work in progress: http://svn.svardos.org/filedetails.php?repname=SvarDOS&path=%2Fsvarcom%2Ftrunk%2Fint24.asm

[mateuszviste]

done.

a future improvement is to make this translatable. but I will fork this as a separate issue as it is much less important.

[ecm-pushbx]

The critical error handler should temporarily set stdin and stdout to the stderr handle. Otherwise redirection may make it impossible to read or reply to the prompt.

[mateuszviste]

That's a good point, thanks for bringing it up!

In fact, I did think about this issue at the very start and was going to use int 21/AH=3Fh and 40h calls to read/write directly to stderr, but then I noticed TechHelp does not list these calls as "safe" for the int 24h handler so I changed to the legacy calls and forgot about the redirection issue. Will look into that.

[mateuszviste]

hmm... for handling redirections I'd need to use int 21h,AH=46h - but this call also is not listed by TechHelp as safe for the int 24h handler :-/

RBIL provides a slightly different list, but still without any redirection functions. It says: "The only DOS calls the handler may make are INT 21/AH=01h-0Ch,30h,59h."

Not sure what's the least worse approach here.

[ecm-pushbx]

I think you have to peek into your Process Handle Table. Stash away the original two handles and copy the stderr handle into both of them. Then restore the original handles again when you're done.

[mateuszviste]

Meaning I need to locate the original process' PSP (without asking DOS for it). Yet another challenge. :-)

BTW Microsoft confirms the limited amount of functions usable from within int 24h handler: (src https://github.com/microsoft/MS-DOS/blob/main/v2.0/bin/INT24.DOC)

Also interesting to note that registers should be preserved when an error is to be ignored or retried. I should take care to restore all these registers.

[mateuszviste]

another option could be to use the BIOS for character input/output... might be actually both safer and easier.

[ecm-pushbx]

Meaning I need to locate the original process' PSP (without asking DOS for it). Yet another challenge. :-)

Function 51h and 62h both give the current PSP. Not sure why you want another one.

[boeckmann]

another option could be to use the BIOS for character input/output... might be actually both safer and easier.

Then say goodbye to using edlin over a serial line :D. Btw. do you plan to support the CTTY command? If that is the case it would not be good to use any BIOS routines for IO.

[mateuszviste]

Function 51h and 62h both give the current PSP. Not sure why you want another one.

While TechHelp lists these functions as safe from within the int 24h handler, RBIL does not... Which is the reason I'm slightly worried. ("The only DOS calls the handler may make are INT 21/AH=01h-0Ch,30h,59h.") But before I reinvent the wheel, I will try using them anyway and see how it works. Perhaps TechHelp is right on this one.

Then say goodbye to using edlin over a serial line :D. Btw. do you plan to support the CTTY command?

Not a huge fan of edlin ;-) but you are right that calling BIOS would not be a very elegant solution. Yes, CTTY is definitely a "nice to have" thing so I will probably implement it, eventually (#101).

[mateuszviste]

using int 62h from within the int 24h handler appears to work at least under EDR and FreeDOS, so it seems all good.

svn commit

[ecm-pushbx]

Uhm, did you test this? Two problems here:

mov dl, [0x1f] ; the process stderr (3rd entry of the JFT in original PSP) If the PHT starts at 18h then 1Fh is not the third entry!

Moreover, you should use the PHT pointer in the PSP, not the hardcoded default PHT location.

[ecm-pushbx]

Other than that you can directly mov ds, bx and the restoration can be done by just popping in the appropriate order, no need for using bx or dx. (If you do use the PHT pointer then you'd need to pop a far pointer to the PHT of course, not only a segment to the PSP.)

[mateuszviste]

Uhm, did you test this?

Yes I did! And, surprisingly, it works. :)

mov dl, [0x1f] ; the process stderr (3rd entry of the JFT in original PSP) If the PHT starts at 18h then 1Fh is not the third entry!

That's why I'm surprised it works. Will fix, thank you for the QA check.

Moreover, you should use the PHT pointer in the PSP, not the hardcoded default PHT location.

Ugh, I did know some day about this being possibly relocatable to a larger table elsewhere, but completely forgot about this hack. Will do.

Other than that you can directly mov ds, bx and the restoration can be done by just popping in the appropriate order, no need for using bx or dx. (If you do use the PHT pointer then you'd need to pop a far pointer to the PHT of course, not only a segment to the PSP.)

Yet another very good point. I tend to keep my assembly as "simple" as possible so it stays compatible with my limited brain power, so it's rarely optimal. But your suggestion is nonetheless very much worthy of looking into. Thanks again!

[ecm-pushbx]

mov dl, [0x1f] ; the process stderr (3rd entry of the JFT in original PSP) If the PHT starts at 18h then 1Fh is not the third entry!

That's why I'm surprised it works. Will fix, thank you for the QA check.

If you do fix that I'd suggest testing with stdin and stdout redirected as well, just to see if it really works.

[mateuszviste]

I did test it with stdout redirected, and then with stdin redirected (amb b:\file < nul). Both scenarios work. Maybe EDR presets the entire JFT with stderr? Or it is smart enough to detect an invalid handle and falls back to console... Anyway, going to fix it all now. I'm really happy you're here with us. As you see both myself and Bernd aren't very good with basic additions, so your help is truly invaluable. ;-)

[ecm-pushbx]

I did test it with stdout redirected, and then with stdin redirected (amb b:\file < nul). Both scenarios work. Maybe EDR presets the entire JFT with stderr? Or it is smart enough to detect an invalid handle and falls back to console...

Yeah I'd guess the latter.

[mateuszviste]

finally done. Positively tested with both EDR and FD (not that it means much).

[ecm-pushbx]

You can use lds bx (or si or di) and if you swap the order of pushing you can directly pop into the original two handles.

[ecm-pushbx]

You can directly push as well in fact, no need to load a register with the original handles.

[mateuszviste]

You can use lds bx (or si or di) and if you swap the order of pushing you can directly pop into the original two handles.

Nice. Saves 4 bytes. :)

You can directly push as well in fact, no need to load a register with the original handles.

I actually did not know it's legal on a 8086 to push from memory. Saves 1 byte. Thanks!

[mateuszviste]

if you swap the order of pushing you can directly pop into the original two handles.

another byte saved! :)