DOS ain't dead

Links to the manual, a release, and the repo are collected at https://pushbx.org/ecm/web/#projects-keephook. KEEPHOOK is a program I've wanted to write for several years now. It aids the unhooking of interrupts by my other programs, which utilise an advanced deinstallation method. In combination with this method KEEPHOOK allows access to parts of the interrupt chain hidden by incompatible TSRs.

The manual contains a very detailed description of this technique. I'm particularly interested in what you may think of "the long story" in the manual. Side note: I'll be adding links to my page for the other TSRs soon. (Those are RxANSI, lClock, SEEKEXT, and the TSR example.)

---
l

> Side note: I'll be adding links to my page for the other TSRs soon.
> (Those are RxANSI, lClock, SEEKEXT, and the TSR example.)

Added sections for the other TSRs with links to the repos and automated some "current releases". These are created daily (at 23:50 CET) from the repos, using the included mak.sh scripts.

---
l

> The manual contains a very detailed description of this technique. I'm
> particularly interested in what you may think of "the long story" in the
> manual.

Interesting program. The concept reminds me a little bit of the old MARK and RELEASE programs from the TSRCOM35 package. It seems as though KEEPHOOK may only work with AMIS-compatible TSR's, though. Is that so, or would it help with uninstalling "regular" TSR's also? Over time I'm converting my TSR's to AMIS so it might come in handy for me, but I haven't completed that process yet.

As far as "the long story" I think you did a pretty good job of explaining, but a little block diagram with some arrows may help. This stuff can be very confusing and even people who've written TSR's but aren't familiar with IISP or AMIS may have a hard time following it. I've tried writing explanations of things like this before and sometimes even I get confused with what I've written -- this is a hard thing to explain.

> > The manual contains a very detailed description of this technique. I'm
> > particularly interested in what you may think of "the long story" in the
> > manual.
>
> Interesting program. The concept reminds me a little bit of the old MARK
> and RELEASE programs from the TSRCOM35 package. It seems as though
> KEEPHOOK may only work with AMIS-compatible TSR's, though. Is that so, or
> would it help with uninstalling "regular" TSR's also?

A TSR's uninstaller needs to use the advanced deinstallation method to gain from KEEPHOOK handlers. Although that implies that the TSR itself is also an AMIS multiplexer, to be exact it doesn't actually have to be.

I may write a companion program (all transient) which re-orders interrupt handlers. This would be useable with TSRs that do not exploit AMIS, too. The difficult problem is that to bubble up a certain handler we need to be able to insert another handler into the chain behind the one to expose. This usually would require to detect the next handler pointer of the handler to expose, ie it needs to have an IISP header.

A different way may be possible by installing KEEPHOOK and covering the same interrupt twice: once before installing the TSR and once after. However, I'm not sure how to avoid loops or insure that the order of the handlers is correct.

> Over time I'm
> converting my TSR's to AMIS so it might come in handy for me, but I haven't
> completed that process yet.
>
> As far as "the long story" I think you did a pretty good job of explaining,
> but a little block diagram with some arrows may help. This stuff can be
> very confusing and even people who've written TSR's but aren't familiar
> with IISP or AMIS may have a hard time following it. I've tried writing
> explanations of things like this before and sometimes even I get confused
> with what I've written -- this is a hard thing to explain.

Thanks for the feedback. I may consider adding a diagram. I'd have to draw it with ASCII art though.

---
l

> A different way may be possible by installing KEEPHOOK and covering the
> same interrupt twice: once before installing the TSR and once after.
> However, I'm not sure how to avoid loops or insure that the order of the
> handlers is correct.

Yeah, that's a problem since you don't really know how the TSR handles the interrupt (preprocessing vs. post-processing vs. both, sometimes passing the interrupt through to previous handler and sometimes not, CALLing vs JMPing, IRQ handlers sometimes issuing the EOI and sometimes not, etc.). It can get really ugly. AMIS, or even just IISP, makes much of that a whole lot easier. Though I've never seen one that did this, a TSR could keep track internally (instead of using the IISP header) of, e.g., whether or not it needs to issue an EOI and changing the order around could mess that up.

> Thanks for the feedback. I may consider adding a diagram. I'd have to draw
> it with ASCII art though.

I was imagining ASCII art rather than a "real picture".

> > A different way may be possible by installing KEEPHOOK and covering the
> > same interrupt twice: once before installing the TSR and once after.
> > However, I'm not sure how to avoid loops or insure that the order of the
> > handlers is correct.
>
> Yeah, that's a problem since you don't really know how the TSR handles the
> interrupt (preprocessing vs. post-processing vs. both, sometimes passing
> the interrupt through to previous handler and sometimes not, CALLing vs
> JMPing, IRQ handlers sometimes issuing the EOI and sometimes not, etc.).
> It can get really ugly.

I'm assuming that most of that won't be a problem, but we do have to be sure which of the KEEPHOOK covers comes first. I scribbled this out into some diagrams on paper.

If we have several non-IISP TSRs ("TSR", "OTHER", "ANOTHER") and want to bubble up one of them ("TSR"), which is pointed-to by one of the KEEPHOOK handlers ("KH1"), then we have to be sure that the other KEEPHOOK handler ("KH2") is located in the chain after "TSR". The correct case's input goes like IVT -> OTHER -> KH1 -> TSR -> ANOTHER -> KH2 -> DOS. The operations on the chain are 1. IVT -> KH1.next (TSR), 2. KH1 -> KH2.next (DOS), 3. KH2 -> oldIVT.next (OTHER). The resulting output is IVT -> TSR -> ANOTHER -> KH2 -> OTHER -> KH1 -> DOS.

Otherwise, it goes like IVT -> OTHER -> KH2 -> ANOTHER -> KH1 -> TSR -> DOS. Then after the same operations we end up with the IVT pointing to "TSR" which points to "DOS", and two separate chains that are both each infinite loops (involving "KH1" and "KH2").

However, if we have IVT -> OTHER -> TSR -> ANOTHER -> KH -> DOS where OTHER must be any number of entries with IISP headers then we can know with certainty that the KEEPHOOK handler must be in the chain after "TSR" and we can re-order the chain to put all "OTHER" entries behind "KH" even though "TSR" and "ANOTHER" do not provide IISP headers.

(Reversing the prior operation is also possible.)

> AMIS, or even just IISP, makes much of that a
> whole lot easier.

If everyone uses IISP re-ordering or unchaining in the middle of the chain becomes trivial. Though it would still be useful to do that re-ordering in a specialised tool because not all programs using IISP (as in, providing the headers) do also implement unchaining from other IISP entries.

> Though I've never seen one that did this, a TSR could
> keep track internally (instead of using the IISP header) of, e.g., whether
> or not it needs to issue an EOI and changing the order around could mess
> that up.

There isn't really any way to determine that. However, software interrupts are probably safer on this matter: Any handler may choose not to chain and not to call down to its next handler, either unconditionally or depending on function call or something else. So things shouldn't break down when re-ordering, or at least not any worse than they could from simply installing programs in a particular order.

---
l

Pg 7 in the manual
> Additionally, the querent must provide an interrupt number
> to check in the BL register.

I could tell what the word means from the context, but I had to look it up to see if it really exists. So think I learnt a new word - Very nice! Only thing is it's not in
https://dictionary.cambridge.org/spellcheck/english/?q=querent
but is in
https://www.lexico.com/definition/querent
https://www.merriam-webster.com/dictionary/querent

Anyway I'm sold!