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 Ninho E-mail, 14.06.2011, 01:31
(edited by Ninho on 14.06.2011, 02:08)

1. the int 154FFA scheme

>> 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.
And rightly so. It is not changed - except if the caller was validated to 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.

> 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.
The buffer is not modified, unless validated (bis). I think modifying registers would not be as safe.

> 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.
Evidently - but then the probability of a memory malfunction is certainly higher than what you envisage.

>> 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.
However it is a significant point, and also in a lesser measure the fact that
"release" scan codes (of non modal keys) are dropped by the PC BIOS anyway.

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...
Well, the switch [i]is(/i] definitely an appeling possibility come to think again. Even though my little subversive int 15/4F trick is defendable, there is no compelling reason to clutch to it.

>> 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.
Isn't coding/designing a series of choices, preferably coherent ones, some important and some less so ? I could pass less data from the resident to the (un)installer, or I could pass more! As you observed, returning this address dynamically could allow for additional compatibility checks, but of course it is non essential that it be passed back thru the buffer.

...
>> 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?
Yes, at least it is a good precaution. By resetting Cy we signal any observers, hookers, (even the initial caller if by witchcraft it were other than KBFR) - that the "scancode" has been dealt with and they should henceforth ignore it. Tis part of int 15/4F semantics.


2. DOS call reenterancy etc.

>> 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.
Oh NO! This is pure nonsense. Function 48 and DOS calls in general are not designed to be reentered, and any sound TSR must be aware of the fact. Any attempt to just reenter memory allocation fncts 48,49,4a,58... in the middle like that would yield horrible errors. By faking INDOS to the intermediate handler we forbid such absurd behavior.

> 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.
I don't buy this new fairy tale either. DOS does not randomly 'allocate memory for itself" after sysinit, and especially not in the middle of servicing user calls. What purpose would it serve? If you mean not the DOS core but an add-on, it is subject to the above reenterancy restrictions

>> 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 ;-)
Just some relief and a pair of smileys

---
Ninho

Post reply
 

Complete thread:

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