::: Area #68 (Comms............ [Acorn])
Message: #2563 (Read 7 times, has 0 replies, 6240 bytes)
Date   : Mon Dec  1 21:27:42 1997
From   : Keith Hall of fidonet#2:250/219
To     : Jonathan Harston
Subject: Re: <subject> XModem-CRC calculation

Quoting Jonathan Harston in a message dated 25th of November :

JH> date 09-Nov-1997, 14:55.  That's better.  And the '03'... ah! File access
JH> byte, 03=00000011 -> myread=yes, mywrite=yes.

'3' is actually a 'capability' flag:

if bit 2 is set (i.e. byte = 03 + 4 = 07) then it would be from arc-binkley as
that sends the attributes too.

I found a document detailing it a bit more - it's not the one I was thinking
of, but it'll do (from 9th July 1993) :

-----8<-----
Quoting Keith Marlow in a message dated 03 Jul 93  18:32:02 :

 > PB>Yep, me too. Ah well. Steven has apparently done it in a neater way,
 > PB>but it's not compatible :-}
 >
 >   Oh #$@&!.. give two programmers the same problem and they will come
 > up with at least two different solutions, none of which work with each
 > other.. its strange but the idea of cross compatibility usually seems
 > to be the last thing on most programmers mind when writing s/w..  I.e
 > why did Hazzy come up with a different method in the first place if the
 > original worked or was it doing something nasty to those systems that
 > didn't expect the extra info?

Could I please set this straight once and for all.

Our (Hugo,Geoff,David Pilling,Peter Gaunt,Me and others) method does not
interfere with any other program used to download zmodem, that was written
*properly*, i.e. every bit of known software under the sun. ARCbbs uses the
same method as ArmBBS and Binkley. Extending the info block to 128 bytes
(possibly an extra 60-70 bytes above blocks without archie-specific stuff)
does NOT do any program any harm.

What Hazzy's done is to use the area where a SERIAL NUMBER is placed in
zmodem specs. Quoting the part of the spec :

 <> SERIAL NUMBER A single space separates the serial number from the
 <>      file mode.  The serial number of the transmitting program is
 <>      stored as an octal string.  Programs which do not have a serial
 <>      number should omit this field, or set it to 0.  The receiver's
 <>      use of this field is optional.
 <>
 <> The file information is terminated by a null.  If only the pathname
 <> is sent, the pathname is terminated with TWO nulls.  The length of
 <> the file information subpacket, including the trailing null, must
 <> not exceed 1024 bytes; a typical length is less than 64 bytes.

This spec is obtainable from Cryton early on in tech specs, or #552 from
my board.

The above programs do not exceed 1024 bytes, and do not overwrite the
serial number. As the information is written at byte 128 - it gives room
for zmodem expansion should Chuck Forsberg change/add anything. One such
thing I found in V3.00 of his sources (which support RLE for data
compression), is that he sends the total number of files, and the current
file number straight after the serial number field. However this is not
mentioned in the above spec (due to it's age probably) :-)

My point is (and everyone else agrees except himself of course), is that
Hazzy's method is definitely wrong. It may work, and it may work between
two mailers, but it's incompatible for use in a BBS, and Binkley will
certainly not change. I can only hope that he will add support for the way
binkley does it as it is stupid to have archie mailers not capable of
transmitting/receiving filetype information correctly.

Here follows the bit of code (that we all use) to set/determine filetypes.

typedef struct
{
  int unused [128/4-3];
  int exec;
  int load;
  int capab;
}
archie_stuff;

void filetype(char *buf,int execp,int loadp)
{
  archie_stuff *f=(archie_stuff *)buf;
  f->capab=3;
  f->exec=execp;
  f->load=loadp;
}

and at the end of wctxpn() (from Zmodem V3.00 sources - latest known)
for sending the filetype :

  sprintf(p, "%lu %lo %o 0 %d %ld", length, mtime, mmode, Filesleft, Totalleft
);
  Totalleft -= length;
  if (--Filesleft <= 0)
    Totalleft = 0;
  if (Totalleft < 0)
    Totalleft = 0;

  filetype(txbuf,f.st_exec,f.st_load);  /* set filetype */
  blksizlen=(1+strlen(p)+(p-txbuf));    /* determine block length */
  if(blksizlen<128)
    blksizlen=128;                      /* ensure block is large enough */
  return zsendfile(txbuf,blksizlen);    /* send file */
}

When receiving - check that the capabilities flag is set to three, _if_ the
received info block is 128 bytes or greater.

I hope this aids those who require the information, and settles the minds of
the confused :-)

Glad to be of any assistance,

Cheers,

|/
|\eith.

-----8<-----

And I found the one I meant to find anyway !!! (19th September 1993 -
Hazzy had changed his mind and decided to use our method) :

-----8<-----
Steve,

well as you're probably going to see this I'll explain it here...

easy way to do things :

C code

typedef struct
{
  int unused[128/4-4];
  int attr;
  int exec;
  int load;
  int capab;
}
archie_stuff;

void filetype(char *buf,int execp,int loadp)
{
  archie_stuff *f=(archie_stuff *)buf;
  f->capab=7;
  f->exec=execp;
  f->load=loadp;
}

and after the sprintf which writes the file details to the txbuf, place

  filetype(txbuf,f.st_exec,f.st_load);

struct f is filled in from calling the stat() function.

it's handy to also have

  if(blksizlen<128)
    blksizlen=128;

in the source after the filetype() call.

on reception, all you need do is read the stuff in again...

int check_filetype(char *buf);
{
  archie_stuff *f=(archie_stuff *)buf;
  int ret;
  if((ret=(f->capab==7)?1:0)==1)
  {
    read_in_exec=f->exec;
    read_in_load=f->load;
  }
  return ret;
}

and then :

  os_regset r;
  r.r[2] = read_in_load;
  r.r[3] = read_in_exec;
  r.r[0] = 1;
  os_swix(0x20000 | OS_File, &r);

somewhere else to set the filetype.

use the same procedure for all ftp's (I'm still awaiting response from
Arjen Lentz regarding filetypes in Hydra)...

Cheers,

|/
|\eith.

-----8<-----

Hope this is of use... Don't forget that capabilities should be 03 for BBS
use, 07 being mailers only-ish...

Cheers, Keith.
--- Dimofail v1.98 (10-01-95)
 * Origin: The Plasma Sphere BBS 24 hrs (01925) 757920 / 757921 (2:250/219.0)