DeskLib update proposal

So the ideal solution would be to abandon ALF and use exclusively ELF, adding appropriate ELF support to Norcroft?

Am I correct in thinking that ELF is industry standard

Depends how you define “industry standard”. Linux and derived use it, Windows doesn’t. I think I read somewhere that Android is dropping it from v5 to use its own format.

Certainly it is one of the most capable formats around, and the FatELF (?) version to allow executables for multiple types of machine in one file is an interesting idea too.

So the ideal solution would be to abandon ALF and use exclusively ELF

I’m a fan of the Norcroft / ROOL compiler. It really doesn’t bother me how the files go from source to executable – AOF/ALF, ELF, magic cat girls with felt tip pens, it doesn’t matter – so long as it works.

ELF support directly in RISC OS would be nice too. There are enough systems supporting it that we ought to be able to find some code that isn’t tainted with GPL; though from a cursory read of the format header in wiki, it doesn’t look hard to implement. RISC OS would likely ignore most of the stuff and just check it is for the right architecture, the right type (not a library!), and loads in a sensible place.
Not quite sure how ELF would handle stuff like runtime compression or the zero init and relocation stuff provided by AIF, maybe that is somewhere in the ELF program header?

RISC OS is historically bad at build processes (just look at the amount of effort it took to recompile apps for 32 bit/ARMv7) and it needs to get better otherwise the next change will be equivalently painful.

I wrote that yesterday with a degree of hypotheticality, wondering if there was likely to be an architectural change any time soon that might require recompiling. And then today Jeffrey announced changes related to null pointers and unaligned loads: not quite a major architectural change, but people are going to have to warm up their compilers again – if not for everything, for software where fixes are required. Seems like, sooner or later, any software will need recompiling.

Seems like, sooner or later, any broken software will need recompiling.

There. Fixed that for you.

(^_^)

“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now.” ;-)

Of course I’m saying that as someone who probably has to recompile a lot of the code that’s on his website.

Also, it’s ironic how it was Theo who started that thread!

50 of your Earth years,

Technically, rabbit years.

Also, it’s ironic how it was Theo who started that thread!

The first person to see the tidal wave¹ coming. The benefit of better foresight?
Or was he merely the first to speak?

¹ OK, probably more like a pond ripple.

This is not an “official” release, just here in case anybody wants to play.
It has had very little testing (rebuilding my server, plus the example programs – that much can be seen to work).

http://www.heyrick.co.uk/random/DeskLib32-rm_20150709,ffd
(rename it DeskLib32, put it in !DeskLib.o, link with it…)

What’s new:

• Most of the (many) build-time warnings have gone; the library now builds with only a few warnings regarding using PC in STM is deprecated, but since that code is building an APCS stack frame…
• Library is now built to be optimised for an ARM11 processor (the Pi), but to use instructions supporting back to ARMv3 (RiscPC era, but note that this library currently requires a 32 bit OS).
• Serial pollword code fixed.

DeskLib status and stuff – I’ve put up a naff page here: http://www.heyrick.co.uk/desklib/

There’s a bunch of updates to DeskLib. To save cluttering up the forum with things that aren’t pictures of kittens :-P you can find the details, plus a non-official release of the library and new header files, at:

http://www.heyrick.co.uk/desklib/

PS: Please let me know if you use DeskLib, and if you have any ideas for it.

Out of idle curiosity (honest!), does the RM version of DeskLib described here build in a vanilla DDE using Amu, or is it relying on GCC’s Make to do the hard stuff? So far, despite an evening’s archaeology, I can’t find a version of the source that I can point at an unaltered Norcroft and get a binary out the other end.

does the RM version of DeskLib described here build in a vanilla DDE using Amu,

Yes. I don’t do GCC.

There’s a program invoked by an Obey file (BuildIt? something like that) that works out what needs done and starts up a TaskWindow, blah blah just run it and leave it for a few minutes. ;-)

Yes. I don’t do GCC.

I hadn’t noticed. :-)

There’s a program invoked by an Obey file (BuildIt? something like that) that works out what needs done and starts up a TaskWindow

I guess these are the “slightly unstable tools” that the developers “didn’t have source for” which are referred to in the DeskLib 2.50 build notes?

Are these versions of the DeskLib source still available anywhere online? RISCOS.info only goes back to 2.50, and all of the other references to DeskLib that I can find in the likes of Uni-Stuttgart turn out to be Desk.

ETA. I should clarify: I’m not really interested in the vintage DeskLib sources (beyond how they were structured on disc, I suppose). What interests me is how it built on vanilla DDE, and whether that could still work today with unmodified versions of the latest sources.

blah blah just run it and leave it for a few minutes.

“Few minutes”? The whole of the latest Desklib (ie. the one from RISCOS.info’s SVN) builds in around 10 seconds here. :-)

I guess these are the “slightly unstable tools” that the developers “didn’t have source for”

Oh, those. I dunno. I threw all that crap away when I save the AIF headers began with four BLX instructions. Clearly not something that’ll run on my machine!

Are these versions of the DeskLib source still available anywhere online?

You’ll find my stuff at http://heyrick.ddns.net/desklib/ (if it gives you a 404, you need the final /).
I’ve put together an installation archive and a source archive. I’ve not tested the source one, it should build. Let me know if I’ve forgotten anything. ;-)

What interests me is how it built on vanilla DDE, and whether that could still work today with unmodified versions of the latest sources.

Yes/No/Maybe. It is possible to build them on vanilla DDE. It’s what I use to build mine. But I redid the entire build mechanism with a few BASIC programs and Obey files, because depending upon compiled programs that were 26 bit and had no source? A total non-starter!

As for unmodified versions of the latest sources, I see only three issues:

1. You’ll need to add entries into the relevant MakeFiles for each bit of source, if it is new and wasn’t there before (I’ve not automated this, I decided that writing a program to do it would take longer than just doing it manually when necessary).
2. You might need to bodge all the filenames if they come out like source/s or something.
3. Fixing up any use of pragmas, constructs, symbols, or pseudo-instructions supported on GCC but not DDE.

Other than that, I don’t see why it shouldn’t work.

I’m guessing you’re interested in having a DDE compatible version of the latest DeskLib?

“Few minutes”?

Pi2, bog standard class 10 µSD card. It takes a few minutes.

builds in around 10 seconds here. :-)

Yup, and my 2.4GHz Pentium4 PC (running XP) can unpack the entire RISC OS sources to disc in about fifteen seconds. It’s just a shame it makes such an unbelievable mess that it can’t be used on RISC OS (my Pi takes considerably longer than 15 seconds to unpack the sources; hell we’re looking at several of minutes just to unpack the tar never mind extract any files from it!).

RISCOS.info only goes back to 2.50, and all of the other references to DeskLib that I can find in the likes of Uni-Stuttgart turn out to be Desk.

Helps to Google with the version number – it turned up this: http://qubeserver.com/Qube/qubeftp.php?dir=%2FFTP%20Mirrors%2FHENSA%2FPROGRAMMING/DESKLIB

I’ve put together an installation archive and a source archive.

Thanks; I’ve downloaded it, and will take a look at some point.

I’m guessing you’re interested in having a DDE compatible version of the latest DeskLib?

Not really¹.

As you might have seen in csap, I’m trying to get the WinEd sources to build, using the supposedly preferred platform of the GCCSDK (which I happen to have in regular use, hence making this look like a simple task). I’ve been hampered by the fact that despite the claims in the documentation, the current DeskLib from SVN doesn’t actually appear to work in the GCCSDK because the header files that it installs for things to include are expecting <DeskLib$Path> to be present and the compiler to understand RISC OS path variables².

If I’m going to be patching things and feeding them back, I’d prefer to do it in a way that is least invasive for future DDE compatibility. Developing a library in the GCCSDK but having “make dde” spit out a folder containing a set of files that DDE would be at home with isn’t impossible³, and even if I don’t plan to fix DeskLib in this regard, I’m not happy submitting changes that would take it further away from that point. However, it means that I do need to know what a DDE-friendly DeskLib looks like.

¹ Although part of me is wondering if the the quicker route to my actual aim might be a DDE version of DeskLib, dropping the WinEd sources into a modern DDE application project, and pretending that I never read the “compiling WinEd” document.

² Which it does, kind-of, but not in a way that’s helpful here.

³ SFLib does exactly this, which is why you can download both ELF and AOF versions with the header files in different arrangements depending on the target.

OK, I admit, I haven’t been giving full attention to the postings about Desklib and Desk over the last few years.

So what’s the state of either of them now? And where are the most recent versions?

It would be nice to be able to use an up-to-date library, with DDE. (I very much went off gcc some years ago, and I have kept my DDE up to date.) Even if it means having to build the library with DDE. I remember doing it years ago, when it used to take significant time.