One of the things to do when uninstalling any TSR is releasing its memory allocation(s) to DOS. I've seen this done by code within the allocation that is to be released. So after freeing the memory there are still instructions left to be executed. This works on DOS because apart from zeroing the owner field in the arena header (the paragraph of memory in front of every allocation) DOS does not tamper with the contents of the allocation.

How safe can a resident uninstaller that works this way be considered?

Imagine an OS more biased towards confidentiality and thus wiping clean the allocation the moment it is released!
Imagine an industrious TSR hooked at the system timer and waiting for an opportunity to get some extra memory!

Aren't you forgetting that DOS has no memory protection and is no re-entrant OS even if you consider INDOS flag? There are billions of ways to actually make the system hang or break it's internal structures...

Basically after freeing memory (using int 21h function 49h) you should return from interrupt ASAP assuming you are calling free memory from your ISR. Nevertheless you shouldn't call int 21h from your timer ISR because you will break something without proper checks

Secondly if you really need more memory why not get away with help of DOS Extender, DPMI or VCPI or XMS/EMS?

During the execution of your unloading function, if interrupts are disabled (which probably is the case), you could say that it's rather safe to free the memory, but you shouldn't do it by calling int 21h. Instead, first disable whatever triggers your ISR, so that nobody jumps to the free memory area later; then set up registers as if you were going to call the free memory function of int 21h, finally, execute a far jump to int 21h vector. This will free the memory block, but none of your code is left to be executed. When the function ends, IRET will take it back to wherever your ISR was called from and you're done.

I don't have a lot of experience doing this, though, so anybody finding a bug in my idea, please do correct me.

axlucas,

Unfortunately, that may resume execution of interrupted code with corrupted registers.

Baldr: You're right! I forgot about that. But now I am thinking this: if the TSR is designed by somebody knowning that they are going to call this particular function, they could choose the registers carefully so that the same are used as for the DOS function. That way, there shouldn't be a problem!

axlucas
I think you are missing the fact that SeproMan talks about the case of hooking timer interrupt which complicates in DOS compatible systems such cases a lot. There was a good reason why DOS Idle interrupt has been added to the OS in the first place and why Indos flag has been available for so long in DOS (although MS did not document it at the begging).

Your TSR should have a command line switch like /unload
This lets you tell the resident part to unhook any INTs (if it can), free any extra memory and return a code.
If the code is OK then you can safely free the (inactive) resident part's memory.

If I understand the original question correctly this is more race condition issue here since instead of DOS Idle INT, timer interrupt is being used. To make long story short: using timer interrupt for calling DOS function and (re)allocating memory without appropriate precaution taken is always a bad idea.