[TUHS] Software written in B

[segaloco via TUHS]

Angelo, do you mind if I mirror these disassembles into my https://gitlab.com/segaloco/v2src repository?  That's where I'm (very slowly) accumulating the results of mt own disassembly efforts on the V2 binaries.  Bonus points if you raise a PR, but I can make sure you get a shout-out in the Readme or something otherwise.  Thanks for digging deeper where I haven't found the time.

- Matt G.

------- Original Message -------
On Wednesday, June 14th, 2023 at 1:03 PM, Angelo Papenhoff <aap at papnet.eu> wrote:


> After writing this mail I actually started reversing the B binaries.
> You can find them here: http://squoze.net/B/programs/
> 
> I did find some differences in versions of the B runtime and library.
> Especially interesting was an implementation of the cksto routine
> in su and stty that checks whether an address in an assignment is in a
> reasonable range ("LV out of range" error if not)
> 
> What is perhaps interesting historically is that the su binary contains
> a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
> it is given as a command line argument.
> 
> I will hopefully continue with this in the next time (if, goto, mail and
> glob are left).
> 
> Best,
> aap
> 
> On 14/06/23, Angelo Papenhoff wrote:
> 
> > Thank you two for finding this!
> > I did some disassembling yesterday and have uploaded brt1.s and brt2.s
> > to my site now: http://squoze.net/B/brt/ (I haven't actually assembled
> > them yet, there may be mistakes)
> > 
> > Some observations:
> > 
> > - The 'chain' format is actually a linked list and not a list of
> > addresses. Phil and I both got this wrong.
> > 
> > - The "Init" string is an error message if for some reason the B init
> > chain didn't run or main doesn't look like a function
> > 
> > - The cmdline arguments overwrite part of the init code. There's about
> > 80 bytes of space for them before it overwrites the code that builds the
> > argv vector
> > 
> > - brt2.s is only to mark the beginning of the stack
> > 
> > I also saw some differences in the bilib code but haven't really
> > analyzed that part (yet?)
> > 
> > Would be really great if we could get all the files disassembled and
> > decompiled and restore the source code for everything :)
> > 
> > Best,
> > Angelo