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


On Thu, 7 Nov 1996 12:30:39  Peter Rottengatter <perot wrote: 
>
>On Wed, 6 Nov 1996, Ronald Andersson wrote:
>>
>Andreas is not willing to give this agreement.

Too bad, another good idea down the drain then.


>He says that it probably would work with all versions of MagiC, and certainly
>not with MiNT. He does not intent to stick to this if one day it will be
>required to give up on this (undocumented) compatibiliy.

Ok, so we can't use it then.


>He does not like the suggested Ovlexec function either, because nothing 
>is going to prevent task switches inside the function, which would be 
>fatal. Super mode does not help either because if the function that is 
>supplied by the user needs to wait on I/O it is gonna preempted, Super 
>mode or not.

Quite wrong!  When implemented as part of the OS, the flag testing assures
that no task switching at all occurs while the Ovlexec is running, and to
keep this blocking period short any I/O waiting loops would be forbidden.

I sounds to me as if he has misunderstood the purpose of it, believing we
intended the entire overlay to run in this mode, which would never work.


>Andreas had an interesting idea on the port ownerships, which I'd like to 
>test first before making it public. On memory ownership there seem to be 
>two other possiblities on MagiC to alter it. There are kernel functions
>for Malloc and Mfree to which the desired process pointer is passed. 
>Andreas wasn't sure, whether he documented these functions yet.
>He would if we'd need them.

If a corresponding method can't be found for all systems, it is useless to us.


>There is no proper way to do it with MiNT, but we figured out that STiK cannot
>run with MiNT anyway.

That is ridiculous!
I have used STiK under MiNT many times.

In fact, when I read the above I saved the letter and did some new testing,
and now that I have done this I have to say it again: "That is nonsense!".
Both STiK and its clients work fine under MiNT.

Some of them may of course not be adapted for memory protection, but that
is of little moment, since that mode can easily be disabled by the user.

I tested Finger, CAB, and Antmail, all in actual traffic and sometimes even
without exiting the others.  That is what M-tasking is all about after all.
This was not only under MiNT, but also under nAES (to multitask AES too).

I did at one time mange to get an error, but when I tried to repeat it I
did not manage to do so.  But perhaps some MiNT/nAES adaption would be a
necessary thing for perfect operation.  God knows it took a lot of doing
before most clients could run at all under MagiC, so this is not strange.

I do not see any basis for stating that STiK is incompatible with MiNT.


>For original TOS the bending of the basepage pointer is a reliable way to do it,
>but it should be rebent ASAP and done in super mode.

Of course, and the same would also have applied if we had been allowed to do it
it in MagiC as well.  His talk of waiting I/O and long delays makes no sense.

Don't get me wrong now, I have every respect for Andreas Kromke, but he must
have misunderstood both this proposal as well as the nature of STiK itself.
Otherwise he could not have given the answers you relate.

PS: Just for fun (and out of curiousity) I also tried another XBOOT setup
    similar to the other test.  This also combined MiNT and nAES, but did
    not include STiK as a normal ACC.  Instead STIK.ACC was loaded into my
    ACC-loader (with 8-9 other ACCs I like) which (as you know) makes
    heavy use of the 'ownership' trick which 'should not' work under MiNT.
    
    Well, it did work anyway, so someone forgot to tell MiNT it shouldn't.
    I only tried a few 'Fingers', but that shouldnt matter because either
    the channels work or they don't, and these certainly did.
    
    I'm going to send this letter that way too, so when you read this it
    proves that Antmail also works with this setup. (I'm sure it will.)
DS.

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