Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

review (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 24.05.2011, 00:45

> > Shouldn't it be possible to make it independent of the order if you
> > relocate the entire process?
>
> I find it more elegant to relocate the resident in one move,
I don't think this can be properly done; not generally, anyhow. If your TSR is smaller than the PSP, or the TSR fits into the memory block that you would split off after the PSP's relocation (this can include some of your program code), then this might be sufficient. This appears to me to be more complicated and restricted though.

> and not have
> to ask for an auxiliary memory block, yielding complications if DOS
> couldn't allocate one (since the resident part is so small it may be not be
> a problem in practice but it might when installing high into a small umb
> for instance).
Just set a proper low-only, last-fit allocation strategy (21.5803.bx=1 then 21.5801.bx=2) and you'll allocate a proper temporary memory block in all cases. I found this method to be the least complicated one. It always causes the least fragmentation, assuming the largest low memory block is at the top of the low memory area, which is a reasonable assumption.

Note that a process loaded from a flat .COM executable into the low memory area has to resize its process memory block first since otherwise the subsequent 21.48 call usually fails to allocate a memory block in the expected position.

Note that relocating something to the top of the low memory area may overwrite a shell's transient code which would require the shell's resident code to reload that from the executable, XMS, or whatever they use for swapping. This can be avoided by allocating, or trying to allocate, a temporary memory block that is X bytes too large for the installer's purposes and not modifying the additionally allocated part; where X is a number assumed to be larger than the shell's transient code size. Note that this is entirely a performance optimization; the only disadvantage of not doing this, or choosing an X that is too small, is that the shell has to reload its code.


> The badly named "psp", really the resident segment value, is returned by
> the communication routine (int 2F).
It's not, that handler reasonably returns its own CS. The only time the resident "psp" variable was accessed in an installed TSR was from the deinstaller.


> This version was delivered to test and evaluate the "load low" option. It
> had all UMB management removed.
However, see my remark regarding complete process relocation to a temporary memory block. For optimal results, independently of whether LH was used, one has to specify both strategy and UMB link status using 21.58 anyhow. Otherwise, the temporary allocation (even if allocated with strategy 2, supposedly, quoth RBIL, "Low memory last fit") might just end up in a UMB. So some of the UMB management would have to be included for that anyway.


> > It's true that DOS doesn't use the PSP beyond offset 50h. I don't see a
> > reason not to relocate the entire PSP though.
>
> Elegance for one.
Don't see it here.

> And memory usage,
I see. But I would consider such constraints a disadvantage of storing the relocated PSP in space that is a part of the process's existing stack.

> enlarge the stack ... (hence the whole executable memory footprint)
Yes? I don't think your executable..., oh. Got me there. When you say "executable" I always think of the program's file. I say "process" or "program" when I mean the live program's memory usage.


> That's splitting hair.
Told you it's theoretical.

> Would a foreign TSR hijack our PSP ? Any
> interrupting TSR which allocates resources for itself must activate its
> *own* PSP first, it would seem.
I thought of some resident code tracking some kind of resource for every process, like, say, the environment. Now the normal DOS environment memory block is well known to everyone so it's easy to free that specifically, but if there was, say, a "hidden environment"-like resource associated with each process, then 21.4C relocation avoids leaking such resources. I don't know of any software creating such hidden resources, but it's a possibility.

More generally, I think changing the active PSP via 21.50, or direct DOS internal data manipulation, is fine if you go back to the previous PSP later on, like, say, a TSR or debugger setting its own PSP with 21.50 while it interrupts the currently running program. When it's done, the interrupting code uses 21.50 again to reset the active PSP. However, both the debugger and the TSR should ensure that their PSPs as well as the running program's PSP are properly terminated by process termination DOS functions.

> It's not like we are *calling* a TSR as a service
That's true. And as I said I'm not aware of any concrete program creating hidden resources for other processes on its own.


> But this
> time I found it interesting to try and put DOS functions to work whenever
> possible rather than direct manipulation of structures.
That's generally useful to keep in mind, but I think splitting memory blocks cannot be properly done without MCB manipulation if you want to keep the upper part.

Back when I did more of this TSR stuff (2009?) I found that the least complicated method remained complete process relocation. Of course you have to modify MCB names and owner fields as usual, but you don't have to create an MCB from scratch, as you have to do if you want to split a memory block and keep the upper part.

> This bug I think is simply the order of the steps. Simple fix (referring to
> the numbered comments in the code) : do steps 3.2 & 3.3 /before/ step 3. In
> fact I can't believe I couldn't see this before submitting.
No, you don't appear to understand the problem. If you modified the installer like that, it would still depend on (a) data in free memory to stay unchanged and (b) the free memory MCB to be large enough, when, in fact, DOS could have created this MCB with a data size of zero.

Now about (b), some will tell you that a DOS that doesn't behave exactly like MS-DOS in memory allocation functions isn't compatible enough. I don't think so. I don't want to depend on the assumption that the created MCB is of a proper size. In any case, resident code can interfere with this in any imaginable way still - that's of course a consequence of (a) as well.

Another more common problem with (b) is that in fact the free MCB created in the 21.4A request might be way too large. I don't remember the details, but it might be the case that MS-DOS doesn't collect free memory blocks after 21.4A. Again though, I don't want to consider this a DOS compatibility requirement.

> Easily done, yet I believe 21/4A will be safe if done in the revised
> order.
I do not see how it can be used safely in this way.


> Step 3.4 (freeing our old, previously shrinked, container) appeared
> necessary because allocation of the resident block (step 3.5) must be
> allowed to step over the start of our program. That was the central idea. I
> wanted to avoid having to request extra memory, as already said.
You'll have to split your memory block at a lower address for this to work properly, in such a way that the TSR image and the remaining installer code will remain inside allocated space. This will make it depend more on the program's memory layout, or generally speaking it makes things complicated.

> Is there a way to make : (free, then allocate) into a "critical
> section" of sorts ?
No, and that's not necessary if you properly keep all the data you need inside allocated space.

> I don't suppose "CLI" would suffice, would it ?
It wouldn't suffice if you called 21.48 since DOS or other Int21 software might enable interrupts or modify MCBs itself.


> steps I've taken ensure this allocation can't fail
I don't think you can really ensure it won't fail given the possibilities of other TSRs. Of course failure is improbable here!


> > Why do you set the TSR's MCB to "SC" ...
>
> This was left as per Japheth. If it turns out later on that we have to walk
> the MCBs for some reason, we may revise it. As we don't ATM it's a no
> brainer.
It's more convenient for the user to see what program uses what memory block in MEM's display.


> > Similarly, why did you hardcode the "32 bytes" message?
>
> It's only printed by the test Kbzero version, I think.
True, the French text says "32 octets" instead ;-)


> Did I thank you for the review, comments and time passed ? Much
> appreciated!
Hah, I sure wouldn't do this if I wasn't interested in it myself.

---
l

Post reply
 

Complete thread:

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