To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: Problem                                                           


On Thu, 31 Oct 1996 10:46:37 Peter Rottengatter <perot wrote: 
>
>On Wed, 30 Oct 1996, Ronald Andersson wrote:

----- snip ----- re: pro & con simplified module termination

>> Yes, I know that this is how Atari's TOS do it, but I am still uncertain about
>> whether it will work with all GEMDOS add-ons.  Any such add-on which adds some
>> allocated RAM block for a Pexec'ed file, expecting to release it at termination,
>> will cause incurable RAM fragmentation if standard termination is skipped.
>> 
>> Some examples of add-ons that possibly do this are auto-unpackers (like AFX/PFX)
>> and low level debuggers etc.
>
>Three reasons I think there is no danger connected with this :
>
>* The *.ISM modules are not gonna be executed by debuggers (it would 
>   be very difficult to do this), and I cannot see how autop-unpackers 
>   could be of any use for *.ISMs. Sure, there might be other add-ons, 
>   but *.ISMs aren't normal programs or applications anyway, as they 
>   do not need to shrink their memory, do not have their own stack, do 
>   not execute the normal way. So any add-on that someone might attempt 
>   to use with *.ISM will probably fail anyway.

I meant that debuggers might be used to debug clients or other programs in a
system with STiK (and thus INETD) installed.  Such debuggers can use a Pexec
link to keep track of program interactions in allocated RAM blocks, with
similar Pterm0, Pterm, and Ptermres links to release blocks again, which
would not happen for your modules.

Likewise, I did not mean that anyone would intentionally apply auto-unpacking
to the modules, but that an auto-unpacking system might use similar links to
those described above, for other reasons but with similar results.

Generally speaking, these links would never intentionally be applied to modules,
but when modules are loaded by Pexec the linked routines may need some Pterm*.


>* If I were to write such an add-on I'd be aware that there are Pexec 
>   modi that are difficult, up to impossible, to handle the way you 
>   described. So I certainly would restrict application of my add-on 
>   to Pexec (0, ...);

Why ?
All documented modes should be relied upon to function as documented.
(Or amended by code patches to enforce the documented behaviour.)


>    What about the multithreading Pexec() of MagiC 5.0, 
>   if the add-on released the mentioned RAM block it would do so for 
>   the whole process, so the add-on would not even work on MagiC 5.0.
>   The same probably holds for the pseudo multithreading of MiNT.

Such innovations will of course be unsupported in older tools, since no
documentation could exist before the mode was invented.
But we were talking of standard modes existing in all gemdos versions.


>* Since there exists this mentioned document, and also lots of programs 
>   that make use of it, an add-on like you described would be a violation 
>   of the principles of proper programming.

I think you're exaggerating a bit, in two ways:

The only 'document' on this that I've seen was an unofficial description of
a method used by one Atari employee to create a reentrant overlay system.
The method in question was AFAIK never confirmed or implemented by Atari,
so this does not constitute an official programming recommendation.
If you have other documentation I'd be very interested in having a copy.

Also, I am not aware of 'lots' of programs that release the RAM of other
Pexec-loaded programs/overlays without calling any Pterm* function.
I suppose some of the module-based graphics programs may be involved, but
please clarify which actually load modules with Pexec but unload without
using any Pterm*.

>Anyway I will consider your proposal, but I doubt that I find it 
>significant to change the unloading to a Pexec (4, ...) call.

Ok, that's up to you, and if you decide to change this later it is quite easy
to do.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
