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


On Sat, 4 Jan 1997 14:02:30  Peter Rottengatter <perot wrote: 
>
>On Fri, 3 Jan 1997, Ronald Andersson wrote:

----- snip ----- re: patching BIOS to reserve port devices without GEMDOS

>> 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.
>
>It not blocking. It's simply the only way on Bios level I know of I can 
>tell an application to do no data traffic because the port is in use by 
>STiK. To the application it appears like the line is blocked, but it 
>should be able to deal with that.
>
>And what do you mean by overcomplex ? It's not at all complex in terms of 
>programming ...

Part of the complexity I meant was that all STiK parts that need BIOS calls
for port I/O will have to do this by simulating trap calls through the XBRA
links of your patch routines.  They cannot use normal trap calls for this,
because then the patch code needs to identify whether a caller is STiK or not,
which probably leads to even worse time loss.

But mainly I meant that any extra code is overcomplex in this regard, since
reserving devices like this should not be done on the BIOS level.  On BIOS
level it should always be possible to access all devices.


>> Even so, I would feel better about a blocking on the GEMDOS level only.
>
>I'd need to hang into the GEMDOS trap in order to catch Fopen and return 
>ACCDN if the filename is U:\DEV\MODEM1 or whichever. First so far I managed 
>without any trap vector bending, and I'd like to proceed this way. But 
>the stronger argument, second, is that the user may have created alias' 
>for the port name, which I cannot know and thus cannot catch.

I did not intend that the GEMDOS trap should be patched at all to achieve the
blocking.  I simply want the Fopen to be used within some code that ensures
that the owner of the channel will be the TSR.  This way neither GEMDOS nor
BIOS will need to be patched.  If Andreas can tell us a method he prefers us
to use with MagiC then we add that alternative, but otherwise I favor using
the 'p_run' basepage patch method as a general solution to this problem.


>> ----- snip ----- re: legality of mixed GEMDOS/BIOS use for port operation
>> 
----- snip ----- re: 'Fopen...Fclose...work' vs 'Fopen...work...Fclose'
>> >> 
>> >> 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.
>
>Oops, that's the same argument I used above ;-)

This is not surprising.  We do have the same goals after all.  It's just that
we still have slightly different viewpoints on how best to achieve them.


>> >> 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).
>
>Same with my method. The only difference is that with my method the port 
>appears blocked, instead of getting ACCDN from the Fopen. I agree, it 
>would be nice to have the latter, but IMHO it can't be implemented reliably.

I agree that a GEMDOS patch should not be used for this purpose, but I believe
that a reliable method can be implemented using the 'p_run' patch trick.


----- snip ----- re: 'p_run' determining channel ownership (even in MagiC 5)
>> 
>> 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.
>
>I believe this too. But I do not feel well doing this. You might be right 
>that p_run will forever be kept by Andreas, but there is MiNT too for 
>instance. Does it work with MiNT ?

I believe so, and I'm sure that some way can be found to do it anyway if not.
The GEMDOS code of MiNT is XBRA linked to the original GEMDOS of single-TOS,
so it is easy to access that 'deeper' level if MiNT routines make trouble.
Let's experiment a bit with this, before we decide anything.

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