Rick's b.log - 2024/03/25
It is the 18th of December 2024 You are 18.119.112.255, pleased to meet you!

Old code considered harmful?

A part of the reason for this is that not so much has been done with the library that I use, DeskLib, since sort-of-1995-ish. I use my own custom build, so I have made some modifications along with my own work at making it 32 bit safe (that I originally did back circa 2002ish).

In parallel, and a little while after I started my own version, it was taken on by the GCCSDK guys and it's on the riscos.info site ... and yes, that site is currently broken. The packages exist but the Wiki part appears to be dead. It may be that a server update broke MediaWiki (again)? That's why ARMwiki came and went on this site - it broke with a major PHP update and, well, there was no time or impetus to fix it. Sorry, but if they can't grok the idea of backwards compatiblity... <shoots Python a death glare over the 2/3 debacle>
Anyway, the version there has seen a little more love and has a few additional parts and stuff fixed. I guess it's a case of "as needs must". I would fix the stuff I need, they fixed the stuff they need. And now there are two, slightly different, versions of DeskLib in the wild.

This isn't as big a thing as one might think. This is because, and here's the primary reason that I continue with mine, is they ditched ALF support a few releases back. As I understand it, GCC on RISC OS no longer supports ALF. It's ELF only these days.

For those who don't know (or remember) the acronyms, the original set of tools (assembler, compiler, etc) supplied by Acorn and later RISC OS Open is known as the "DDE". We often call the compiler "Norcroft" as that's who made it originally.
These are the tools necessary to build RISC OS itself, and quite a lot of existing software is built using these tools. They are the ones that I use (so if you see references to ObjAsm, that's the assembler).
There are four primary files used during the process of building an application. The first is the source code, duh. This then gets translated into an AOF, Acorn Object File. This is the immediate output from the assembler or compiler and it contains the built code along with a list of all of the references (functions or variables) that it expects to find, along with all of those that it provides. It's the job of the Linker to collect together all of these intermediate files, patch up all of these references so everything knows where all the other bits are, and issue an AIF (Acorn Image File), which is the nerdy way for saying "the program executable" (or, alternatively, a module or utility or whatever).
The other option is the option used by libraries, be it DeskLib, RISC_OSLib or CLib itself. In this case you collect up all of those intermediate files (the AOFs) and bung them together in one big file that is called an ALF file (Acorn Library File). This has the same overall effect of supplying potentially dozens or even hundreds of prebuilt intermediate object files, but without the complications of having hundreds of files around the place (all of which would need to be specified to the Linker one by one). Instead you pass a single reference to the library file and say "it's in there" and the Linker will sort it out.

Here's a diagram of how all these parts fit together.

An overview of how programs are built.

While there's a version of DeskLib that's a little newer/better within the GCCSDK, it - and GCC in general - have abandoned the traditional Acorn formats and work with ELF (Executable and Linkable Format) that is a standard in the Unix world. There is, at this time, no native support for ELF within RISC OS, so it requires an extension (SOManager, I think) in order to load such programs, or to have them converted to AIF. This is neither here nor there. GCC and ELF support the concept of shared libraries (akin to DLLs) without which we either wouldn't have software such as Iris (the WebKit browser) or it would be an executable with everything statically linked that would be something like 120MB in size, which would be ridiculous when you realise that every browser window consists of two processes (one for the network and one for the browser). Shared libraries are the only way such a thing would make sense.
But, alas, there is a schism between GCC and the DDE. It's no longer possible to interact between them, it's now one or the other (or both but individually).

Note well - I have nothing against GCC. It's a perfectly competent set of tools. I just happen to already have the DDE and no inclination to want to learn or deal with another toolchain and its quirks.

Anyway, that's why the two DeskLibs. Now let's look at Tea.

The first thing that I ran into was newer calls that simply don't exist. For instance, I had to call Font_ScanString myself because there's no equivalent in DeskLib. This call was present in RISC OS 3, so I'm guessing its absence is either an omission, or because it does so damn many things that it would probably need several functions to call it in different ways.
The next thing was Wimp_ResizeIcon. This is RISC OS 3.50 or newer, so DeskLib can be forgiven for this not having been done.

I also had to write my own code to call Wimp_ReportError because I wanted a custom title for the message, and there's no call to do that. Again, all of the additional features are part of the nested Wimp, so it's sort of 1996ish I think. I have already added some functions for this, so I guess a "with title" will be another to add.

There is also a very serious bug in the library itself. As you might recall, this was my first time at writing an application that creates icons on the fly. Given that each programme gets its own icon, the standard selection of channels can generate a window with 400-500 icons. If you select all channels, you're looking at a huge number of icons.

Which all worked fine until I wanted to update the title of the window to provide the date of the programmes being shown... at which point the application would shit itself and instantly die, with tracing code showing that things were in a state best described as Cthulhu walked by.

It turns out that the Window_SetTitle() function defines a local window_info block which is allocated space on the stack. This is space for reading in the window definition block used for the given window, in order to examine/manipulate the window. In this case, we would look for the address of the indirected data that gives the title of the window, so we can change that text to something else.
The problem was that DeskLib was errantly using the call to Window_GetInfo() rather than Window_GetInfo3(). The difference is that the latter call (new to RISC OS 3, hence the '3') returns only the window block. The older default call will return the window block and follow that with all of the icon data. Hundreds of them. Which will have not slaughtered the stack so much as annihilated it.

I will need to fix that, and take a look to see if anything else uses the older call when it shouldn't... though there's a part of me that says I ought to actually delete the older call and alias it to the new one. I mean, is there an actual use case where reading god knows how many icons would be useful?
Actually, I might keep it, but call it something like Window_GetInfoAndIcons() to make it very clear that it has side effects.

Thinking about this, I wonder if it could be the cause of subtle bugs elsewhere, in other programs that set a window's title? A couple of icons being read into a block of memory with no space for them might corrupt things in hard to detect ways as it'll be subtle or hard to spot (or maybe even have no real effect if what follows is, say, a string that is set afterwards?), it wasn't until the call encountered a window with hundreds of icons that everything exploded. The icon blocks themselves are small, 32 bytes per icon, but 450 of them adds up to wiping out a little over 14K of whatever may have been on the stack. "Oops" just doesn't cover it.

Of course, this is the fun of dealing with a system that hasn't had a lot of extraneous development work in the past thirty-ish years. People are still using DeskLib, the Toolbox was released by Acorn in the latter days and hasn't changed much either, and the DDE still ships with RISC_OSLib which is best described as "various functions used in writing the three ROM apps, plus some other stuff to make it look like a real library". Interestingly, the current incarnations of the C/C++ manual have removed the hundreds of pages describing RISC_OSLib, so you'll need to pop over to 4corn to grab a copy of the Acorn C v4 manual in order to get a description of what the library functions do.

Danew, the saga continues

They said it was tested before shipping, and given that it came right up with the Android main screen I don't doubt this. It just didn't survive a reboot. I don't know why. Maybe it was an old thing lingering around that got "updated" from an SD card (the bootloader can do this) but the update itself was somehow iffy or just plain broken? Like I said, Android 9 is old.

They have invited me to send it back, so this time here's the parcel.

The parcel this time, basic
protection and under 2kg.

I did some serious origami on the original parcel box in order to get the thing wrapped in such a way as to get the weight of the parcel down under 2kg so it should be able to be shipped for less. I sat on this for a week wondering if I should even bother, but, hey, having something for a tenner or so is better than having nothing I guess. At the least I can pop Docs on it and use it to write stuff while on break at work?

Yup, brambles

Today? Well, I wasn't actually planning on doing anything (and my back certainly isn't thanking me right now) but I wandered outside to stretch my back while waiting for the kettle to boil for more tea (of course) and, well...

What I started with.

About two and a half hours later...

What I ended up with.

I no longer need to guide my dinky little car down a gap between the house and the brambles, I can literally park another car there and still have space to squeeze by.
At least, it'll give me more space to back up.

That doesn't look so impressive, so here's another view. You can see on the right half where I drive by, and on the left? It's all brand new space.

Another view of the clearing.

Old phone (OMG, yes, another!)

The DTMF board.

I have flipped photo of the underside of the board and overlaid it on top of the photo of the component side. It's not great, but it's enough to start to look at what goes where.
You can download the full size image (1602×1385, 918.33KiB).

Anyway, here is the phone, the brown one beside the one that is actually hooked up to the Livebox. It's quite nice looking, isn't it?

Two old-fashioned DTMF phones.

Yes, they're sitting on top of cat food boxes. As good a place as any.

Speaking of which...

Anna's last day as a female cat

Anna being Anna.

Today is her last day as a female cat. Tomorrow morning she is going to have... unspeakable (in the Lovecraftian sense) things done. It's for her protection, vaccination against anything the local (not necessarily tame) cats may have, and neutered to make her less desirable to the males, plus nobody having to deal with the situation of having kittens turn up.
I just hope she'll forgive me...

If it's any consolation, little furball, I will have Lovecraftian horrors inflicted on my mouth on Wednesday. Dentistry is weird, you pay to have pain inflicted. <shrug>

Your comments:

David Pilling, 27th March 2024, 13:43

Way back libraries seemed a great idea, now cause of a lot of trouble. I am having my own problems with RISC OS software, so interesting to read about the compiler situation. As to icons, ISTR there is a call to render an icon, so you don't have to create squillions of them. Not suggesting you change because it involves a lot more trouble, you're handling redraws.  I lasted one weekend with RISC OS lib, before finding it was a trap - at that time bugs which Acorn would not fix - they've probably not been fixed yet.

jgh, 28th March 2024, 23:05

I had to have a tooth removed last year. Really weird watching 75kg of dentist a few inches away from you using brute to wrench a lump of dentine out of your mouth.    Surely they would have invented some tool better than a pair of pliars by now. I can picture all sorts of cool clamp and screw systems that I use without thinking in carpentry work.