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, 23.05.2011, 13:18

> For the TESTING COMFORT of non-French users, I made KBZERO.EXE
Appreciated.

> assemble with MASM (I used 6.15)
Would it work with JWASM too? I don't really care right now, though if I ever wanted to assemble it...

> important is to present the objects in the following order
Shouldn't it be possible to make it independent of the order if you relocate the entire process? Depending on the memory layout it might be possible.

> optional bit of hokus-pokus to adjust and shrink the header of the resulting EXE
Just use flat .COM executables if the .EXE header size worries you ;-)


Now here's what I determined during testing:

As you noted in KBRES.ASM, the "trans" function can be inlined to save some bytes.

The "drvflgs" variable in the Int2F resident part is apparently not used.

I do not see why the "psp" variable has to be in the resident part, either. It's apparently used with 21.49 by the deinstall function, however, isn't it sufficient if the function determines itself which memory block to free?

I see that you do relocate your PSP and all. Why didn't you choose to change the UMB link status and allocation strategy while allocating the memory block for the resident part then? I consider a program's ability to relocate itself into a UMB a feature.

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.

I prefer activating the new PSP via process termination. Theoretically, if any resident program associates resources with our PSP address, my method might prevent leaks. In practice it probably doesn't matter though.

You use 21.4A to resize the part of the process which contains the old PSP. This means your new PSP is in free memory after DOS's MCB resizing finished. (It doesn't matter that even the DOS algorithm could overwrite your new PSP since any resident code interrupting your program's run at that time is allowed to allocate and overwrite the memory block anyway.) The best solutions to this are in my opinion: (a) do not split memory blocks at all, instead, relocate the entire process to an entirely new memory block, or (b) if you choose to split memory blocks, do not use this unsafe 21.4A method; instead, prepare the new MCB yourself and modify your old MCB to point to that one. The new MCB must be created with the letter read from the old one, and you have to set the old one's letter to 'M' afterwards.

You free your process's memory block partially after relocating the PSP. However, you have not relocated your program code. Your installer executes in free memory after that. This is far worse than the previous issue because you do issue 21.48 (to allocate the TSR's memory block) yourself while executing code in free memory. If DOS happened to allocate a memory block overlapping your program the latter might get overwritten. Note that the critical part of your program which must not be overwritten here includes the TSR's image that you copy into its block later.

The 21.48 request to allocate memory for your resident program definitively needs an error check.

Why do you set the TSR's MCB to "SC", owner 8? I prefer to set my TSR's MCBs so I can distinguish them: self-owned with a more or less descriptive name.

Related insignificant nitpick: Your new PSP's MCB's name is uninitialized. That's of course not important since that name is never visible except in debuggers.

Even if you fixed the issues with using free memory, your method might fail to place the TSR at the optimal position if your resident memory requirements grew larger than the size of the old process's and PSP's memory block that you free. To overcome this limitation, you have to relocate the entire process to a new memory block.

Other insignificant nitpicks: Why do you calculate the size of the TSR at run time? I see that you have to dispatch between the value for the removable TSR and the non-removable one, but that still doesn't explain why you don't use the assembler to do the shifting and such at build time. Similarly, why did you hardcode the "32 bytes" message? Just let the assembler calculate the memory block size difference between the removable and non-removable TSR and write that into the message.

---
l

Post reply
 

Complete thread:

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