[comp.sys.amiga] "RES:" - The end of the resident war?

nordmark@spirit.nada.kth.se (Arne Nordmark) (12/16/89)

REZ, Resident, ARes, Res...   well you could probably extend the list
even further.

Resident commands is a Good thing - they are memory efficient and are
'loaded' in notime. Shortly - you can't live without them.
But the problem is that there are almost as many different ways to make
commands resident as there are shells, and the number is increasing.

The reason for this is that there is no documented (*) and officially
supported way to do it, so everyone has to invent their own solution.

But after a bit of thinking I found out that there is a quite simple
way to put an end to the problem of which 'Resident' to use.

	|---------------|
	|		|
	|     RES: 	|
	|		|
	|---------------|

That's right, a dos-handler for resident commands!

Then you can say

	Path RES:

and you have resident commands no matter what shell you are using.

To find out which commands that are resident just say

	Dir RES:

And to remove a resident command, for instance Copy

	Delete RES:Copy

The main problem is how to make LoadSeg() actually 'load' the resident
program when it has got a lock on it.

One possibility is to fool LoadSeg() to think that it is loading the
whole program, but instead RES: gives is it a small 'stub' routine
disguised as a very short load file. The routine could look like

	jsr	ResidentProgram
	rts

And then you can safely UnLoadSeg() the small 'stub' program,
but the real resident command remains in memory.

There may of course be other solutions that are not so kludgy.

  -- Gunnar Nordmark

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

(*) The 1.3 Resident command is using the old resident list found in
the di_NetHand field of the DosInfo structure, and this is simply
a linked list of the undocumented structure

struct Resident {
	BPTR	res_Next;
	long	res_Count;
	BPTR	res_Seg;
	char	res_NamLen;
	char	res_Name[1];
};

As you can see there is no field for checksum or other security in the
structure, so this is a VERY BAD way to do it, and I hope that this will
be changed in 1.4.


	Gunnar Nordmark		nordmark@vaxkab.sunet.se