Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

evaluation (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 29.05.2011, 17:26

This looks good. Some comments:

You could free the environment block before entering the "critical" part, and use 21.49 as usual.

If you changed your MCB splitting code to this, I don't think you would need to clear the interrupt flag:

mov word [3], newsize
mov byte [0], 'M'

You could also free the MCB using 21.49 then. The rationale behind this is that if the MCB contained 'M' initially, then the first instruction will resize the MCB appropriately. The second will effectively always be a NOP then, since the resized MCB must still point to the one you created. (It could hardly contain 'Z' suddenly.) If the MCB however contained 'Z' initially, then you're either at the very end of the MCB chain or you are modifying the MCB that points to the first UMCB (at segment 9FFFh if 640 KiB of low memory are in use). In both cases, making the MCB point to your new MCB while temporarily leaving the letter as 'Z' has none or no critical drawbacks. (If it pointed to the first UMCB and a TSR interrupts between the two instructions and that TSR allocates memory using DOS, DOS's behaviour with allocating UMBs would be erratic - however, no critical failure would occur.) At least that was my reasoning for executing this code without clearing the interrupt flag when I wrote MCB splitting code.

You could of course still include the clearing of the interrupt flag.

cli
mov word [3], newsize
mov byte [0], 'M'
sti

Exchanging the instructions in your code to this advantageous order where the MCB's size is adjusted first is still useful for tracing that code in a debugger, as debuggers disable any protection you get by clearing the interrupt flag.

Assuming your TSR image is still stored behind the installer and assuming that your stack is behind that, you do not need to leave the interrupt flag disabled during your 21.48 call, with or without this adjustment. As you noted, you do not execute in free memory and do not depend on data in free memory. Therefore, protecting the 21.48 call is not necessary. Attempting to justify your (arguably ineffectual) protection scheme isn't necessary either.

Other than that, you still seem to keep the "psp" variable around in the TSR and you still set the TSR's MCB's owner to 8 (so that MEM probably won't show your name properly). The variable is an optimization that isn't required, and the owner is a minor display issue that doesn't do any harm otherwise. So, as I said, this looks good.

---
l

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