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 ecm Homepage E-mail, Düsseldorf, Germany, 13.06.2011, 20:20

> An alternative (int 15/8F, apparently unused elsewhere) was considered and
> reserved in case
The problem with overloading any function is that there's no main authority where you can reserve function numbers. (In fact, there never was. Off-topic.) By which I mean: There could be other programs already using 15.4FF4 or 15.8F for other purposes. And they can't detect that your program is servicing those instead, because they can't know your program's interface. That is basically the same problem as that of interrupt 2Fh usage as TSR multiplex interrupt.

> Precisely because of the "overloading" : int 15/4F callers and hookers must
> not be disturbed.
In what way would they be disturbed more if you specified cx as additional parameter and used it to verify the return values too?

> 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: The uninstaller hardcodes the address of introu15 (to determine whether the current topmost interrupt 15h handler is that of the resident code) and as I said it hardcodes the address of orgint15 (to move the next interrupt 15h handler to the top if successfully uninstalling the resident code).

Of course I don't know whether your development version contains other code there, I'm just looking at the week-old source code that you uploaded recently.

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

> I don't make it a sovereign goal to be tracer-friendly :=)
Still leaves the direction and interrupt flag. The latter arguably isn't critical. The former however, left in the wrong state (which could have been set by a previous interrupt 15h handler that chained to your handler via jumping and assumed you would iret properly instead of using retf 2), can easily cause a program to crash.

> 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 ;-)

> And you agreed there a TSR
> awoken during int 21/48 would not be well advised to mess with DOS mem
> allocation.
>
> > ... my assumption was wrong. While in DOS (potentially in
> > code messing with MCBs itself: 21.48 or 21.4A or 21.5803 or 21.4B or
> > 21.67) TSRs must not alter MCBs...
>
> 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.

* Because the intercepted call is one that would call DOS's function 48h memory allocation code.

> 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.
First, to be precise, you are not emulating function 4Ah because function 4Ah is not the "split a memory block into two and free the lower block" function. In splitting memory blocks (without freeing either), you are emulating some particular functionality that is (presumably) internally implemented in DOS's function 4Ah handling as well. There is a difference. (And no, we aren't splitting hairs here. It's MCBs ;-) )

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. Your statement is somewhat true for the process's MCB, but note that if you would use 21.49 for freeing that instead, then the MCB splitting operation (which shrinks the process MCB and insures its MCB letter is 'M') would be the only write access to the process MCB. This way, you would also use the formally correct and "monitor-able" DOS function for freeing the MCB (think 21.25 vs. direct access).

(Also note that with entire process relocation, you never directly read from or write to the initial process MCB. But I guess I provided enough shameless plugs for my method in past posts already.)

> Would you like if I uploaded a new package for every little change I do ?
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.

> So long... (pun intended of course)
May the splitting of MCBs continue.

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