BS>> Well it wouldn't make any bennefit now :/ There is 
 BS>> needed to be fixed a few things first.

 BJ> But we could test it when running max in local console mode! 
 BJ> ("bin/max -k"). 

 BS> Yes, it works, because i packed the files manually.

Ok.  Good.

 BS>> * Maximus has problems about calling the archiver, it 
 BS>> quits because zip returns "Nothing to pack".. And the 
 BS>> string i correctly whitch is executed.

 BJ> Interesting.  Take a look at (a) path definitions, (b) what's
 BJ> different between how squish uses the compress.cfg filel and how
 BJ> max uses the compress.cfg file. 

 BS> I took at look in the language definitions files, there 
 BS> was maxpipe defined on UNIX, and i did undefined, so 
 BS> now it runs '/usr/bin/zip -j -q  path/downlink.qwk> /*.*' and it's quite 
 BS> wierd because Squish is doing just greate with my Compress definitions.

Ah...  That actually makes sense.  Squish doesn't uses maxpipe, so it
wasn't impacted.  And I think maxpipe is one of the options we want to
exploit in the future, but requires some work....

 BS>> * Filetransfer doesn't work properly over TELNET.

 BJ> In what way?  [I haven't tested this....]

 BS> It just doesn't work :( Ztelnet works with all BBS 
 BS> Systems, and it doesn't work :(

Ok.  Then we are probably not 8-bit clean on the max telnet side.  That
doesn't suprise me....  :(

 BS> My suggestion is that we use sz/rz (lrzsz) for zmodem 
 BS> transfer on UNIX platforms.. 

Won't help until we get the tcp/ip connection 8-bit clean....  :(  

On the other hand sz/rz might just have code in it to reset the pipe to
become 8 bit clean, in which case we could look at that code and fix
Max....  Hmmmm....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01