🚀 go-pugleaf

This may not be a new revelation, but I figured I'd post it since I haven't
seen any mention of it yet.

While writing PLT:, I've found myself rebooting the computer every time
I make a change so that the new version will be loaded into memory.  This
can happen very often when I'm chasing down a bug by adding debug messages.
In his example ram disk handler, Matt Dillon's solution to flushing out the
handler was a program to allocate all the memory, hoping to cause exec to
flush it.  In a POSTTER file, he said that may not work after all and suggested
using multiple mountlist entries.

I figured there had to be a better way, dug out a program I had written to
print out the system device list, and modified it to do the job.

Basically, I search the device  list for an entry matching the name I give it.
It checks the dvi_Type field to make sure it's a device and not a logical
assign or volume, then it checks the dvi_Task field to make sure it's not
currently running.  Lastly it checks the dvi_SegList field to see if it's
really in memory.  If it passes those three checks, then the program calls
UnLoadSeg(), and sets e dvi_SegList to NULL.

The next time DOS tries to access the handler, it sees that it's not loaded,
and loads the new version.

The only problem is that it will only work for handlers that set the dvi_Task
field.  Handlers like the console handler supposedly don't do this, and the
program will think the code is not in use.  Unloading the handler code while
it's in use is not recommended.  I supppose there's probably a way to figure
out if the code is in use, but that's currently beyond my knowledge.

I imagine that this program can be taken a step further to make it an unmount
command by also deleting the DevInfo node from the device list.

Anyways, the program works just nifty with PLT:.

Rich Champeaux  (rachamp@mbunix.mitre.org)