AmiBinkd 2026
From
Gary McCulloch@39:902/518 to
All on Wed Aug 19 20:34:32 2026
AmiBinkD - a native AmigaOS binkd, and how it gets tested ---------------------------------------------------------
AmiBinkD is a port of binkd to AmigaOS 3.x. It talks straight to bsdsocket.library - no ixemul, no ixnet - and runs on real 68k iron
or under emulation. BinkP/1.1, CRAM-MD5, works with C-Net/5 and any
other FTN-aware BBS.
The goal is not to write a new mailer. It is to get *binkd itself*
running on the Amiga. 18 of binkd's 34 source files are completely
untouched, and protocol.c - the binkp engine, 3,769 lines - carries
exactly one Amiga-specific line. Where the port does deviate, it is
almost always to work around something broken in the Amiga C library,
not to change how binkd behaves.
TESTING
It runs on a live board carrying seven networks, and that is where
the bugs turn up. Recent examples, all found in production:
* Outbound mail was going out as ZERO BYTES - every bundle, always.
Nothing logged an error, because no layer had one: the tosser
packed a valid archive, and binkd sent exactly the byte count it
was given. The cause was libnix13's fstat(), which always reports
st_size == 0 (it measures with SEEK_CUR right after seeking to the
start). Upstream binkd's code was correct; the C library was not.
Fixed by overriding fstat(). If you build ANY Amiga software with
-mcrt=nix13 and it depends on file sizes, this affects you too.
* Log lines were being torn in half when two sessions wrote at once.
binkd locks its log - but with a private semaphore, which is fine
for one process with threads. This port runs each session as its
own AmigaOS Process, so the lock has to be a PUBLIC semaphore to
span them.
* Concurrent sessions all logged under one id, so three simultaneous
inbound calls read as triplicated lines. Now each has its own.
RELEASES
v10.25 is current and in the file area. v10.29 follows once its soak
is done - by then the fixes are mostly small: quieting a benign lock
race that logged at error level, and removing a diagnostic that
turned out to be reporting garbage.
Nothing ships until it has run on the board for a day or more. A fix
that has not survived a real night of traffic is a guess.
Reign of Fire BBS - call.rofbbs.com - telnet 6800 / ssh call@
* ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
* C-Net/5
* Origin: call.rofbbs.com : 6800 6400 8502 : 423-541-8271 : rofbbs.com (39:902/518)
From
Gary McCulloch@39:902/518 to
All on Sun Aug 23 08:26:08 2026
AmiBinkD v10.33 - and where it sits among the other Amiga mailers ------------------------------------------------------------------
AmiBinkD is a port of binkd to AmigaOS 3.x. It talks straight to bsdsocket.library - no ixemul, no ixnet - and runs on real 68k iron or
under emulation. BinkP/1.1, CRAM-MD5, works with any FTN-aware Amiga
BBS.
v10.33 is out. Before the release notes, a word about something that
has come up: AmiBinkD is not the only non-ixemul mailer for the Amiga,
and it was not the first. Worth setting out plainly who has done what,
because three different projects are getting talked about as if they
were the same thing.
WHAT IS ACTUALLY OUT THERE
AmiBinkd v9.02 (2014, X-TReMe BBS)
The original Amiga binkd, and the one people mean when they say
"the old AmiBinkd is buggy". Nothing to do with this project
beyond the name, which I kept because sysops already knew it.
In hindsight that has caused more confusion than it saved.
FidoBlitz (Stephen, v0.19 May 2026)
A native Amiga Binkp/1.1 mailer written in AmiBlitz3. NOT a port
of anything - it is a fresh implementation of the protocol. That
is a different kind of work from what I am doing, and a harder
one in some ways: everything binkd already solved has to be
solved again.
binkd 1.1a-115 noixemul (Ervras, Aminet June 2026)
pgul's binkd adapted to AmigaOS 3.2 without ixemul, built with
bebbo's gcc, requires 68020 or better. Ships extras I do not:
srifreq, process_tic, a nodelist compiler, decompress. His repo
dates from April 2026, so he got a non-ixemul binkd running on
the Amiga before I did. Credit where it is due.
AmiBinkD v10.x (this one)
Also pgul's binkd, also no ixemul. Two differences that matter:
* It builds for plain 68000. No 020 required, no FPU, soft-float
throughout. If you are running a stock A500 or A2000, this is
the one that will start.
* It is deliberately still binkd. 18 of binkd's 34 source files
are untouched, and protocol.c - the binkp engine, 3,769 lines
- carries exactly one Amiga-specific line. Where it does
deviate it is almost always to work around something broken in
the Amiga C library, not to change how binkd behaves.
Two people ported the same program independently without knowing it.
That is how it goes in a hobby this size. Use whichever fits your
machine.
WHAT v10.33 FIXES, AND WHY IT MATTERS TO EVERYONE HERE
For weeks this board had a rare, ugly fault: now and then a write meant
for one file turned up in another. A .bsy lock file was found holding a
line of log text. About 0.2% of log lines - rare enough to look like
cosmic rays, often enough to eventually corrupt something that matters.
Four theories were wrong before the right one. What settled it was a
test that hammered TWO files at once from several Processes. Every
earlier test used a single file and passed cleanly, because with one
file a mixed-up descriptor still resolves to that same file. Two files
and it reproduced in ten seconds: 92 of 1000 log lines lost, and lock
markers written into the log.
The cause is in libnix, not in binkd. Every descriptor comes from
___allocfd, which scans a shared global table for a free slot and grows
it with realloc(), reassigning the global pointer. Disassembling that
layer - open, close, write, read, lseek, fopen, fwrite - there is not
one Forbid/Permit, not one semaphore, nothing atomic anywhere in it.
That is fine for a normal Amiga program. It is not fine if you run more
than one Process, because on AmigaOS they share ONE address space. Two Processes calling open() at the same moment can both take the same
slot. The loser's descriptor now points at the winner's file.
READ THAT AGAIN IF YOU WRITE AMIGA SOFTWARE. It is not a binkd bug and
it is not mine. Anything multi-Process built against libnix has it,
including - I would guess, though I have not tested his build - the
other binkd port above.
v10.33 keeps the heaviest user out of that table. Log() opened and
closed the logfile for EVERY line; it now goes through dos.library
directly and never allocates a descriptor. 4,133 log lines over two
days including outbound transfers, zero corrupted. Lock files and
transfers still use the library's descriptors, so this is not a
complete fix - but those run at a tiny fraction of the frequency.
YOUR PEERS MAY HAVE YOU LOGGED UNDER THE WRONG VERSION
The version was hardcoded in three separate places: the startup line,
the shutdown line, and the VER string sent to every node you poll. Two
got updated over the years and one did not.
From v10.19 to v10.32 every node this system polled recorded it as
v10.19 - including under a release published two days ago. Nothing
local was wrong. Only the REMOTE's log showed it, which is why it went
fourteen versions without anyone noticing. Worth grepping your own
sources for duplicated version literals.
UPGRADING
On v10.23 or earlier: your outbound mail is not being delivered.
Every bundle goes out announced as 0 bytes - libnix13's fstat()
reports st_size as 0 while returning success. Sessions look
completely normal in your log. Fixed in v10.24.
On v10.19 to v10.32: see above, your peers have you as v10.19.
AmiBinkD10_33.lha is in the file area, and on GitHub at
github.com/SpitfireTN/AmiBinkD
Nothing ships until it has run on the board for a day or more. A fix
that has not survived a real night of traffic is a guess.
Reign of Fire BBS - call.rofbbs.com - telnet 6800 / ssh call@
* ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
* C-Net/5
* Origin: call.rofbbs.com : 6800 6400 8502 : 423-541-8271 : rofbbs.com (39:902/518)