evaluation (Developers)
snippety snip....
> Assuming your TSR image is still stored behind the installer and assuming
> that your stack is behind that, you do not need to leave the interrupt flag
> disabled during your 21.48 call, with or without this adjustment. As you
> noted, you do not execute in free memory and do not depend on data in free
> memory. Therefore, protecting the 21.48 call is not necessary. Attempting
> to justify your (arguably ineffectual) protection scheme isn't necessary
> either.
I think it is useful to attempt to protect (CLI or otherwise) the whole section which {frees some of our memory, then DOS-allocate} and the rationale for that in fact was suggested by our prior discussions. 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).
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").
> So, as I said, this looks good.
I hope so. Returning to the protection problem, which is what kept me awake for part of last nights, 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.
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.
Anyway and fortunately, the current proposed method looks "just right",
if implemented properly :=)
---
Ninho
Complete thread:
- keyb: new! memory scheme, easy TEST - Ninho, 22.05.2011, 19:10 (Developers)
- boring - ecm, 22.05.2011, 23:58
- boring - Ninho, 23.05.2011, 01:20
- not that boring after all (nt) - ecm, 23.05.2011, 13:27
- boring - Ninho, 23.05.2011, 01:20
- review - ecm, 23.05.2011, 13:18
- review - Ninho, 23.05.2011, 23:10
- review - ecm, 24.05.2011, 00:45
- review - Ninho, 24.05.2011, 12:50
- review - ecm, 24.05.2011, 15:20
- of TSR powers & limits - Ninho, 25.05.2011, 11:24
- Swap! - ecm, 25.05.2011, 14:13
- of TSR powers & limits - Ninho, 25.05.2011, 15:14
- Swap! - ecm, 25.05.2011, 14:13
- of TSR powers & limits - Ninho, 25.05.2011, 11:24
- review - ecm, 24.05.2011, 15:20
- review - Ninho, 24.05.2011, 12:50
- review - ecm, 24.05.2011, 00:45
- fix - Ninho, 29.05.2011, 14:36
- opinion - ecm, 29.05.2011, 14:49
- opinion - Ninho, 29.05.2011, 16:36
- evaluation - ecm, 29.05.2011, 17:26
- evaluation - Ninho, 29.05.2011, 21:00
- hardly a 100% solution - ecm, 29.05.2011, 22:17
- hardly a 100% solution - Ninho, 30.05.2011, 19:26
- hardly a 100% solution - ecm, 30.05.2011, 19:33
- hardly a 100% solution - Ninho, 30.05.2011, 21:14
- hardly a 100% solution - ecm, 30.05.2011, 21:20
- hardly a 100% solution - Ninho, 30.05.2011, 23:50
- allocation no higher than the PSP - ecm, 30.05.2011, 23:56
- allocation no higher than the PSP - Ninho, 01.06.2011, 18:56
- allocation no higher than the PSP - ecm, 01.06.2011, 19:10
- allocation no higher than the PSP - Ninho, 01.06.2011, 18:56
- allocation no higher than the PSP - ecm, 30.05.2011, 23:56
- hardly a 100% solution - Ninho, 30.05.2011, 23:50
- hardly a 100% solution - ecm, 30.05.2011, 21:20
- hardly a 100% solution - Ninho, 30.05.2011, 21:14
- hardly a 100% solution - ecm, 30.05.2011, 19:33
- hardly a 100% solution - Ninho, 30.05.2011, 19:26
- hardly a 100% solution - ecm, 29.05.2011, 22:17
- evaluation - Ninho, 29.05.2011, 21:00
- opinion - Ninho, 30.05.2011, 19:04
- sti - ecm, 30.05.2011, 19:26
- evaluation - ecm, 29.05.2011, 17:26
- opinion - Ninho, 29.05.2011, 16:36
- opinion - ecm, 29.05.2011, 14:49
- review - Ninho, 23.05.2011, 23:10
- boring - ecm, 22.05.2011, 23:58