Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

discussion - splitting MCBs again (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 14.06.2011, 05:54

> > 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 ?
No, obviously I wouldn't. But, yes, I do believe it to be true.

> > 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).
No, in that way DOS doesn't assume that the InDOS flag ever contains the value zero. However, it doesn't check the InDOS flag before incrementing it.

In that context, it can be said that DOS and other handlers of inreentrant interrupt 21h functions conceptually assume the InDOS flag to be zero because they are about to enter DOS: _they cannot be inside DOS yet_. If they in fact are inside DOS already (which means actually in a DOS call or the InDOS flag was faked up) it is the caller's responsibility to have handled conflicts.

> > 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.
Code that can be called from DOS isn't allowed to simply call DOS, since it could be re-entering DOS then.

> > 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.
>
> 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.
I can't provide one that specifically intercepts the memory allocation functions right now (without writing it myself), but you can for example take a look at DOSLFN's source code: it hooks interrupt 21h and extensively works with the InDOS flag (incrementing it by itself additionally, to avoid being re-entered itself) yet it doesn't check the InDOS flag before calling down into DOS.

For one particular example, any 21.71 call can cause DOSLFN to (try to) reload its Unicode translation table, using 21.3D, .3F, .42, and .3E, if the current DOS code page has changed since DOSLFN last had been called.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 202 users online (0 registered, 202 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum