Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

hardly a 100% solution (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 29.05.2011, 22:17

> Indeed
> if some interrupt-activated resident chimes in after freeing but before
> allocating, it could itself allocate from one or both of the blocks we've
> just given back ! That would not be an error, as far as DOS is concerned,
> but could spoil our hopes for optimal placement of our own resident (this
> seems to apply equally to your system, as far as I've understood it without
> actually seeing an example).
Yes, it does apply to my system. Yes, it could temporarily allocate memory in such a way as to prevent optimal allocation.

However, as you said, that would not be an error (not just for DOS, in fact, it wouldn't be an error for anyone). The system cannot possibly crash that way. The worst that could happen is that the TSR allocated so much memory that our 21.48 call would fail. (I told you you should check for an error there!) Otherwise, it might still cause less optimal placement as you said.

While the possibility exists, this is also somewhat unlikely.

Additionally, if the TSR's allocation could be said to be permanent in some way, then our 21.48 would not make a "less optimal" allocation - because, in fact, the TSR's allocation would have changed the memory layout then. Hence I said that specifically a TSR temporarily allocating memory could cause less optimal placement.

Because the system isn't unstable after such an incident, the user could easily unload our TSR and install it again - probably achieving optimal placement this time.

All in all, I am aware of such possibilities but do not consider them a big issue. And it's hard to completely work around them.

> Putting the section under the protection of CLI will prevent this from
> happening, because as I commented, although DOS /will/ STI (a good thing
> anyway), a well written TSR that would be invoked while int 21 has been
> entered shall either postpone its popping up until better times, or if it
> does activate it shan't try to reenter DOS or access internal DOS
> structures (unless first swapping, not just the usual SDA but pretty much
> the whole DOS "list of lists").
I have to admit you are right in that TSRs mustn't muck with MCBs (too much) while in DOS since DOS could be processing a 21.48 or 21.4A call. However, observe:

int21:
; IISP header or whatever here.
        ...
; Dispatcher here.
        ...
; Some kind of processing here.
        ...
; Ah! I need some memory.
; Should be safe to call DOS because I'm processing Int21 here
; and the service I've hooked is one that would enter DOS anyway.
        mov ah, 48h
        mov bx, somesize
        int 21h
; etc.

So resident code hooking Int21 might access memory precisely because of your Int21 call.

> which is what kept me awake for part of last nights,
I hope this didn't inconvenience you!

> Returning to the protection problem, ...
> there would be at least 2 other, more radical ways
> to solve it if the solution above was not enough : 1- do the allocation by
> hand, without calling DOS (tedious.) An advantage is that we can program
> the search so it "knows" about the blocks we are ready to provide, so that
> we could do without actually freeing them and without the CLI.
However, resident code could still prevent optimal allocation if it did its allocations earlier and if the optimal place for the TSR isn't where our environment or our process is placed. (In fact, I don't think you can prevent resident code interference with any loading scheme. Even if it was built into DOS. To ensure optimal placement in any case, you would have to ensure that all resident code would never allocate memory.)

> Alternate method 2- don't CLI around the section, but mask interrupts at
> the PICs. I don't like this too much. We would unfortunately need to mask
> all IRQs, because while the keyboard, timer and RTC irqs are fixed, the
> mouse (or other contraption) IRQ whose number is impredictable.
Ah yeah. I don't like this either. Too hardware-dependent. And would this even work in V86-mode, if running, say, Jemm?

And it still wouldn't avoid resident Int21 handler code interference.

---
l

Post reply
 

Complete thread:

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