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, 22:37

Ugh, forgot to save my half-written post elsewhere before I closed my browser. I'll reconstruct this from memory, so complain if you don't understand anything.

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

You can't say that about both interceptor- and interrupter-type TSRs. The interceptor arguably should behave in a way so as not to break the semantics you expect, but if the interrupter interrupts the currently processed 21.48 call at the right time, then it doesn't know that your 21.48 call is currently being serviced. So it can't avoid breaking the semantics you expect in that case.

> you would say, function 48 caller asks for a
> certain size block, so if it gets one, who's to complain ?
Basically yes, even though that's not my main point.

However, as noted, the interrupter conceptually could have interrupted your program earlier and could have allocated memory way before you issued your 21.48 request to the topmost interrupt 21h handler. (In practice, you can keep the interrupter out for some time by disabling interrupts in your own code. But by calling interrupt 21h, you accept that interrupts may be enabled elsewhere - and that therefore the interrupter might gain control.)

> But [the caller] has the right to expect DOS to allocate that block
> following a specified algorithm
Still disagreeing.

> besides his right is confirmed by the ability to choose between several
> allocation "strategies".
I don't think the strategies are that important. For example, disabling the UMB link (21.5803.bx=0) overrides all area specifications in the current strategy and searches in the lower memory area instead. (Yes, even if one of the 40h strategies (Upper memory area only) was set.)

> Clearly a TSR which follows scenario number 1 is "cheating"
> our foreground prog.
Again, even though arguably the interceptor should behave so as to fulfil your expectations, the interrupter can't know it is interrupting your program after your program called interrupt 21h to issue a 21.48 request.

> It does matter, not size-wise :=) but position-wise it does.
No, I meant it doesn't matter optimality-wise either.

> I think the TSR has no right nor reason to "speculate" thusly
The (intercepting) TSR must speculate one way or another. Either it issues its own request before the caller's, or after the caller's.

As I explained, if the interceptor deems its own allocation permanent, then it is advantageous to issue its own allocation request first. It isn't advantageous to issue it afterwards.

So if the interceptor needs to allocate memory permanently and you disallow it to issue its own allocation request first, you'll often (every time there's a temporary allocation made using 21.48) force the interceptor to use the worse method.

I thought of another reason why it is advantageous for the interceptor to issue its own request first. Actually, a classic reason for issuing any interceptor's own requests to the intercepted service before issuing the caller's request. Examine this interceptor:

i21:
    cmp ah, 48h
    je .handle
.chain:
    jmp far [cs:.next]

.handle:
    ...
    push ax
    push bx
    ...
    mov ah, 48h
    mov bx, ...
    pushf
    push cs
    call .chain            ; call for this handler's own request
    ...
    pop bx
    pop ax
    ...
    jmp short .chain       ; chain for caller's request

Now examine this one, modified to issue the caller's request first as you demand:

i21:
    cmp ah, 48h
    je .handle
.chain:
    jmp far [cs:.next]

.handle:
    ...
    pushf
    push cs
    call .chain            ; call for caller's request
    push bp
    mov bp, sp
    rcr byte [bp+6], 1     ; flip
    rol byte [bp+6], 1     ; flop
    pop bp
    ...
    push ax
    push bx
    ...
    mov ah, 48h
    mov bx, ...
    pushf
    push cs
    call .chain            ; call for this handler's own request
    ...
    pop bx
    pop ax
    ...
    iret

As you see, in this case the intermediate handler can never simply chain to DOS (as it needs to post-process the results of its own requests). Because of that, and this order of requests (where the caller's request can't be the last one) it also needs to correctly pass the Carry Flag from DOS to the original caller.

> If you will, with the understanding that interference during the...time
> frame should be disallowed.
"Should", but it's not possible to.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum