On 2019 Jul 04 02:07:36, you wrote to Maurice Kinal:

 RS>>> I think that's a completely different issue.

 MK>> Not really.  The fact that nothing is ever done about these "bugs"
 MK>> when raised with suitable evidence isn't going to change anything if
 MK>> my observations have been correct over the decades.

 RS> If it's a problem for you, then switch software?

the problem is in the path... he writes messages and checks them at other 
systems... some system(s) along the path are stripping out 0x8d and that's (one 
of) the problem(s) he's pointing out...

FWIW: maurice's stuff is all bash code using traditional linux tools... there's 
no BBS or FTN specific compiled code in the mix... it is about as basic as one 
can get... i think he reads the messages pkt by pkt using his raw methodology 
but i've not looked deeper into his setup... i think nicholas boel did at one 
time, though...

 RS> SBBSecho used to strip 0x8d's and since rev 3.113 (Apr-30-2019) no
 RS> longer does (at least, not by default).

thanks for that, too!

 RS> See? "bugs" can be fixed, so long as someone has the source code.

or can sufficiently hack the binaries ;)

 MK>> I posted a CP866 as an example and lo and behold the single 16-bit
 MK>> charater with the trailing bit 0x8d was deleted.  The only differece
 MK>> is that in utf8 those bytes matter way more than they do in purely
 MK>> 8-bit land.

 RS> So find out what software is stripping the 0x8d's and start a campaign
 RS> to get that software "fixed".

we've been looking... the possibilities are down to only a few software 
packages ;)

)\/(ark

And to this end they built themselves a stupendous super-computer which was
so amazingly intelligent that even before its data banks had been connected
up it had started from "I think therefore I am" and got as far as deducing
the existence of rice pudding and income tax before anyone managed to turn
it off.
... The four seasons are salt, pepper, mustard and vinegar.
---