Subj : MMTerm? To : Jim Hanoian From : Jasen Betts Date : Sat Apr 21 2001 01:48 am Hi Jim. 19-Apr-01 15:51:14, Jim Hanoian wrote to William McBrine -=> William McBrine wrote to Jim Hanoian <=- JH>> initial root of the all caps header. Also, PCBoard messages had JH>> a size limit of 64k (I think it was) which was later "updated" to JH>> permit messages of a liberal 100 lines. WM>> 64K is much more than 100 lines, actually -- figure 80 chars WM>> (ignoring that most lines are slightly shorter) * number of lines WM>> = 8K for 100 lines. JH> Again, maybe my memory is playing tricks on me. There was some JH> limit that was originally set by size, that was expanded to the JH> 100 lines. Later, as hard drive space became more affordable, the JH> limit was lifted. JH> This change was before my time, and I can remember buying my first JH> hard drive for my first XT computer. It was a 20meg drive and I JH> got it *used* for only $200. JH>> I remember TomCat, and WildCat still uses the "T" command to get JH>> into mail, doesn't it? WM>> Indeed. They took away the TomCat name, but kept the key for the WM>> benefit people who were already in the habit, and made up a new WM>> string to fit it ("Transfer QWK mail", or something like that). JH> Didn't want to break any scripts, eh? My problem with JH> switching from a PCBoard BBS to a WildCat BBS was the use of the JH> "N" key. On PCB it means "NO" as in no more of this list, but on JH> WC it means "NONSTOP" as in let the list rip with no pauses. JH>> [OPX doors are] Much more consistent that the ways that different JH>> QWK doors worked with different BBS types, right? WM>> In some ways; but overall, not really. Take the line endings WM>> (please) -- in QWK, every line ends with character 0xE3. This is WM>> unambigious. In Blue Wave, they're defined as CRs to terminate WM>> each paragraph, with LFs to be ignored if present. In OPX, I WM>> discovered that they can be either LF, CR, CRLF, or even a WM>> misused "soft CR", depending on the door. It's psychotic. JH> Does that have anything to do with the base BBS the door is being JH> used for? JH> I was under the impression that Fido prefered to allow the reader JH> or the user to reflow paragraphs (something like what is done with JH> HTML today) to fit their particular screen and/or machine, and JH> that forced line length ala QWK is frowned upon. WM>> Then there's the EXTAREAS.DAT file. In some doors, this is used WM>> to list any areas after the first 256. But it's not actually WM>> necessary, because other doors just add those areas to WM>> BRDINFO.DAT along with the first 256. WM>> I could go on and on with this. There's also the internal WM>> inconsistency found in every implementation, because it's part of WM>> the spec: there's a mix of C and Pascal-style strings, for WM>> example. (It's mostly Pascal-style, but the message headers are WM>> lifted whole from the Fido specs, which use C.) JH> QWK has the same kind of mixed language and types, doesn't it? No, it uses BASIC types throughout. :) (messages.dat) Fields #1, 1 as status$,7 as msgnum$, 5 as mdate$, 5 as mtime$,25 as mto$, 25 as from$,25 as subj$, 12 as password$,8 as refnum$,6 as blocks$, 1 as killflag$,2 as confnummki$,2 as sequencenummki$, 1 as taglinepresent$ (but obviously with shorter names so as to fit...) (index files) fields #2,4 as offsetmks$,1 as conf$ -=> Bye <=- --- * Origin: The answer to my fido addiction: a point (3:640/531.42) .