Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

intermediate handler issued calls (Developers)

posted by Ninho E-mail, 15.06.2011, 17:53

>> 1. the "hooker" MUST NOT do its own (private, hidden) 21/48 call BEFORE
>> effecting the user's (more foreground). That would be IMO a bug (because
> it changes the actual result expected by the foreground program)
>
> I disagree.
Then I agree to disagree. Or, I would replace the term "bug" by "bad design", at the very least.

> The caller shouldn't expect anything in that way.* After all, calling
> interrupt 21h means to expect that interrupts might be enabled at some
> point. And that means that a TSR which is activated by a hardware interrupt
> could interrupt the currently processed interrupt 21h call and allocate
> memory for itself before the interrupt 21h call reached DOS's function 48h
> handler.
This is the same point. In general because a DOS TSR (in the general acception) is in a position to break the expected "semantics" of exterior DOS calls does not imply that it should indulge itself into doing so, especially when it's gratuitous.

I admit there are disputable limits. Take the specifics of this DOS "request memory block" : you would say, function 48 caller asks for a certain size block, so if it gets one, who's to complain ? But in fact caller expects /more/ than just any properly sized block, he has the right to expect DOS to allocate that block following a specified algorithm [this is an important difference from XMS/EMS], besides his right is confirmed by the ability to choose between several allocation "strategies". Clearly a TSR which follows scenario number 1 is "cheating" our foreground prog.


>> Besides there is little reason you would want to program the "hooker" in
>> that rude manner. Presumably the mythical utility will use its hidden
>> memory chunk to record or annotate the foregounder's memory operation,
> it
 >> had better wait till DOS returns.

> Why? If its allocation is just as permanent as that of the caller, then it
> doesn't matter (memory-layout-wise) whether the intermediate handler does
> its own or the caller's allocation first.
It does matter, not size-wise :=) but position-wise it does.

> If the intermediate handler's own allocation can indeed be said to be
> permanent in some way, then it is (from the handler's point of view)
> advantageous to do its own allocation first - because the caller _might_
> want to allocate that memory only temporarily. And if that was the case,
> then the resulting memory layout would possibly not be optimal if the
> handler allocated (temporarily used) memory for the caller first and then
> allocated (permanently used) memory for itself afterwards.
I think the TSR has no right nor reason to "speculate" thusly

>> 3. However, much better would be for your "hooker" to do its underground
>> memory reservations, not from conventional memory which is a precious
>> resource and should not leak or move or vanish mysteriously. Using
> scratch
 >> memory from XMS or EMS or similar looks right. This is no more 1981 !
>
> Then we'll be discussing whether your XMS or EMS memory allocation scheme
> is optimal instead :-P
Not comparable : EMS or XMS blocks real location is opaque in principle, there is nothing to "optimise" (from the client's PoV; of course the EMM or XMM is allowed and encouraged to do its own optimisation and move blocks around.)


>>> Notwithstanding the (im)possibility of always optimal placement,
>> Optimal placement is granted unless backgrounders don't behave. If not,
>> so much the worse!

> I would rephrase this as: Optimal placement is achieved if no resident
> software interferes with temporary allocations during one particular time
> frame. If not, then oh well the placement isn't optimal but that isn't the
> end of the world or anything.
If you will, with the understanding that interference during the...time frame should be disallowed.

> As replacing 21.48 entirely is undesirable, that's (almost*) the best
> method there is.
Agreed. And the risk of interferences of the kind we've been making precise, whether you call them bugs or not, is small in the real world (I dare hope it is). Still for when things go better I do not exclude making KBFR walk the (low mem only) MCBs. It's not conceptually complicated (no need to process the general case) and might give us somewhat of a warm feeling.

---
Ninho

Post reply
 

Complete thread:

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