DeskLib32/RM

In case anybody is a user of DeskLib, I have revamped and rebuilt my “fork”¹ of DeskLib 2.30 to work on the newer 32 bit hardware. I had already done this, like a decade ago (give or take a few years), but the compiler I was using then did some unpleasant things which fail on the ARM9 and later. This should now be okay; and indeed a simple test program built with the new version worked without problem.

desklib32-rm-20130720 (1.9MiB zip)
Note that this build has only had light testing at this time.

What’s in the file: The archive above is a snapshot of my version, so it contains everything except the examples and docs. “DeskLib:o.DeskLib” is the original (26 bit) version. Do not use this. Use “DeskLib:o.DeskLib32”.

How to use it: If you already have DeskLib, then you can make use of this by moving your one out of the way, putting this in its place, and tweaking your makefiles to point to DeskLib32.

If you are an end user (you don’t plan to mess with DeskLib’s source code), you can delete the !DLSources directory and its many many contents. Really, !DeskLib is all you need.

How to build: The original build script system is really complicated, and thanks to using a number of tools without sources, is also really broken. It will crash on anything that isn’t 26 bit PC.
Thankfully, I threw together a couple of really simple BASIC programs to build TaskObey files and call them. So all you need to do is run the “build_desklib” Obey file.

Extensions: [note – these are contemporary with the time they were done, roughly 1999-2001]

BackTrace (new)
Back-ported from DeskLib 3.20. You probably should not use this as it may do some stuff in a 26 bit way… I’ll check/fix this soon (soon=some day).

Window
Added Window_Open (smarter than Window_Show), Window_ShowCentred and Window_ShowWherever.

There are, no doubt, a huge heap of things necessary to support later than RISC OS 3.5, the modern SoCs, the RO5 HAL, etc etc.

Your suggestions are welcome!

¹ It was never my intention of creating a fork, I was simply tweaking DeskLib to work on newer hardware because nobody else seemed to be doing it. In my time away from the wired world (2002-2009), others have stepped up to expand DeskLib; however I am planning on maintaining my own fork because…
…well…
…this line should say it all: The next major release of DeskLib will be version 3.0 and will be ELF-based, requiring GCC 4.×.
ELF isn’t a native RISC OS file type, and if I have a perfectly functionable development toolkit set up, I don’t really want to set up another one alongside. I do not disagree with the move to GCC, I’m just saying it isn’t for me. For those with the Norcroft/Acorn/Castle/ROOL toolset: The last AOF release, for use with older versions of GCC (3.4.6) and the Castle C/C++ compiler is 2.80.
Unless you prefer to help my ‘fork’ and keep DeskLib going on the original setup, that is! ;-)
[see also: http://www.riscos.info/index.php/DeskLib]

As I understand, it works with DDE/Norcroft…

Yes. It is an ALF (library), just add it to the command line parameters passed to link (alongside Stubs and any other libraries like TCPIPLibs).

Or did you mean the other one? ;-) Yes, that works with the DDE as well but if you read the website, future versions won’t. This has already been discussed on the forum, searching for “ELF” ought to find some posts…

ELF isn’t a native RISC OS file type, and if I have a perfectly functionable development toolkit set up, I don’t really want to set up another one alongside.

Are you absolutely sure that this isn’t FUD?

In response to a related enquiry that I made elsewhere, someone who ought to know suggested that Norcroft’s linker is supposed to be able to handle “AOF-equivalent”¹ ELF object files alongside AOF. I haven’t actually experimented yet, and there was a hint that it might have worked once but may not any more, but if correct it suggests that you might be getting all righteously indignant over a non-problem…

;-)

¹ As in ELF files that contain data that can be converted into AOF files.