DOS ain't dead

discussion - splitting MCBs again (Developers)

posted by Ninho , 14.06.2011, 04:05

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

96 - possibly more - counting preset parts of the buffer meant to be checked by the resident. Indeed not implemented in the published test version. My bad. 24 bits really are less than I would deem acceptable.

Switching to int 15/8F will allow the relaxing of constraints on the use of registers, make sanity checks simpler too and might be a minor but net gain in code size even. Definitely a winner.

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

Collisions can be designed against, accounting for probabilities. The advantage of int 15/8F, or any other int 15 subfunction for which no previous use is known, is evident still.

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

You would repeat this under oath ?

> After all, that is what DOS
> does itself: It assumes that InDOS is zero, ie that it isn't being
> re-entered.

And this, too ? I mean - limiting ourselves to MSDOS for specifics - it's been my understanding that DOS /increments/ InDOS upon entry and /decrements/ it back on exit (with internal nesting possibly), nowhere does it /assume/ InDOS=0 (but it does /test/ for inDOS =/= 0 on occasions).


> The responsibility for checking the InDOS flag is only defined in this
> scheme for resident TSRs invoked "asynchronously", ie by hardware
> interrupts.

Agreed

>Other than that, all reentrancy issues are dealt with by
> disallowing code called from within DOS to access DOS itself.

Sorry I don't know how to parse that.

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

Agreed, formally at least. There is more or less a de facto standard, the limits of which are somewhat fuzzy... But you are wandering too far in your supputations. I want to code for MS-DOS first in any case, and I may consider limited adaptations to small deviances in other DOSes.

> not defining "compatible" as "same binary as MS-DOS",

of course not. Be serious please

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

All of which would be very dangerous, without even too much imagination.
The way DOS is architected - not just an implementation - pretty much precludes or at least constrains bizarro scenarios like some of which you offered as examples. IMHO and I am challenging you to show an actual int 21 hooker which does the kind of shenanigans (did I get the word right?) you've been advocating repeatedly, like call DOS memory management functions or mess with MCBs directly inside of a user initiated int 21/48 etc, call, and still withstands testing successfully.

---
Ninho

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