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, 13.06.2011, 23:33

> This is where my cute (modesty apart) "overloading" is in order.
Your overloading is problematic independently of whether you overload functions or subfunctions.

> The detailed method affords additional protections both to me (as KBFR) and
> to int 15/4F callers,
It doesn't. A caller might just as well assume that dword[ds:si+4] isn't changed.

In fact, using a pointed-to buffer might increase the risk there: if a caller accidentally does call your special function without knowing about the modifications you make, then if you only modified registers I would assume it is more probable that this modification doesn't affect the caller - as opposed to having modified memory at some random location.

This is obviously very theoretical. If any caller accidentally and unknowingly hits all the exact magic values for your overloaded interfaces, you are in for some trouble.

> as does the choice of the /release/ scancode for a
> key that is inexistant anyway on standard as well as exotic keyboards.
As I said, I'm no expert on the keyboard interface. Therefore I will ignore this for now.

> That said, the
> intended use behind the communications scheme is to provide the uninstaller
> with a simple and sure way to identify an active resident instance,
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.

> design objective that a random version of the
> uninstaller can remove a different version resident
Disagree.

> (especially if they are both betas!).
Agree, somewhat.

> it appeared safe inasfar as the RETf 2 in question is hit only if
> returning from the private API call.
Bad enough. You'll have to insure not to depend on the direction flag value after the call in your program. (And if theoretically an unaware caller happens to get there, they could be in even more trouble than otherwise.)

> I might change
> the RETf to an IRET, which unfortunately adds the overhead of modifying the
> stacked version of the flags.
Yes, you'll have to access the flags image on the stack then. But do you have to modify the carry flag?

> Right, I think can see the whole picture now. I was sort of forgetting to
> take in consideration cases such as of an "intermediate" int 21 handler,
> interrupted by hardware while processing KBFR's int 21/48.
That's one way it might happen, if the intermediate handler enables interrupts. However it doesn't even have to be interrupted: The intermediate handler is allowed to call the DOS memory allocation functions itself.

> Seems I want to do both CLI *and* increment INDOS myself, one or the other
> alone is deficient, but doing both saves my face, doesn't it ?
No, the intermediate handler is still allowed to call DOS itself, as I mentioned in my previous reply. Because you are calling function 48h, the intermediate handler can assume that calling function 48h and the other memory allocation functions for its own purposes is allowed - even if the InDOS flag is already non-zero.

Furthermore what we are calling an intermediate handler could even be part of DOS itself; a compatible DOS system could easily allocate memory for itself after entering its critical section (incrementing the InDOS flag) but before servicing your call.

> The gain then is in execution time :=)
Then please never use interrupt 21h functions 25h, 35h, 48h, 49h, or 4Ah. You don't want to be inconsequential, now do you ;-)

> > * On the other hand, a public svn (or git, hg, ...) repository would
> allow
> > access to every little change without much inconvenience.
>
> I have /really/ less time and more other, tangible problems in front of me
> than you may believe.
That was only an off-topic note, not a demand.

---
l

Post reply
 

Complete thread:

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