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, 13.06.2011, 21:52

> The problem with overloading any function is that there's no main authority
> where you can reserve function numbers.
Agreed. This is where my cute (modesty apart) "overloading" is in order.

> In what way would they be disturbed more if you specified cx as additional
> parameter and used it to verify the return values too?
A caller - the BIOS foremost, it is after all the "owner" of that interface -
but any caller (hello, Bret?) might assume no register except AL and the Carry flag will be changed across the int 15/4Fxx call. In practice BIOSes I've looked at do protect themselves, but I'm doing everyone a favor by not using registers other than the normally affected ones and then using the latter in a manner compatible with what the interface expects. Hence the apparently unnecessary passing of data thru a mem buffer provided by caller.
The detailed method affords additional protections both to me (as KBFR) and to int 15/4F callers, as does the choice of the /release/ scancode for a key that is inexistant anyway on standard as well as exotic keyboards. Enough said, or what will remain for that document I promised ?

>> I think you're mistaken, it's the installer portion that for convenience
>> uses some hard coded offset, not the uninstaller. BICBW.

> I wasn't entirely mistaken, and you were wrong: ...
Quite possibly. I am on and off at this, there are legacy details to be cleared and you probably know my code better than I do ;=) 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, which it does & w/o having to add bloat to the resident (discardable bloat is OK). The details of what additional data are exchanged is not crucial, nor do I consider a prime design objective that a random version of the uninstaller can remove a different version resident (especially if they are both betas!).

> (Note that hardcoding addresses inside resident in the installer is
> alright: The installer knows that this particular resident must be in use
> because it does the installing itself.)
That is the intent indeed.

>> I don't make it a sovereign goal to be tracer-friendly :=)

> Still leaves the direction and interrupt flag....
TBH I frowned a little upon my own use of RETf ... it appeared safe inasfar as (again speaking from memory rather than reading the code) the RETf 2 in question is hit only if returning from the private API call. I might change the RETf to an IRET, which unfortunately adds the overhead of modifying the stacked version of the flags.

>> I won't insult the reader by reminding that IRET back from DOS to my
>> code restores a cleared interrupt flag.

> Unless DOS or another resident interrupt 21h handler uses retf 2 to return
> from the interrupt call too ;-)
Dare they !!! :=)

>> And you agreed there a TSR
>> awoken during int 21/48 would not be well advised to mess with DOS mem
>> allocation.
(...)
>> Indeed they mustn't ! Ergo I think my critsec /is/ playing its role
> against
 >> unwanted MCB tampering.

> No. You misunderstood the subject of my agreement there. TSRs are not to
> mess with MCBs (too much) while the InDOS flag in DOS's SDA is non-zero.
> However, resident code (in particular any interrupt 21h handler as shown
> previously) is free to call down into DOS while that flag is zero. When an
> interrupt 21h handler is executed, the InDOS flag (which is usually
> modified by DOS) is still zero. Resident code that was invoked by
> intercepting your interrupt 21h function 48h call can assume that it is
> okay to call the DOS memory allocation functions right now (even without
> checking the InDOS flag*) - for your purposes, and for its own purposes as
> well.
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.

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 ?

>> Even if we weren't caring for criticality - we have to access those MCBs in
>> the course of installation anyway, as it stands it is a gain rather than a
>> cost to emulate DOS functions 49 and 4A.

> Second, your statement is not at all true for the environment's MCB; you
> aren't otherwise accessing that and using 21.49 would be easier there.
The gain then is in execution time :=)

> No*, but you said that what you uploaded is one week old already. Why
> didn't you upload a more recent development version?
> * 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.

> May the splitting of MCBs continue.
And some hair too, despite contrary allegations haha

Post reply
 

Complete thread:

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