DOS ain't dead

Announcement: KEEPHOOK (Announce)

posted by ecm  , Düsseldorf, Germany, 16.10.2021, 18:53

> > 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

Complete thread:

• Announcement: KEEPHOOK - ecm, 12.10.2021, 18:54 (Announce)
  • Announcement: KEEPHOOK - ecm, 13.10.2021, 18:26
  • Announcement: KEEPHOOK - bretjohn, 13.10.2021, 21:24
    • Announcement: KEEPHOOK - ecm, 14.10.2021, 00:27
      • Announcement: KEEPHOOK - bretjohn, 14.10.2021, 00:55
        • Announcement: KEEPHOOK - ecm, 16.10.2021, 18:53
  • Announcement: KEEPHOOK - andrewbird, 17.10.2021, 18:30