To: perot@pallas.amp.uni-hannover.de
Subject: Re: [5] New STiK, more info and binaries                                        


On Wed, 1 Jan 1997 17:58:22  Peter Rottengatter <perot wrote: 
>
>On Wed, 1 Jan 1997, Ronald Andersson wrote:

----- snip ----- re: RFC 768
>
>I appended it here at the end of the message after the signature. I got 
>it on my Unix workstation, and I'm just too lazy to copy it to the Atari 
>only so that I can compress and uuencode it in a way you can deal with. ;-)

Thanks.  I've saved it with the rest of my RFC collection now.


----- snip ----- re: avoiding GEMDOS

>> >True, this is a serious drawback. However, but linking dummy routines 
>> >that pretent operation, into the slots while the STiK port is switched 
>> >active, I can prevent mixed up operation. If the STiK port is active, the 
>> >other app simply does not work, but shouldn't crash either if programmed 
>> >correctly. After the STiK port is switched inactive, the application 
>> >should work as usual.
>> 
>> I'm not quite sure of what you mean here, but the effect you describe does
>> sound acceptable anyway.
>
>Well, the BIOS uses the vectors too to call the routines for the serial 
>port. The 'activate_port' call in SERIAL.STX copies the vectors for the 
>specific port to some internal structure, and puts vectors to dummy 
>routines, that are inside SERIAL.STX too, in place, to be called by BIOS 
>if any application tries to access the port. So if an application calls 
>Bcostat, the corresponding dummy is called, and that reacts by making the 
>application believe that no data can be send (returning zero, which means 
>no byte can be send). Corresponding dummies exist for the other vectors.
>The Bconstat will always state that no data has been received, the Bconin 
>will return a zero (meaningless), and Bconout returns without having done 
>anything.

This sounds a bit overcomplex.  Are you sure this sort of blocking is needed.
Normally device access on BIOS level is not afaik blocked in this ways, so
that BIOS can circumvent such blocks on the GEMDOS level.


>On desactivation of the port (via CPX for instance) the old vectors are 
>restored, so that other applications can be used as usually.

That should be ok, and is of course needed for full compatibility, so that
ports unused by STiK retain the original/HSMODEM characteristics and speed.
Even so, I would feel better about a blocking on the GEMDOS level only.


----- snip ----- re: legality of mixed GEMDOS/BIOS use for port operation

>> >Yes, that's right, it's only that I want avoid the Fopen. If Harun does 
>> >not tell how to do it on a lower level, I need to do a Fopen with a 
>> >following Fclose, and trust that the handshake switch stays the way the 
>> >Fopen selected. Since this is not documented, I do not feel well about it.
>> 
>> Why Fclose directly...?
>> I'd rather have something like the following:
>> 
>> Fopen the port using GEMDOS
>> Dial up and connect using BIOS I/O
>> Serve the clients using BIOS I/O
>> Disconnect using BIOS I/O
>> Fclose the port using GEMDOS
>> 
>> I don't see what could be wrong with this.
>> The only potential problem is the ownership of the GEMDOS channel, but when
>
>This is precisely the problem. If you got a modem on SERIAL2, then you'll 
>want to use the Dialer to establish the connection. The Dialer will calls 
>STiK's on_port(), this will call the activate() inside the SERIAL.STX, 
>this in turn will do the Fopen. Thus the channel is owned by the Dialer 
>again, and closed as soon as the Dialer terminates. So if it is closed 
>anyway, I can do it myself in a more controlled way. This won't harm 
>STiK's IP traffic I guess, as it is done via the vectors, which should 
>not be aware of ownership. 

I see your point, but then we also need to patch the GEMDOS vector so that the
GEMDOS functions do not see the port as free for use.  This vector bending, as
well as that of the BIOS, does not really contribute any new capabilities for
communication but does increase the overhead of _all_ GEMDOS/BIOS calls.

That might be ok if we gained more from it, but not just to replace functions
already inherent in GEMDOS.  Instead we should find a workable method to use
those existing functions (ie: Fopen and Fclose).


>> the clients only use BIOS this should only matter when time comes to disconnect.
>> We already know one method to solve this that works fine with all existing TOS
>> versions, as well as under MagiC.  I think we should use it to let the TSR own
>
>I'm not sure what you're talking about. Gimme a hint, which method ?

As you guessed (further down) I mean the 'p_run' basepage vector.  AFAIK there
is no other way for any TOS-type (or \AUTO\) program to own anything, either
RAM blocks or file/port channels.  Andreas may have speculated about removing
it but, according to what he told you before, he hasn't done so in any MagiC.
It is my personal belief that he never will, for compatibility reasons.


>> the channels and handle both Fopen and Fclose for the dialer and any other
>> connection establishing programs used for local Intranets.
>> (Or will that be handled by the dialer too...?)
>
>For local nets you only open the CPX and click the connection active.  If 
>you store the settings then, the connection will be available immediately 
>after bootup.

Ok, but that only means that the CPX will then have to go through an opening
sequence without manual prompts.  All operations (whatever) can be the same.
In this case, the CPX-server will normally be resident so ownership should
not be any problem then.  Even so, the method I suggest would also allow such
a configuration to use a non-resident CPX-server (eg: Xcontrol.APP).


>> In case Andreas Kromke has negative opinions on this (like he had before),
>> please ask him these questions:
>> 
>> Precisely how is the ownership of a GEMDOS channel determined ?
>
>It is owned by the process that does the Fopen.

Yes, but how is this process identified...?
I believe it always has been (and always will be) identified by the content
of the 'p_run' basepage vector.  It cannot be done by anything AES-related,
since that would forbid TOS-type programs to use files at all.


>> Is it illegal for a TSR to open a GEMDOS file (or hardware channel) ?
>
>The question is none really, because either the TSR is still running, 
>then of course it may own files and memory (means AUTO execution is not 
>finished yet), or it has terminated, then it is no process anymore, but 
>cannot call Fopen anymore either because it is not running. If another 
>process calls a piece of code from the TSR then of course it is the other 
>process again which owns the channel.

True, but why ?
I believe it is because that process will then have its basepage address in
'p_run'.  Thus it should still be possible to force the ownership to the TSR
by temporarily patching 'p_run', only to execute the Fopen.  Then, when time
comes to close the channel (if ever) the same thing is done for Fclose.


>> If not, how is this to be done legally (for _ALL_ TOS and MagiC versions) ?
>
>I asked him this question before, when the problem arose with the Dialer 
>and the older STiK versions. He hasn't got an answer, he admits this is a 
>problem. He gave me the hint of Fforcing the channel to a standard 
>channel, he said this would most probably prevent closing on termination. 
>But this can be done just once or twice, because the number of standard 
>channels is limited, and other processes might want to use them.

Yes, of course, so that method is not satisfactory.


>> If he has no satisfactory answers to the above questions, then I suggest that
>> we use the method we have discussed previously anyway, since it does work with
>> _ALL_ existing implementations (including MagiC 5).  I strongly believe that
>> any attempt by him to remove this compatibility will be disastrous anyway.
>
>Again, I can't follow. Do you mean bending the p_run pointer ?

Yes, and for very specific reasons I believe that this will remain valid.
If Andreas ever does abolish the documented use of 'p_run', he will have
to implement something nearly identical in his kernel.  To do this would
constitute nothing less than compatibility sabotage, for no real purpose.
I therefore do not think that this will ever happen.

If it does happen he would have to document a replacement method, based on
his new kernel functions, so it should still not be a problem.  We would
just have to add an alternative method.

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