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


On Fri, 1 Nov 1996 11:40:51  Peter Rottengatter <perot wrote: 
>
>
>On Thu, 31 Oct 1996, Ronald Andersson wrote:
>
>> 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
>> 
>Sure, but the debugger would ignore Pexecs and Pterms from other than the 
>program which is to be debugged.

Not necessarily, but I'm willing to drop this


>> 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.
>
>Only a general unpacking program that packs and unpacks everything that 
>goes to and comes from the harddisk would produce problems. And I know 
>plenty of other programs that would have problems too. Apart from this I 
>never heard of such a program for TOS ...

Actually the 'packing' plays no significant role relative to 'Pexec'.
Only the auto-unpacking of programs is relevant, so all versions of AFX are
involved, as are all other similar schemes.  Whether their implementations
actually would cause problems remains to be seen.


>See my last point. It is documented, as I learned recently, that 
>something loaded via Pexec may be removed via Mfree. Thus if something 
>would really link other Malloced blocks in a Pexec amendment then it must 
>link into Mfree too, to release those blocks too when the TPA is freed. 
>If it does so then there is no problem with my code.

That is a good point, since guarding both exits would ensure safety.
As for documented..., all I can say is:  Where ?


>> >    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.
>
>MiNT is quite old now, and since 'MiNT is Now TOS', everything that 
>collides with MiNT does officially not run under TOS, thus is to be 
>considered buggy.

Who said it wouldn't run under MiNT ?  It just wouldn't be able to provide
any special handling for the 'new' Pexec modes, and would leave them alone.


>It seems to be a different document, but I haven't got a copy yet.
>Never confirmed or implemented by Atari ? So tell me how XControl gets 
>rid of loaded *.CPX ? It certainly does not use Pterm ! And XControl is 
>by Atari ! If I ask a debugger to get rid of a program that is started 
>and halted, but not terminated yet, it cannot use Pterm either.

You must be joking!

CPX's are not real programs by Atari definitions.  They have no program header,
so they cannot be loaded by Pexec anyway.  They are loaded as data files...!


>XControl for instance. And since this is by Atari, and used widely, a 
>program that does not work with XControl won't go far in modern Atari 
>world.

Sure, but like I said above: Xcontrol does not use Pexec to load CPXs,
since they are not compatible with the program format this requires.


>> >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.
>
>Yes, as long as I keep contact with everyone who might start on a *.ISM 
>module (won't be many anyway, I suspect ;-) ).

Precisely, so whichever scheme is chosen we should be able to modify it if
needed later on.  Any modules produced by outsiders could be recognized from
lacking a newer version code in their header, and INETD could then adapt its
use of them as indicated by the interface version code, or simply refuse if
there are reasons to believe that such usage is unsafe.

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