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 ecm Homepage E-mail, Düsseldorf, Germany, 15.06.2011, 16:50

> Some confusion came from the use of the term TSR, that in general I take
> to mean a (HW)interrupt activated TSR. What you have here are soft int 21
> hookers (of course they are also TSRs in the general sense).
Ah, I see. I usually note it specifically if I am talking about "asynchronously" hardware interrupt activated, or "pop up" TSRs. The term TSR otherwise means TSR in the general sense to me.

(Though actually, "Terminate and Stay Resident" isn't even that good a specifier for some of the programs I would describe as TSRs.)

> 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.

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.

Whether the intermediate allocation is in fact issued by an interrupting TSR or by one which is intercepting the function 48h call is a hidden detail that doesn't change the caller's situation.

* If the caller did depend on such expectations to be true, that would in my opinion be a bug (because such dependency makes the scheme so fragile it obviously can be broken by resident software or incompatibilities). Fortunately, your installer doesn't generally depend on that.

> 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.

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.

> 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

> > 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.

As replacing 21.48 entirely is undesirable, that's (almost*) the best method there is.

* To illustrate, there's better methods available that, though not replacing 21.48, are nonetheless overly elaborate:

For example, one could _not_ free the process's environment and the memory used by the old PSP initially, then allocate all available memory as fast as possible, then decide which location would be best for the TSR - and relocate the process and TSR image as often as necessary to get the latter there. Afterwards, all memory not used by the TSR is of course to be freed.

A less extreme method would not free the environment and PSP memory initially as well; it would instead resize both of those blocks to the largest possible size and then try to allocate a third block (with the exact size required by the TSR). It would then decide which location inside the allocated blocks would be the best for the TSR. Relocation and freeing of the unused memory later would behave like in the previous method.

The only advantage these two extreme methods have over our current methods is that the time frame during which temporary allocations of other resident software can disrupt optimal placement would be shortened - it never goes away. (If in doubt, imagine again that resident software might temporarily allocate some memory even before the TSR's installer process is loaded.)

---
l

Post reply
 

Complete thread:

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