DOS ain't dead

discussion - splitting MCBs again (Developers)

posted by ecm  , Düsseldorf, Germany, 14.06.2011, 02:20

> And rightly so. It is not changed - except if the caller was validated to
> be KBFR. There are 96 bits of ID, not counting the 8 in AL. Many APIs we
> depend upon could fail with much much higher probability.

I see only 24 bits: al = F4h and bx = "BK". 8 of those bits have a meaning in the original interface, 16 do not have a meaning there.

> I think modifying registers would not be as safe.

My point was that I think that in the event of unintended matching magic values, modifying registers would be safer than modifying memory. The reason I think so is that values in registers will possibly be discarded (and therefore ignored) by the caller anyhow.

Both memory contents and registers of course may or may not be in use.

> As said earlier, if I weren't sure of this scheme, I'd use int 15/8FFA
> instead. Oh, but I'm sure you would find objections, too...

All such schemes could obviously be in use by another program for other purposes already.

> > Then you might as well save some resident space by returning only
> > resident's segment; ie, by hardcoding the address of varjne in the
> > uninstaller too.

> As you observed, returning this
> address dynamically could allow for additional compatibility checks, but of
> course it is non essential that it be passed back thru the buffer.

What? You're already returning it dynamically. I only pointed out that passing this single address dynamically while hardcoding everything else is inconsequential. You might as well hardcode everything if you aren't properly returning all offsets (or a table with all offsets) from the resident interface.

> > the intermediate handler is allowed to call DOS itself

> > Because you are calling function 48h, ... calling function 48h and
> > the other memory allocation functions ... is allowed - even if the
> > InDOS flag is already non-zero.
>
> Oh NO! This is pure nonsense. Function 48 and DOS calls in general are not
> designed to be reentered, and any sound TSR must be aware of the fact. Any
> attempt to just reenter memory allocation fncts 48,49,4a,58... in the
> middle like that would yield horrible errors. By faking INDOS to the
> intermediate handler we forbid such absurd behavior.

This is pure nonsense. That DOS isn't designed to be re-entered is specifically the reason that any intermediate handler that intercepted a function 48h call can assume that the InDOS flag currently must really contain zero (even if it doesn't actually). After all, that is what DOS does itself: It assumes that InDOS is zero, ie that it isn't being re-entered.

The responsibility for checking the InDOS flag is only defined in this scheme for resident TSRs invoked "asynchronously", ie by hardware interrupts. Other than that, all reentrancy issues are dealt with by disallowing code called from within DOS to access DOS itself. (For example, an interrupt 13h handler isn't generally allowed to call DOS.)

> DOS does not randomly allocate memory for itself after sysinit,
> and especially not while it is servicing user calls.

Ah, is that defined in the official DOS standard? Obviously it isn't, since such a standard doesn't exist. And the implementation details of existing systems, such as any given version of MS-DOS, are not definitively precluding the possibility of such a DOS implementation. (Assuming one is not defining "compatible" as "same binary as MS-DOS", which would be a definition that would preclude one from discussing TSR implementation details with me - because I wouldn't bother with them.)

In any case, my point about intermediate handlers that (when intercepting properly inreentrant DOS functions) call into DOS without checking the InDOS flag is independent of whether you consider DOS static or extensible.

> Why would it /ever/ need to?

Be imaginative.

> And if you mean not the DOS core
> but an add-on, it is subject to the above reenterancy restrictions

Except when it isn't.

---
l

Complete thread:

• KBFR 1.9 beta discussion opened by CM - Ninho, 13.06.2011, 12:17 (Developers)
  • discussion - ecm, 13.06.2011, 14:49
    • discussion - Ninho, 13.06.2011, 19:28
      • discussion - splitting MCBs again - ecm, 13.06.2011, 20:20
        • discussion - splitting MCBs again - Ninho, 13.06.2011, 21:52
          • discussion - splitting MCBs again - bretjohn, 13.06.2011, 22:38
            • discussion - splitting MCBs again - ecm, 13.06.2011, 23:41
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 00:17
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 02:05
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:10
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:09
                  • ! - ecm, 14.06.2011, 05:17
                    • ! - Ninho, 14.06.2011, 05:59
                      • ! - ecm, 14.06.2011, 06:06
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 05:11
                • on overloading and AMIS - ecm, 14.06.2011, 05:50
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 13:38
          • discussion - splitting MCBs again - ecm, 13.06.2011, 23:33
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 01:31
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:20
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:05
                  • discussion - splitting MCBs again - ecm, 14.06.2011, 05:54
                    • discussion, & "retiring" for awhile - Ninho, 14.06.2011, 12:50
                      • DOSLFN, intermediate handler issued calls; "retiring" - ecm, 14.06.2011, 18:51
                        • intermediate handler issued calls - Ninho, 15.06.2011, 15:32
                          • intermediate handler issued calls - ecm, 15.06.2011, 16:50
                            • intermediate handler issued calls - Ninho, 15.06.2011, 17:53
                              • intermediate handler issued calls - ecm, 15.06.2011, 22:37