RFC-X-No-Archive: Yes
TZUTC: 0100
CHRS: CP437 2
PID: GED+W64 1.1.5-b20240306
MSGID: 2:280/464.112 65fbe690
REPLY: 3:633/280 65fb8c80
Hi Stephen,

On 21 Mar 24 12:21, Stephen Walsh wrote to Wilfred van Velzen:
  about: "FMail 2.3.0.0 public beta release":

 SW>>> pkt.zip & fmailm68k.zip in your inbound.... If you want to do
 SW>>> something with M68K support... (This is after all just something
 SW>>> todo on my part!)

 WV>> Not really. ;-) I think there are more important things on the todo
 WV>> list.

 SW> That's understandable, I doubt you'd have a huge M68K user base... Mostly
 SW> a count of 1... #-)

You are not using it! So 0. ;-)

 SW>>> FMail-lnx-m68k-2.3.0.0-Beta20240317 - The Fast Echomail Processor
 SW> [...]
 SW>>> Packet is addressed to another node (256/49920); packet file:
 SW>>> /home/vk3heg/fmail/inbound/f8d28501.pkt is renamed with
 SW>>> extension: '.wrong_destination'

 WV>> 256/49920 = 1/195, if you swap bytes. So a typical endianess
 WV>> problem...

 SW> I just looked through what andrew did to add M68K support in Talisman BBS
 SW> and it's not just a few lines of code...

Making the pkt code endianness agnostic isn't a big task. My pktviewer code
does it. I wrote it decades ago, so it would compile on both the Amiga and PC.
;-)

But doing so for the three supported messagebases (msg, hudson, jam), is a
huge pain in the ass, because the code for these is all over the place.


Wilfred.

--- FMail-W64 2.3.0.1-B20240319
 * Origin:  point@work  (2:280/464.112)
SEEN-BY: 15/0 90/1 103/705 105/81 106/201 124/5016 128/260 129/305
SEEN-BY: 135/225 153/757 7715 154/10 30 203/0 218/700 221/0 226/30
SEEN-BY: 227/114 229/110 112 113 206 307 317 426 428 470 550 664 700
SEEN-BY: 240/1120 5832 266/512 280/464 5003 5555 282/1038 291/111
SEEN-BY: 292/854 8125 301/1 310/31 320/219 322/757 341/66 234 342/200
SEEN-BY: 396/45 423/120 460/58 256 1124 467/888 633/280 712/848 770/1
SEEN-BY: 5020/400 5054/30
PATH: 280/464 460/58 229/426