Received: from athserv.otenet.gr (athserv.otenet.gr [195.170.0.1])
	by maskin.oden.se (8.8.7/8.8.7) with ESMTP id TAA23664
	for <dlanor@oden.se>; Sun, 8 Mar 1998 19:33:51 +0100 (MET)
Received: from otenet.gr (athe-g14.otenet.gr [195.167.120.125])
	by athserv.otenet.gr (8.8.8/8.8.8) with SMTP id UAA22352
	for <dlanor@oden.se (Ronald Andersson)>; Sun, 8 Mar 1998 20:36:50 +0200 (EET)
Date: Sun, 8 Mar 1998 20:36:50 +0200 (EET)
Message-Id: <199803081836.UAA22352@athserv.otenet.gr>
To: dlanor@oden.se (Ronald Andersson)
From: papval@otenet.gr (Vassilis Papathanassiou)
Organization: Private
Subject: Re: Masque.Stx beta mailshot t
X-Mailer: NEWSie Version 0.86 (Atari)
X-Sender: POPwatch v2.51 (Atari)
X-UIDL: 69e12e86804499eb19a3457821bef1c9

Hi Ronald

  Since many misunderstandings have gone after our last loooong mails, i'll
try to make this shorter. It's always a pleasure for me to read your mails
(either on general subjects or technical), so this is not a problem for me to
answer by paragraph, but this time we have a lot of MiNT/MintNet stuff, which
can be answered simply by: "Let MiNT to MiNT fans, let single TOS / MagiC to
us ! ". I hope you agree with this.

>----- snip ----- re: the need of a good mailer (re: Infitra)
>>
>>Reminds me something about FTP clients...
>
>Yep, definitely.  MG-FTP, aFTP and NEWSie are all slow, quirky, and mostly
>unsupported (even NEWSie has not been improved for ages in its FTP functions).
>
Right, and when my XFS for BNET finishes, i'm thinking of making a FTP client
folder into it also. It'll save a lot of GEM programing making something like
aFTP (drag&drop etc). Just let the desktop do that.

----- snip ----- re: Serial ports speed

>>I had good connections to the PC even in the old days with the SERIOUS
>>serial problems.
>
>That sounds very odd.  I have never been able to use high speed connections
>reliably without HS-MODEM installed, and that goes for all of ST, Falcon,
>and TT.
>
I didn't said without HS_MODEM. I meant the STinG days with serial problems.
Back then i could hardly move 2 datagrams between TT and Falcon, but had good
connections with the PC. Peter is using his Linux/Pentium for tests, so it
might be the case (taking so long to convinced by me and others, that
serial ports had so many problems).

>>And why CoNnect or MintNet are working much faster in my setup ?
>
>I don't quite see the point...?  CoNnect is a terminal program, so whatever
>port it uses must be unused by either MintNet or STinG, so if CoNnect is
>faster in a MintNet system or in a STinG system can only be due to other
>factors than how either TCP/IP stack uses the serial ports.
>
I mean CoNnect alone, no STinG loaded, transfers happily at 153600, no
problem. The same for MintNet, 115200 TT to Falcon, no problem.

>>In any case i'd appreciated if you could send me his STinG/HS-Modem settings.
>>(One thing i know, i know nothing. - Socrates)
>
>I'll check with him and get back to you with that info later.
>
Ok, thanks.

>----- snip ----- re: TCP_close problems

I talked to Peter about this (again) he said yes, it's a headache for him too,
it'll go to the list again for discussion. I wish us better luck this time...

>>>  The client is no longer using that
>>>connection, so there is no way it can be informed anyway.
>>>
>>Sure, if it has closed it permanently...
>
>Is there any other way to do it ?
>AFAIK there is no 'temporary' form of TCP_close, so if traffic is to
>continue after closing a connection, another connection has to be opened.
>Perhaps you meant 'immediately' rather than 'permanently'...?
>(By which I mean calling TCP_close with zero timeout.)
>
My fault, yes, i mean immediately.

----- snip ----- re: TCP_ack_wait

>I consider that a separate bug.
>It violates Peters TCP manager specs from the STING.HYP part on TCP_ack_wait
>
>----- STING.HYP quote start -----
>Returns E_NORMAL, or E_BADHANDLE, E_CNTIMEOUT, E_UNREACHABLE, E_REFUSE,
>E_CONNECTFAIL or E_RRESET.
>----- STING.HYP quote end -----
>
>As you can see the possible return values include E_CNTIMEOUT which must be
>the only sensible return value for a timeout.  Unfortunately that may lead
>to incompatibility if any clients rely on E_NORMAL for such cases...
>
First look at that:
----- STiKSPEC.TXT -----
int16   cdecl TCP_ack_wait(int16 cn, int16 timeout);
  .......
  - Returns E_NORMAL regardless of whether the timeout is reached
    or the output buffer clears.
  - This is a kludge that you should probably never use...
-----  STiKSPEC.TXT quote end -----

Further tests proved that STinG actually returns E_CNTIMEOUT, but now things
are worst ! I mean the client could still wait for more data, either E_NORMAL
or E_CNTIMEOUT !

-----> 26 Feb 98

You can forget the 'now' from the above, since the new TCP.STX has changed
things drasticaly. I still can't say 'corrected', it's rather early for that,
but seems i can't reproduce the +1 byte bug anymore. So i'm saving the rest
of this subject for later...

Seems to me that TCP_ack_wait and (new) TCP_close can save us some trouble,
until the RFC compliant TCP_close. But what about STiK compatibility ? I have
reports that FTP Server works fine with it. Making corrections to my code i'm
afraid i'll leave STiK out. (and this f***ing TCP_close is very sensitive
from the server side ).

----- snip -----> re: TCP close fix

Can't see anything wrong with your proposal. As i see now (5 Mar 98) Peter is
ready to do it properly anyway (discussion with Dan).


>>----- snip ----- re: Path handling
>>>
>>>BTW:  BNET_TCP in the form I received it also messed with path access in
>>>      a way very similar to how MetaDos does it.  This actually made it
>>>      impossible to use either MetaDos or ExtenDos properly.
>>>      That may have contributed to your bad opinion of MetaDos...
>>>
>>I don't know what you mean here. I know that path handling is not one of the
>>strongest points of BNET_TCP.
>
>BNET_TCP interferes with path operations mainly in three ways.
>
>1: It patches paths to uppercase in the original strings 'owned' by the
>   callers of GEMDOS functions, and modifies them even if the path used
>   is not for the 'BNET drive'.
>
>2: It intercepts Dsetpath such that lower-level filesystems are not always
>   supplied with the information they need to function correctly.
>
>3: It intercepts Dgetdrv/Dgetpath such that information from lower-level
>   filesystems can be 'lost'.
>
Absolutely right ! That's the case, even though i didn't check the code. It
just strengthens my bilief for sharing code. A 'second' eye can see something
i didn't, even after 1000 (!) passes from the code. But it's not the same
with the BNET.XFS (he he !).

----- snip -----> re: XFS load and MetaDos

True, MagiC loads the XFS's first (making my early tests to result in a
system without drives !!) but inits it later. I think it will be clear when i
send you BNET.XFS sources.

>>The point is that BNET_TCP works for me, either with EASE/MagiC or
>>Thing/Freedom 1.15/MagiC,
>
>I assume the latter means that you used Freedom to access the BNET drive.
>
Yep, Freedom 1.15 to desktop window or two open Freedoms and copying between
them. Both work fine (but this is not my aproach to BNET ! ). But, when i'm
talking about bugs, BOTH ffsel.prg and Freedom are NOT loaded. You and Peter
say that Freedom has bugs, so i take it for granted !


>>while MetaDos doesn't (well, it worked if
>>i didn't do anything else, leaving it running alone, but 'hanged' the
>>machine if i was trying to use another program doing disk access).
>
>Which machine...?  TT or Falcon ?

Falcon. Just listening music while working.

>Which BOS and DOS files did you use ?
>
Sorry, can't tell now (ie after installing SPIN). I suppose the MetaDos 2.7
files (?)

>>----- snip ----- re: BNET.XFS
>>
>>>Sure, but you then have a MagiC-only XFS.
>>
>>Yep, that was my goal. To avoid using EASE when multitasking. Thing works
>>fine in Single TOS, even in the present form of BNET_TCP. That leaves out
>>MiNT and Geneva. For the first, the XFS is an easy port
>
>I have my doubts as to the 'ease' in porting XFSs. (pardon the pun ;-)
>If it's that easy, then why aren't there more MagiC XFSs ported from MiNT?
>(eg: MINIX.XFS)  (BTW: I am actually considering an eventual MINIX.DOS)
>
I don't know. Maybe because at a first glance they seem completely different !
Maybe we're less left developing ATARI software than we think :-)
But after i studied the MiNT 1.14 sources, i found out they're not. (ok this
is a statement that 'takes' a lot of discussion !) Andreas is right when he
says that MiNT kernel makes 'double' calls for XFS functions. As far as i can
tell 'til now, one can call most OS functions from a MagiC XFS directly. In
MiNT, he has to call'em from the Kernel (but they're direct equivalents, you
don't have to 'implement' them). But that doesn't mean the port is not easy.
(ok, it depends on what one considers 'easy' !! )

>The nice thing about MetaDos drivers is that they should work independently
>of both MagiC and MiNT, without requiring any further conversions.
>
Hmm, that's true.

>
>>(although i'm not interesting) and it also has NFS,
>
>No, MiNT itself has no such thing.  That demands a fairly complex MintNet
>setup, which is an entirely different cup of tea...
>
Sure, but, it seems to work ! (local tests only).

>>which is more 'standard' when it comes to comunicate with other platforms
>>(and acording to Peter, NFS is an Internet standard).
>
>So it is, though I doubt this will ever really matter in the sense that any
>major NFS servers would allow any of us to mount their systems on ours...
>(Not bloody likely, is what I think...  ;-)
>
I'm afraid it is...

>>>----- snip ----- re: BNET.XFS - BNET.DOS -> BNET.APP
>>>That could be a good idea, but this depends on to what extent the BNET.APP
>>>interacts directly with the XFS/DOS and on whether it is dependent on any
>>>MagiC-specific stuff.
>>>
>>Well, at least for my XFS, the part that 'listens' to commands from the
>>evnt_timer loop, stays 'as is', and the 'local' part (ie assembly trap
>>handler, stack tricks and the C L_xxxx functions, are now almost all part of
>>the XFS code.
>
>Then it might be best to use that as a basis for conversion to a BNET.DOS.
>Unfortunately, though I've now learned the filesystem concept of MetaDos,
>I have not found any good example source for MagiC XFS filesystems.
>Do you know where any clear and instructive sources can be found ?
>
I'm afraid not. I did a LOT of searching for infos, nothing. Only the
MAGCDOCU. This is entirely in German. If you can read GER docs, i think it's
a good point to start (ie the only !!) If not, i can send you my Ruftrade
translations with my few corrections etc (and of course the BNET.XFS sources)

>>----- snip ----- re: MintNet installation

1: Never liked it so much to download KGMD.
2: You're right, i think you can't use scriptless PAP-login (but haven't
tested, since my ISP needs one).
3: At the first days of STinG, i had problems even to setup ROUTE.TAB. The
docs were very poor also.
4: The MintNet installation i have, works for me, what else do i need ?
(no need to answer). But it should be clear now that i installed it: 1st for
the PPP and 2nd (lately) for tests, doing the port. I have no other interest
for it, so sorry again for making this answer so short.

>>>Many MintNet applications may fail anyway, because they depend on MiNT flavor
>>>of GEMDOS functions and signals etc.  You'll have to patch that too then...,
>>>and full MagiC/MiNT compatibility in this may not even be possible (?).
>>>
>>Maybe all, but i'm talking about easy ports here, not binary compatibility.
>>And i'm sure you know that there is EVERYTHING available for BSD sockets
>>outthere. (example: NFS, which Peter likes so much ! )
>
>Lots of stuff is available yes, but 'easy porting' requires a UNIX-clone
>setup leading to the 'horrible mess' situation I referred to earlier.
>
I'm sure you've noticed by now that people that can write a good GEM program,
can have trouble with the 'connection' part. That is what i mean 'easy port'
ie direct sockets equivalents. Take a look at the source of CAB.OVL for
MintNet (Howard Chu) and you'll understand what i mean (ie apart from
NETWORK.C, which is the 'sockets' part, in all other files you can't tell if
you're using a file handle or a network handle).

----- snip ----- re: MagiC kernel vs MiNT kernel

>But the main negative factor of all multitasking AES systems based on MiNT
>is that they are considerably slower than standard TOS, whereas MagiC is
>actually faster than standard TOS.  On a standard ST, and to some extent
>even on a Falcon, this speed difference is so significant that it makes
>the difference between 'barely useful' and 'very good'.
>
That also makes me a MagiC fan. The fact that my old STe is a usable machine
again. If i had to tell users 'go out and buy a TT to be able to use the new
software' i wouldn't. But i find it easer to 'push' someone to buy MagiC,
since his old machine is upgrated a lot (and no need for new EPROMs etc)
ie he/she can still play the old (and good) games !

>>----- snip ----- re: MintNet -> MagiC: Can it be done ?

>The possibility has been discussed in the mailing list, but not in terms of
>anyone being ready to start coding.  That will require a dual familiarity
>with both STinG and MintNet which I believe none really possess at present.
>You may be the one best prepared as yet for it, having experience of coding
>for both, but such a project will also require intimacy with internal kernel
>coding of both as well.
>
True, but i have read so many mails the last two days, and have done no work!

>----- snip ----- re: Where STiK / STinG came from ?

> The STiK interface
>is definitely not something that would arise from any direct porting...
>
Yep, and it's the best, no doubt about it (if you mean the STinG interface).

>
>>This happens to use BSD sockets. It's the same with MintNet. The
>>only difference is that KA9Q had to 'invent' a multitasker for the PC, while
>>Kay Roemer had MiNT. Therefore he just did the XDD and drivers (ok, and the
>>utilities). But since even STiK/STinG were born from the above, what makes
>>you so negative about it?
>
>I'm not really.  In fact I do not know enough about any BSD socket interface
>to criticize its usefulness, because I have never programmed for any such.
>
Hmm, it's not so simple as STinG, but logicaly laid out, so it's easy to get
used to it, i think.

>I misunderstood your intention to be not only to implement such an interface,
>but also to use it as, and in such a 'cloned' environment as, the MintNet
>fanatics use MintNet.
>
Me ? NO WAY ! Even though i was a 'Unix System Specialist' acording to
Nixdorf, i gladly left Unix back then. And i admit, i don't remember now so
much of it, so i can happily work with MiNT, but not love it !

>That is why I seemed at once both a bit puzzled and disappointed in my last
>mail, because I could not understand why you would want to do so.
>
Ok, now you know. I'm doing this to have a decent Ethernet connection for my
machines, to see how a XDD stack is compared to STinG (pushing STinG to that
direction, if i'm right) and having a MagiC PC stack.

----- snip ----- re: Sockets Apps

>>  Note also that STinG's way of giving us only a connection handle, and not
>>the rest of 'normal' I/O, is the bigest problem when porting software.
>
>I'm not quite sure of what you mean by 'normal' here, possibly because I
>am not really familiar with socket interfaces.  It stands to reason however
>that in any translation from any set of methods to another, one tends to
>regard the methods of the source as 'normal' and any similarity to those
>methods in the destination will simplify the translation process.  That
>does not necessarily mean that this view of what is 'normal' has any real
>validity however, since both sets of methods rest on arbitrary decisions.
>
Saying 'normal' i mean what we have in STDIO.H (with the exception of fopen
which is called socket() probably to remind the programmer that he's dealing
with one ! ) Clear now ? It helps a lot to be able to use fprintf, fgetc,
fputc, vfprintf (for va lists) etc, etc.

>>Why shouldn't STinG get this capability, is something i don't understand.
>
>Because as described it would only be for one of the many Atari system
>environments, whereas STinG is intended to work in all of them.  That
>is my only serious argument against it.  If that single premise could
>be changed then my opinion would turn in favor of it.
>
Maybe it can ! KA9Q has a complete STDIO.LIB which replaces the one used for
TURBO C++ 3.0 he was using for the PC. The main difference from the standard
is in the FILE structure, where he has added the socket support (and saying
socket here i mean the 'ip_addr:port' socket, not BSD sockets ! )

  I've tried to support this in FTP Server, but i have no access to the TCP
buffers, so it's only partly supported (ie connection handle in place of file
handle). Still, i can use fdopen, the macro 'fileno (ftp->control)', a modified
version of fprintf etc.

  I think it can solve single TOS problems, and leave MagiC with the XFS
(which also supports Dcntl, _ioctl, critical code execution etc).

I can continue for ever with pros and cons of XFS's etc, but now i need hard
evidence to continue, ie completed working code, so i can back up what i'm
saying. We also have your BetaDos now, which might solve all our problems.

>>----- snip ----- re: glue STinG
>>
>>it's more than easy to implement the STinG API (at least for the clients,
>>which are our major concern anyway)
>
>But if we only consider client stuff, then updating GlueSTiK to GlueSTinG
>should be no problem at all, and yet I do not feel that this is enough.
>If that were the only goal, then we might as well skip it and settle for
>the compatibility given by STinG's compatibility to STiK.
>
And this is one problem too. STinG is too much compatible with STiK ! This
means Peter hasn't corrected things he could, just proposes corrections that
haven't done yet. (i have nothing against Dan, it's just that STiK was always
a useless stack for me, ie no local networking and no PPP ).

>----- snip ----- re: ethernet skeleton code
>>
>>Again: I asked for skeleton code, not full implementation.
>
>Actually I do not believe that any meaningful skeleton even exists for this.
>The Ether.Stx of the distribution is just a do-nothing placeholder identical
>to some of the others (Midi.Stx, Centr.Stx) except for the name strings...
>
He could say that...

>>Peter said that i don't have some other info to do it, and when he finishes
>>the STX, he would send me the code.
>
>But when I have discussed it with him he has only been _planning_ for the
>coding, with nothing actually coded as yet, at least that was my impression.
>
He has now (6 Mar 98) for Rielb adapters.

>>I have the code for my hardware, but it's code for the old
>>BNET, so i only needed a way to put it in STinG.
>
>Oh.  Does that mean you do not really need any ethernet specific stuff at
>all, but only want to see how you can define your driver structs and link
>these into the STinG structs...?
>
Exactly !

----- snip ----- re: Masque is a port driver

Great !!!

>The only problem (?) is that Masque is a 100% assembler module, so if you
>want to use C you will have to translate structure initializations etc
>The actual structure definitions are available in normal .H files, since
>these are what Peter normally uses himself.
>
You call it a problem ? My driver software is also in assembly (although i
was stupid enough to try to port it to C, which took me some time, but i
didn't have the info to 'patch' it to STinG, so i left it).

>I can also give you assembly .S and .SH lib files if you think these would
>be of help to you.  These files together form an extended and more debugged
>version of my STNGPASM dev-kit as found on Peters pages, and is what I
>myself use for STinG programming. Together with the actual Masque.S source
>this should give you all you need to see how a STinG port driver can be
>created.
>
Ok, you're a life saver !

>Cen_PLIP is also a port driver module you can study to see how these are
>built, though its very odd (really) interrupt structure is not something
>I would recommend that you take after.  It does contain many useful things
>missing from Masque though, such as routines for converting raw sequential
>datagram RAM blocks to the format used in STinG's internal queues etc.
>Such stuff is needed by all physical port drivers (which Masque is not).
>Cen_PLIP is also programmed in 100% assembler.  It has to be so in order
>to get anywhere near what I consider decent speeds for a parallel port.
>
Hmm, great. So, using it we could also use the cartridge -> centronics
interface to direct-connect two ATARIs, which could be faster and safer and
leave the printer port free. (just a thought !)

>>Peter talked for LANCE
>>adapters, an old project at TUW university (i have that source also), but not
>>the info for STinG. On the other hand, MintNet has source for MANY ethernet
>>adapters, including LANCE, so...
>
>Ok, so I take it that the Ethernet-specific code is not a problem for you
>then, but that linking to STinG is, right ?
>
Right.

>If you think the files described further above would help, just say so
>and I'll send them to you ASAP.
>
I'm saying so, and also saying thanks a lot !!

>>>Most importantly:  There is _NO_ hardware or interfacing standard for how
>>>to implement EtherNet on Atari's.  This will have to be invented 'on the run'
>>>as it were, which will cause problems in adapting to various hardware.
>>>
>>I know that, PC's haven't either. Ethernet drivers come with the cards.
>
>So I've heard, with fixed addresses locked in ROMs even (which I find absurd).
>
Hmm, in fact it's the Ethernet address (48 bit) that is in the ROM, to avoid
even two cards to have the same address.

>>But then again, they are not interesting if you run TCP/IP or NETBUI or
>>whatever on top of them. So this is not really a problem.
>
>Good, since PC emulation to run hardware drivers is not a good idea ;-)
>
Tell me about it ! Even though i had docs from the manufacturer, i had to do
some PC dissasembly to figure out some things (i'm trying to forget those
nights ! )

----- snip ----- re: Plag & play !

>I do know, though fortunately I am not myself a windows 'sufferer'.
>(That word fits reality better than 'user' don't you think ?)
>
Sure, for Bill those two words have the same meaning !

>>Don't forget the cartridge port of all ATARI's. With 3 chips
>
>GALs or standard TTL ?
>
Standard and cheap ! 1 74LS244 (it's also under our keyboard !), 2 X 74LS374.
If i get problems with my back one day, i know what chips to blame !
(checking their output with a test program and a multimeter all day over my
 TT).

>>it can be
>>converted to a FULL signal parallel port, and thus take ANY pocket Ethernet
>>adapter designed for the PC's parallel ports. (i have build such interfaces)
>
>Interesting.  Do you have a circuit diagram as file (IMG or whatever) ?
>
Yes, BUT i've patched it again, so the img is not correct (again). I can
correct and send it. There is also the PCB file in HP format (from Scooter
PCB ) done by a friend of mine, which is now also wrong (after the patch).
This sounds crazy, but the 'patch' is simple. This came from the fact that i
have one adapter 8bits_out 4bits_in (old PC standard) and one 8bit in/out.
I'll send them to you, as soon as i correct them (it's almost a forgoten
project, but something tells me it's coming back to life ! )

>>----- snip ----- re: Dialer
>>
>>>That must be a modem-specific limitation.  I always use 57600 for DTE<->DCE
>>>connecting with 28800 bps for DCE<->ISP.  If the modem allowed higher local
>>>speed I am sure the Dialer could use it, although that is really up to the
>>>SERIAL.CPX to setup.  You should not blame STinG for the limitations of
>>>your modem, or the available speeds on TT ports (those can be changed BTW).
>>>
>>Then why CoNnect and PPPD work OK at 115200 ? It's the same modem, same TT
>
>Wow, that's a _damn_ fast modem, none I've had would take that speed.
>
It's a SupraExpress 336 V+, not expensive compared to others, and no Class 2
FAX protocol.

>>same cable. Do you really think i'd blame STinG for something like that,
>>without checking ?
>
>No, not really, but when both my Falcon and TTs of others perform better
>with STinG than your TT does, then something is wrong somewhere...
>
What can i say ? Maybe...

>>I think this happened in the October release of Dialer,
>
>But the dialer should never affect any baudrate anyway.
>That is the job of SERIAL.CPX, and none other.
>
Hmm, Peter says it must be SERIAL.LIB...

>>(and it's still here), i informed Peter as usual, but...
>>
>>BTW: Have you tested it with 76800 ? If i use this speed in SERIAL.CPX, the
>>         dialer stays dead after 'atz'.
>
>Mine does the same, because it does not support any speeds higher than 57600,
>so attempts to use higher speeds are just ignored (as random glitches).
>Even modems that do go higher may not necessarily support that exact speed,
>since it is not AFAIK a 'standard' speed for anything.
>
I also know some modems that 'prefer' 'standard' speeds.


>>         If i go to 38400 it works. If i had 57600
>>         in TT's Modem 2 port, i could be happy. (i'm not THAT speed freak !)
>
>There are clock patches to accomplish this IIRC.
>I think these give the same speeds as on Falcon.
>(I'm not sure, but with the right clock they should.)
>
You're right, there are. But acording to HS-MODEM docs, it's better if one
does it changing also the SCC. I checked, but i'm afraid to desolder this
chip (SMD).

>>----- snip ----- re: Interrupts

Not much to say, i see problems in the horizon (recent OLGA talks etc)

>>>Note that STinG itself does not in any way affect the interrupts used by
>>>low level port drivers. For serial lines this is left entirely to HSMODEM.
>>>
>>Yes, i know, but i'm afraid we have the LAN problem now...
>
>Sorry, I didn't quite get that ?
>Are you talking about problems with local networking or with the LAN port?
>
The LAN port. But since you mentioned HS-MODEM problems earlier with your
friend's TTs, this could be the case for me also.

>----- snip ----- re: ESCAPE hotkey

With Netscape and CAB.OVL for MintNet, it's possible to interrupt whatever
the app is doing with the stack. With STinG you can't.

>----- snip ----- re: MagiC-only monopoly disapproval

Your new BetaDos could be the vehicle to achieve many things in singleTOS
regarding file access.

>Still, it would be fascinating to try making a real singleTOS u:/...
>In fact that would be something very worthwhile in its own right.
>
Fully agreed. I think MiNT 1.14 sources is a good start. I could do anything
to maintain your precious singleTOS compatibility, so that we can fully
exploit MagiC ! Note also that STinG does NOT work with MagiC PC, and i'd
like to see it happening one day, 'cause i'm using it even as the windows
desktop ! (i can't stand Windows, so MagiC PC is in their 'auto' folder ! )
I can see a PC network drive, but i can't see my ATARI network !

----- snip ----- re: MintNet misunderstandings

>>  After 9 months, i still believe that STinG is great for the Internet,
>>not to mention that it brought all ATARI users together (very important).
>>But the support (at least for people that can write some software) wasn't
>>good at all.
>
>Agreed, although there is a lot more available now, the latest HYP is much
>more complete than any previous.
>
Hmmm, yes, at least for writing clients.

>Also, most of the MintNet docs I've seen were _below_ the levels making any
>specific criticism meaningful.  (like 'puzzle it out from the source' etc)
>
I agree, but then, there are tons of docs for socket programing.

>In both cases this is because most people who can program prefer to do so
>rather than spend a major part of their time on documentation.  Fortunately
>Peter is one of those people who can write understandable technical docs
>when he takes the time for it, and this is becoming more noticeable in the
>newer versions of the STING.HYP.
>
Yep, that's true.

>>Some times i think Peter wants to do everything alone.
>
>No, this is a misunderstanding.  I, for one, have been involved quite
>long and have never had any real problems cooperating with Peter, though
>we've had some very long and intense arguments.
>
I wish i had arguments with Peter, i only have long parts of my mail missing
without comments... And believe me, i've send him very detailed reports
explaining problems, making suggestions etc, etc. One thing i understand, is
that he's too busy, but so am i, so why should i bother writing mails to make
STinG better, if i get no response ? (or almost no response).

>We are both _very_ stubborn concerning things we believe in,
>
So am i...

> and will not
>yield to either side until one of us manages to convince the other that
>his facts weigh heavier. But when that happens (either way) we do yield
>directly since we share a common goal (improve STinG 'to the max') and
>only differ at times in the ways and means we deem best for achieving it.
>
But you need much more info to propose exact ways to achieve a change, don't
you think ?

>Some of the others in the list have at times mistaken this for antagonism,
>or a wish to 'control everything', but that is not so.  It is merely the
>result of consistently striving for a goal.  If someone else wants things
>done in a different way, then it is up to him (eg: me) to find arguments
>that such a change is really warranted, and suggest ways and means to do
>it.  Failure to do either of these is a strong indication that the change
>is not warranted and should not be implemented.  Also, to abandon one's
>own conviction without first being convinced that the other is correct
>would mean agreeing to a change while convinced it is wrong. Intolerable!
>
Sure, but you can't do that without help from the author of the stack. Up to
now i have relied in real problems, dissasembly, and a general 'feeling' of
what goes wrong (if it's wrong).

>As of know, I have written three of the six 'real' STXs, with Peter having
>written the others, and though TCP and SERIAL are the 'heavyweights' I can
>hardly say that Peter has tried to 'do it all'.  On the contrary, he has
>helped me a lot in getting started, especially with my first module which
>was actually 90% his code in early versions, though this has been rather
>extensively rewritten since then (Resolve.Stx).
>
Lucky you !

>I've also taken part in helping him with changes to improve both TCP.STX,
>UDP.STX, and the kernel itself, so I find him quite open to both additions
>and improvements, provided that he is given convincing arguments for them.
>None of the above could have happened if he had been the kind of guy who
>wants to keep it 'all to himself'.
>
Ok, if you say so...

>>  That's the main reason that forced me to try this port (if you can't
>>improve something that's good, you have no option but writing your own).
>
>It's a great pity that you did not 'find' us when STinG was younger, and
>much that is now 'standardized' was first hammered out.  I am sure that
>your participation in those debates would have been useful for all.
>
Maybe, at that time i had much more free time to concentrate day and night
onto STinG. It's really a pity.

>>  I still believe that we don't have the luxury to write the same things
>>again and again, but...
>
>Agreed.  That would be wasteful, and we do not have all that many actively
>working on STinG stuff.
>
TRUE. But i think things are getting better.

>>Whith this in mind, i've send you the sources for
>>BNET_TCP (and you didn't ask for, right ? )
>
>I don't remember exactly.  I think you offered to do it before I asked,
>but otherwise I probably would have.
>
Yep, i did the minute you mentioned something about a net filesystem.
('cause FTP protocol can't prevent date/time stamps etc)

>>and then the sources for user_login and password generation of FTP Server
>
>Actually this kind of user-access limitation method could be implemented in
>a more general fashion to, since it does allow a simulation of Unix-like
>access flags on normal TOS drives.
>
I can send them to you also, even the whole FTP Server if you like, but note
that the whole is 151 kb of 'C' code, plus headers in my PURE_C include, in
KA9Q's dir, even headers from Turbo C++ (PC version 4 !). So, you have been
warned !

>>to Peter (he asked them and got'em the same day). Well, that's the way i
>>see things. If others don't, this is not my fault...
>
>Actually I think Peter too agrees with this intellectually, it's just that
>he often doesn't get the stuff sent when he ought to.
>
No thanks, i switch subjects very often in my 'programming life', so getting
something that i need now in more than a month (for example) doesn't make
things easier. Ok, you can blame me for not being an 'organized' person, but
i can't change this near my 40 years ! (and i don't like to make promises for
new software, that is never ready, for one reason or another).

>  Also, I think he is
>a little worried about the possibility of approaching the total chaos of
>the Linux and MiNT developers, where even normal users are expected to
>compile their own kernel versions to get something useful, and no one can
>be really sure what the latest kernels really contain without intense
>study of huge and complex 'make' files (that seldom work right).
>
I agree with that, but i thought that if one could get STinG sources, he
should send them back to Peter for final approval, before something goes
public. At least that was (and still is) my intention.

>So for STinG changes and additions should be agreed upon together, through
>debate, and then implemented in a single release.  This way there is never
>any confusion as to what is, or is not, the current state of STinG.
>
Only that some times we have two or three TCP.STX modules where Peter has
forgoten to update the version number, and this can cause confusion.

>For this purpose I too have several of Peters sources, and given that they
>are only used for these purposes I do not see any reason why he should deny
>other serious participants the same opportunity for studying them.
>
This is the only way to document if something has to be changed or not, can
be done or not etc, etc. Otherwise i'm talking 'to the air'.

>  But
>naturally that decision is not up to me, except where it concerns my own
>sources (Resolve.Stx, Masque.Stx, Cen_PLIP.Stx).  Those are of course at
>your disposal simply by asking me for them.
>
Why ask for something that works fine from day one ? (Resolve.Stx) Thanks
anyway. Masque and Cen_PLIP could be very helpful for other drivers, so i
definetely want them.

----- snip -----> re: Newspapers printed with ATARIs

>Even so, considering what I know of the contrast in speed between nAES and
>MagiC, that impressive speed must be a slow crawl compared to what they
>could do under MagiC.
>
Absolutely right ! MagiC is now available for the Hades. But what about the
network ?

>>  Now i desperetely want a Hades... (it costs 2000 DM for them)
>
>Appx 70000 Swedish crowns then...  No, that is just too much.
>
>Not because It could buy several _very_ fast pentium systems (which it could)
>I don't like those systems anyway... so there is no contest...
>
Ooops, you can buy 1.5 (!) _very_ fast pentium with this amount here. But if
you mean motherboards for existing systems, i agree.

>But the same money could also buy a _very_ neat PowerMac system,
>which can still be used for Atarian software under MagicMac
>
I don't know about PowerMac here, Macs were _very_ expensive, and i know that
the guys selling Macs here, were stupid enough to loose almost their whole
market.

>Don't get me wrong, I'm glad that advanced Atari compatibles are still made,
>
Of course i don't.

>but the low production volumes for this market makes a lie out of the old
>motto 'Power without the price'.  Instead we now have a reversed situation,
>so that the same money buys more raw power when spent on any other brand
>having larger production volumes.  I find this sad, but it is inevitable.
>
It is, let's see how Milan is going to do in the market...

>>Well, this was long (again).
>
>So it was (as usual), and so was this response.
>(several hours long in fact ;-)
>
Same here, so sorry if i did it shorter. I think that keeping long paragraphs
just to say 'i agree' isn't much help. But i still have your original, so if
you think i've left something unanswered, just tell me.

  Ok, i'm going back to BNET.XFS (have to finish it some day ! ) I also have
to test BetaDos, Infitra etc, etc. Still, i'm happy that we have so much to
do for our machines.

Regards    Vassilis

.
