DeskLib update proposal

Does anybody still use DeskLib?
Does anybody use my version of it? ;-)

Suggestions and comments welcome. While I have (hopefully!) made a 32 bit conversion of v2.30; the library itself is stuck in the era of RISC OS 3.10; so I find myself putting together code to call _kernel_swi() to get a better looking error box. Time for that to change.

Proposed updates to DeskLib 2.30 / RM
=====================================

Note that my version of DeskLib already includes numerous additional
functions; these are updates to bring the library closer to modern day;
and as a result RISC OS 2 support will be dropped as of now.]

My fork of DeskLib v2.30 *predates* the currently maintained v2.80. It
was originally done because the (new mostly forgotten) DeskLib v3.20
changed many many things in a highly incompatible way. It was at this
point that I started expanding v2.30 with some of the fixes and
features in v3.20.

Note, however, that the two versions of DeskLib are going in different
directions. My version will ultimately concentrate on RISC OS 5.xx
facilities, which attempting to run on RISC OS 3.5 or later (possibly
RISC OS 3.10 too, but this is no longer a stated design goal). What I
can promise you is that my version of DeskLib will ALWAYS work with
the DDE. It would appear that "the other branch" ;-) will, in the
future, be GCC only and an ELF library. As ELF is not native to RISC OS,
there will be dependencies. My library? Ought to work on straight plain
regular RISC OS without issue. That's the plan.

There is, obviously, likely to be a growing disparity between some of
the more recent functions. I do not currently know what to do regarding
this. It may be like RISC OS Select vs RISC OS 5 - you choose your
preferred incarnation and stick with it. Certainly, the future pretty
much dictates that if you like gcc you will use the other DeskLib, and
if you like the DDE you'll either use mine or the "probably won't be
updated further" pre-ELF release of DeskLib v2.80.

Thankfully, neither version is GPL so at least we don't have *that*
headache...


Okay. Here's a list of proposed changes. Comments welcome.



Backtrace - merge in modifications present in my server to search for
the backtrace frame *correctly* on StrongARM processors; plus to also
terminate backtracing at main() (as anything prior is within CLib).


ColourTran - support ReadPalette, [Set|Return]FontColours, and
Set[Opp]TextColour.


CPU - [note: this is *low* importance] Extend CPU_ID and CPU_Type to
understand ARMv4+. Add CPU_HALType which will return NULL (no HAL
present) or a composite word describing the hardware, or bit 31
set if a HAL but hardware not identifiable. Update CPU_Class()?


Debug - rename as DebugOld.


Debug (new) - more or less the same thing, but works with DADebug and
is to be included in the main library.


Env (new library for miscellaneous "environment" things): Add all of...
OSgeneric() to return generic OS version (300 - RISC OS 3.xx; 350 - 
3.50 to 3.70; 400 - RISC OS 4 *and* 6 :-P ; 500 - RISC OS 5).
OSversion() to return exact OS version.
WimpVersion() to return Wimp version.
IsModule() returns TRUE if the module specified is presently loaded,
else FALSE.
IsTask() returns TRUE if the specified task is presently running, else
FALSE.
IsHAL() returns TRUE if a HAL version, else FALSE.
PlatformType() returns NULL or a value defining the current platform
type. The platform type is read from the HAL. Older versions of RISC OS
will be NULL; but you can probably make some guesses based upon the
OSversion.
IsPi() returns TRUE if this is a RaspberryPi, else FALSE. [determine by
processor type; as the Pi family keeps getting larger...]
IsVFP() returns TRUE if VFP extensions are present, else FALSE.
IsNEON() returns TRUE if NEON extensions are present, else FALSE.
ReadUID() returns machine unique ID [usu. MAC address on later machines]
DelayMicro() will ask the HAL to delay a specified number of
MICROseconds. Has no effect on non-HAL machines.


Error - add Error_ReportFancy() to support RISC OS 3.5 extended options.
Standard Error_Report will call Error_ReportFancy if running on a
capable machine; the default icon will be an exclamation mark and the
app's icon.
Add Error_ReportWithButtons() to provide buttons other than OK and
Cancel.
Add Error_AskQuestion() to veneer to ReportWithButtons.


Event - remove RISC OS 2 compatibility. Event_Initialise() will perform
a startup suitable for RISC OS 3.10 upwards.
Event_InitCustom() will do the same thing but allow you to specify the
desired Wimp version, such as for the nested WindowManager.
Add Event_PollIdle() to perform the same thing as Event_Poll(), only
with the idle delay.


File - add File_ReadString() to read a [CR]LF terminated string from
the file.
File_WriteString() will call File_WriteBytes() as necessary.
Expand File_CreateDirectory() with File_EnsurePath() which will step
through the path given creating directories until the path is valid.
File_Canonicalise() will convert a file reference to an absolute path,
ie "Choices:Boot" will become something like
"SDFS::RISCOSpi.$.!BOOT.Choices.boot". [actually, this will just call
Filing_CanonicalisePath() ;-)]
File_CanonicaliseAndParse() will determine the full correct path and
also return a struct with a pointer to the start of the filesystem (and
its length), the start of the disc name (and its length), the start of
the path (and length) and the start of the filename (and length).
[to check - File_IsDirectory() behaviour on image files with relevant
FS loaded / not loaded]


Font - ConvertToOS and ConvertToPoints to veneer to existing (mostly in
lowercase for some reason).
Add Font_PaintBlended() and Font_Paint3Blended() to support background
blending. Note that the original Font_Paint() may internally call
Font_Paint3() [so is not going to be RISC OS 2 compatible any more], it
is retained purely because the API is simpler - put this text at this
location, for when no fancy stuff is required.


Font (more) - Add Font_EnumerateCharacters() to allow Unicode
characters to be looked up.
[would it be feasible to do a Font_PaintUTF() which will output in the
current font but if it finds a UTF-8 character that is not supported in
the file, to try to switch to Cyberbit (?or?) to display it [use
Font_ReadDefn to match current font size] (otherwise fall back to '?')?
[does Font_LookupFont return more in R2 nowadays?]


Icon - add ShadeAll(), UnshadeAll, and DeselectAll() as quick ways to
set a known state.


Kbd - [do we need any changes to support extra keys like WinKey?]


Menu - FontMenu[3] and FontMenuDecode[3] will be the same. No more RISC
OS 2 code.
Add Menu_ForceClose() to remove an open menu.


Net - new library; add all of...
Lookup() - convert hostname to IP address.
LaunchURL() - try to start the *http* URL in various ways for various
browsers.
[if OS is RISC OS 5, it will use a simpler system; I recall getting a
URL started with Browse, Fresco, and Oregano could be a bit convoluted]
EncodeURL - given an input consisting of domain and path, it will build
an http compliant URL (including escaping stuff in the path if need be).
Will have an option to select https instead.


Resource - Add ChoicesRead() and ChoicesWrite() to build appropriate
filenames for accessing your choices file based upon "group" name
(given), your application name (assumed), and a leafname (given). If
the input is NULL,NULL then there will be no group, your application
will be the subdir, and the file will be called "Choices".
Will cope correctly with reading from Choices$Dir and writing to
Choices$Write. ;-)


Screen - add ReadModeVariable() to read display information. Add
ReadState() to return a struct giving screen dimensions, colours, etc.


Serial - [check NonZeroPollWord code as it is probably NOT 32 bit safe
due to being entered by word values - fix this]
What sort of level of serial support is present on HAL devices? Can we
talk to the serial port of Beagle or Pi? Can it be handled via this
code? [though, note, these serial ports are Tx/Rx only]


SerialBlk - ? proposal to support serial blockdrivers?


Sprite - duplicate every SpriteOp veneer with "Ptr" suffix to accept a
pointer to a sprite (the current routines expect a sprite name).
Check if MemorySize correctly calculates size requirements for "deep"
sprites.
Modify MemorySize and Create to handle mode specifiers.


Time - ReadClock() to actually read the current system time.
ConvertTimeToOrdinals() to convert a five byte time to a localtime
ordinals block.
ConvertTimeToUTCOrdinals() as above, but UTC time.
ConvertTimeFormats() to convert many to many (more flexible; but RISC
OS 5.20+ only). Returns with -1 if SWI not supported; else returns with
R0 = NULL or pointer to error block.
ReadOffsetFromUTC() to read offset from UTC in centi-seconds; including
daylight savings correction if applicable.


UTF8 - ? Support of UTF-8 may implicate a new library, for things such
as counting characters in a UTF-8 string, working out a byte position
for a given character, and so on.


Wimp - ProcessKey should strip apart UTF-8 codes to send them as
multiples.
Add new functions for enhanced ReportError use.
Add ResizeIcon().
Is it feasible to fix SetCaretPosition() to work correctly on UTF-8
strings?
Look at SetMode() re. mode selector blocks.
Add TextOp().


Window - add IsOpen() to return TRUE if window is open, else FALSE, and
HasFocus() to return TRUE if window has input focus, else FALSE.


Other enhancements?

… so I find myself putting together code to call _kernel_swi() to get a better …

It’s cases like that lead to enhancements in Libraries ;)

From a quick Google (and yes I’ve found your blog) getting into DADebug could be quite useful.

I think the Net(working) additions would be beneficial as well.
Everything from resolving a hostname to – possibly – downloading a small file from the internet.

Also, what’s the licence for DeskLib?

I’ve got plans to get Desk back out there and cherry pick changes from your version, the 3.8 that’s on riscos.info and any other ideas while I’m at it.
But that’s licence depending – of course!

I believe that programs in the GCCSDK autobuilder that use the ChoX11 X11 emulation also use DeskLib (the version at riscos.info).

It would appear that “the other branch” ;-) will, in the future, be GCC only and an ELF library.

It shouldn’t be too difficult to allow DeskLib to be compiled for GCC and the DDE. OSLib manages it.

Why restrict your library to the paid for compiler and not allow people who prefer GCC to be allowed to use it as well? I appreciate you can say the same for DDE with the riscos.info version, but I guess with that, it’s being used mainly for the autobuilder and hasn’t got anyone actively maintaining it (as far as I know).

As ELF is not native to RISC OS, there will be dependencies. My library? Ought to work on straight plain regular RISC OS without issue. That’s the plan.

Not sure about this point. ELF is just a different way of creating libraries, they are linked to work on plain regular RISC OS without issue. Plain regular RISC OS doesn’t come with the DDE either.

If you are making major changes, why not rename the library while you are at it and say it’s a drop in replacement for DeskLib?

they are linked to work on plain regular RISC OS without issue.

Is not a module – not provided in standard with RISC OS – needed to load elf files?

Is not a module – not provided in standard with RISC OS – needed to load elf files?

GCC comes with a program which you can run on your built elf program which converts it to the aof(?) format. Then running the program on RISC OS does not require anything to load elf files as the program is no longer in elf format. It’s how I tend to ship my programs so there are no other dependencies and how most of the autobuilder programs are shipped.

As an aside, the elf loader itself is a module and the basic shared libraries come in a RISC OS style application which includes the module and the C shared libraries. If you wanted to ship you program in elf format, you would need this installed as well. It’s an extra step, but not really difficult.

It’s cases like that lead to enhancements in Libraries ;)

Exactly.

From a quick Google (and yes I’ve found your blog) getting into DADebug could be quite useful.

Even moreso if you find my patched version (search the forum for DADebug) that can periodically output the information to the serial port. A cheap PL2302 clone USB serial interface hooked between Pi and PC and Bob’s your uncle.
(though I want to further hack a version of DADebug to output directly to serial and not buffer stuff)

Everything from resolving a hostname to – possibly – downloading a small file from the internet.

That would be good – but didn’t the Acorn URL module do that? Was URL replaced? If not, how come it isn’t readily available these days?

Also, what’s the licence for DeskLib?

I think the GCC version is an MIT licence.

The version I have is as follows:
The software may be copied and distributed without restriction so long as the following conditions are met:
a) The copyright message and these conditions are distributed intact in all such copies
b) Only original, unaltered copies for this software are to be distributed (so that this library remains consistent over time) -PLEASE DON’T alter the library and pass it on: Alter it and send alterations back to the moderator (see below) so that your code becomes an official update rather than a hack.
c) No profit is made through such distribution.

This software may be used in the production of any piece of software so long as the authors acknowledge in the final product distribution that DeskLib (or parts thereof) was used.

I am ignoring clause 2 because neither Jason Williams nor Julian Smith are actively maintaining DeskLib; it spent a while in limbo.
However, as evidenced by one of my concerns in the original document (up top), there is the problem of growing disparity between versions. I consider mine to be the “purer” given that it is mostly a 32 bitted version of the original 2.30….but then I would say that, wouldn’t I? ;-)

FWIW, I would guess that if the GCC guys were able to sort out all the relevant permissions for making their DeskLib be under the MIT licence, then the same could apply to my version. To be honest, I’m not that fussed about the licence so long as it isn’t GPL, and to that end, if any of my code is later on considered worthy for inclusion into the GCC version, they’re welcome to it.

I’ve got plans to get Desk back out there and cherry pick changes from your version,

Desk or DeskLib? I think Desk was an interesting progression for the library, but it might have been a case of “too many changes”. I remember I tried Desk and it utterly didn’t work (so many naming schemes had changed). I guess the DeskLib programmers were too lazy to change? Hehe, I was. But on the other hand I have never used OSLib in my life so the namespace clash (hazy memory, it was long ago) just didn’t affect me.

It shouldn’t be too difficult to allow DeskLib to be compiled for GCC and the DDE. OSLib manages it.
Why restrict your library to the paid for compiler and not allow people who prefer GCC to be allowed to use it as well?

Hey – don’t look at me!

Quoting from the current DeskLib site:

Current Release: The current version is 3.00, and is ELF-only for use with latest versions of GCC
[…]
Older Releases : The last AOF release, for use with older versions of GCC (3.4.6) and the Castle C/C++ compiler is 2.80:

This implies two things:

1. That further releases of DeskLib will be ELF only.
2. More recent versions of GCC can’t handle AOF.

This suggests that future development of DeskLib over there will make things more difficult for those who are using the official development environment. While I did my (somewhat hacky) 32 bit port of DeskLib in 2004, reading the lines quoted just above is why I have a renewed interest in DeskLib.

I appreciate you can say the same for DDE with the riscos.info version, but I guess with that, it’s being used mainly for the autobuilder and hasn’t got anyone actively maintaining it (as far as I know).

Actually, stuff does change, but at the speed of frozen treacle. My version is no longer the most recent, though I don’t qualify for the free upgrade as I’ve had it more than 6 months (though that 6 month thing is funny, I’ve never seen the DDE updated anything like that often…). Anyway, point is, it is being updated.

Plain regular RISC OS doesn’t come with the DDE either.

Fair point… but on the other hand I wanted to run cmunge to compare its output with CMHG for some deep nerdy thing I was doing regarding module start entry. Thankfully I was able to, but cmunge (along with asasm, elf2aif, and ln) were the only tools in the bin folder that were in a recognised RISC OS format. gcc itself is about 460K of big-question-mark file. It is ELF, because the first word identifies it as such.

And we’re back to this. Different by design. Given the heritage of RISC OS, I might be inclined to say “non standard by design” as well. ;-)

AIF, ALF and AOF are standard. While you don’t get the DDE supplied with RISC OS, that is true, you do get AOF, ALF and AIF documented in the PRM (back of book 4).

If you are making major changes, why not rename the library while you are at it and say it’s a drop in replacement for DeskLib?

Because it is DeskLib. Not a replacement, not a clone. Not something that looks and feels like it but isn’t. It is…It.

David said:

Is not a module – not provided in standard with RISC OS – needed to load elf files?

To which Alan replied:

As an aside, the elf loader itself is a module and the basic shared libraries come in a RISC OS style application which includes the module and the C shared libraries.

In other words, YES. ;-)

It is good to know that ELF programs can be converted to AIF; however I wonder why GCC doesn’t use AIF natively. It has been said a million or so times here – RISC OS is not Linux. I wonder what actual benefits ELF for executables is supposed to bring to RISC OS? Maybe runtime linking, but this surely risks entering into a miniature version of DLL hell? Linux has a patchy track record with respect to ABI compatibility…

Maybe runtime linking, but this surely risks entering into a miniature version of DLL hell?

I have never done any programming outside RISC OS land, but I have always wished for some sort of runtime linking. That is because I keep half an eye open on what is available for Lua by way of useful libraries. All of them are designed for runtime linking. If they are to be available in RISC OS they must be statically linked. This is sad, because Lua has been designed to be lean and minimal. RiscLua has the bc bignumber library built in, for example, but if you are just using Lua for tiny StrongED scripts you are unlikely to be needing it. With runtime linking you can adopt the policy of having lots of specialized tools that fit together. Without it you are stuck with monolithic applications that have to carry stuff you never use.

Wouldn’t it be a good idea to give one of these projects a new name? Don’t know if the license allows that but surely it would be better to avoid a “RISC OS 4/5/6” version number mess. Starting with a new name would solve any version number conflicts that are guaranteed to pop up if they haven’t already.

If they are to be available in RISC OS they must be statically linked. This is sad, because Lua has been designed to be lean and minimal.

Why not look at overlays (in the dde manual) which even use a script interpreter with add on functionality as its example, that way the extra lua bits are only loaded when needed

RiscLua has the bc bignumber library built in, for example, but if you are just using Lua for tiny StrongED scripts you are unlikely to be needing it.

When you write a program with DeskLib, you are extremely unlikely to be including the entire library. This is because the library is broken into tiny little modules, directly related functions go together, but less related things are separate. For instance, the BBC style graphics. The following C files: ReadPoint, Rectangle; and the following assembler files: Clg, GetClip, Plot, SetClip, SetColour, Vdu, Wait, Write0, WriteN.
There may be some dependencies, like Rectangle may call Plot; but if you just wanted “Wait”, then that is the only part that would be included in the final program. Not everything.

I had a rough outline I wrote a long time ago for a very simple BASIC(-like) compiler. It had a code library, but I didn’t think including an entire library with every program would be useful, so the library contained a “core” (startup, shutdown, necessary functions) and a set of function libraries afterwards with an index table pointing to them (you know: one for INKEY, one for CLS, one for VDU) and the compiler was supposed to keep a track of which functions were actually used, and they alone would be included in the final executable.

Maybe you could use a similar method?

Wouldn’t it be a good idea to give one of these projects a new name?

Mine is “DeskLib 2.30/RM” (note the suffix) with the object file “DeskLib32”. If you don’t want my enhanced functions, you can download any version of DeskLib 2.30 for 26 bit machines.
Once I’ve done some more work on it, I will look to see about making a native build for 26 bit (APCS-R for the oldies) as well as a 26/32 neutral (APCS-32) version.

As for version numbering, I will probably suffix “release #” or something like that after the /RM and let it always identify itself as DeskLib v2.30. Because, spiritually, that is exactly what it is. Or maybe DeskLib 2.30 ++ ? ;-)

I have absolutely no objection to yours or any other fork of this excellent project. I’m just thinking of what appears to be a rather “RISC OSy” way of all forks keeping the original name despite the confusion with “versions” and versions that will inevitably arise should more than one of those forks survive for more than a couple of releases.

A clean break might be a better way of “marketing” a particular fork, RickLib (for example) could of course mention that it is a fork from DeskLib 2.30 and could even start with new version 1.00 (or 1.0.0 should you want to go for Semantic versions). That would even make breaking backwards compatibility easier should that be needed.

Why not look at overlays …

Thanks for that, Mike. An excellent suggestion. I had overlooked overlays all these years and they might be just the ticket. Putting the libraries in ResourceFS might be the way to go.

Rick,

It shouldn’t be too difficult to allow DeskLib to be compiled for GCC and the DDE. OSLib manages it. Why restrict your library to the paid for compiler and not allow people who prefer GCC to be allowed to use it as well?

Hey – don’t look at me!

I’m not having a go at you here, the DeskLib on the riscos.info site has gone the ELF route only. I’m not saying that is good. I’m just saying as you are actively maintaining a new version of DeskLib, why not provide a GCC ELF version of the library as well, so users of GCC can use it. It’s entirely up to you of course. Any development of libraries for RISC OS is a good thing.

Plain regular RISC OS doesn’t come with the DDE either.

Fair point… but on the other hand I wanted to run cmunge to compare its output with CMHG for some deep nerdy thing I was doing regarding module start entry. Thankfully I was able to, but cmunge (along with asasm, elf2aif, and ln) were the only tools in the bin folder that were in a recognised RISC OS format. gcc itself is about 460K of big-question-mark file. It is ELF, because the first word identifies it as such.

You seem to be talking about the GCC tools here. I’m talking about the final output program running on RISC OS that doesn’t need any ELF loader. Isn’t that the bit you were complaining about? You don’t expect the DDE to be installed on the end users machines either.

And we’re back to this. Different by design. Given the heritage of RISC OS, I might be inclined to say “non standard by design” as well. ;-)

Sorry, I think I’m missing the point here. Of course it’s different, but that makes it no less capable of producing RISC OS programs that are designed for RISC OS.

AIF, ALF and AOF are standard. While you don’t get the DDE supplied with RISC OS, that is true, you do get AOF, ALF and AIF documented in the PRM (back of book 4).

OK, that’s what you mean by standard. I didn’t realise that all the intermediate formats used by the compiler had to be standard as well.

If you are making major changes, why not rename the library while you are at it and say it’s a drop in replacement for DeskLib?

Because it is DeskLib. Not a replacement, not a clone. Not something that looks and feels like it but isn’t. It is…It.

OK, it was just a suggestion to remove confusion between versions. As you were making changes it seemed it would be easier for you to change, but I wasn’t demanding it.

David said:

Is not a module – not provided in standard with RISC OS – needed to load elf files?

To which Alan replied:

As an aside, the elf loader itself is a module and the basic shared libraries come in a RISC OS style application which includes the module and the C shared libraries.

In other words, YES. ;-)

Why does my aside make it a YES? My main reply was it could build AIF files so the programs don’t need an ELF loader to run on RISC OS.

It is good to know that ELF programs can be converted to AIF; however I wonder why GCC doesn’t use AIF natively. It has been said a million or so times here – RISC OS is not Linux. I wonder what actual benefits ELF for executables is supposed to bring to RISC OS? Maybe runtime linking, but this surely risks entering into a miniature version of DLL hell? Linux has a patchy track record with respect to ABI compatibility…

I’m not a GCCSDK developer, and so can’t really say why they switched to ELF. I think it was something to do with making it easier to port the compiler and associated tools.

Not sure why you are mentioning RISC OS is not Linux. RISC OS isn’t just the BASIC interpreter or a compiler for any other language either. Surely if you say we can’t use ELF format we can’t be allowed to run JavaScript or anything else that was first developed on another machine:-)

GCC is a good compiler and can be used to produce RISC OS programs, designed for RISC OS, that run on RISC OS without any more dependencies than the programs created by the DDE. So why not support the use of it with your library?

Just to be clear – I’m not saying ELF is better than the other formats, or that GCC produces better code. But it gives RISC OS developers a choice of a free compiler that supports some features not supported in the DDE.

But, it’s your choice – if you really hate GCC that much, there’s no need for you to do extra work to support it.

I’m just saying as you are actively maintaining a new version of DeskLib, why not provide a GCC ELF version of the library as well, so users of GCC can use it. It’s entirely up to you of course.

The problem with this is that it would entail setting up and learning an entirely new toolchain. The only time I have ever used GCC was in building firmware for my PVR, and that was from a downloaded archive that had everything set up. I did the hard part – I typed “make”. ;-)
Having said that, the sources of releases will be made available and if somebody more experienced with GCC wants to create a library from that, then I would have no objections merging code modifications (if necessary) back into the main source in order to support both DDE and GCC.

Any development of libraries for RISC OS is a good thing.

Certainly. And IMHO it is important to develop DeskLib just so the world has an alternative to RISC_OSLib. ;-)

Of course it’s different, but that makes it no less capable of producing RISC OS programs that are designed for RISC OS.

It is indeed capable of producing not only ELF programs but RISC OS native. The GCCSDK autobuilder creates plenty of examples.
However, note your comment above “why not provide a GCC ELF version of the library as well”. While it can create RISC OS executables, it no longer seems to want to interact with the library files that have been standard for a quarter century. Perhaps the only thing not making this a weird decision is that a lot of ALF libraries and tools were lost in the 32 bit transition. Prior, there was a lot of library code out there. My “DoorLib”, for instance, simplifies the task of creating doors for ARCbbs (I can’t recall if I supported ARMBBS, I think I did…). It is supplied, like DeskLib, as a library file. The only reason I never bothered to 32 bit it is because the server was never 32 bitted – so it seems a bit pointless… There was also a clever thing that would make BASIC able to output AOF files. ;-)

Is there a tool to convert ALF to ELF? If so, this whole discussion is moot.

I didn’t realise that all the intermediate formats used by the compiler had to be standard as well.

They don’t have to be standard.
A compiler, frankly, can use any format it pleases in between source and executable.
However, the users of said compiler shouldn’t get upset if libraries distributed in one of these intermediate formats doesn’t work with their compiler. AOF and ALF were not designed because Acorn were control freaks, they were designed so that there would be a common standard for everything to work together.
Before I had the DDE, I had C version 4. That was basically the DDE without objasm, for Acorn had this idea that they could sell objasm separately for lots more money. For the times when I needed assembler, I used Nick Roberts’ assembler – which in many ways is better than objasm. Worked perfectly. Why? Because the intermediate format was documented. All these things could interact. There was a linker. And, oh, let’s not forget the “as” assembler too.

As you were making changes it seemed it would be easier for you to change, but I wasn’t demanding it.

I’m not even sure that I could rename the library. Much of it is not my work. I am continuing something created by others…

Surely if you say we can’t use ELF format

I’m not saying you can’t… We can run Lua and perl and all sorts of things that are not part of the “official” RISC OS world. All that is necessary is the software. However, two different pieces of software interacting would benefit from having something in common. If they don’t, then it all gets a bit messy.

we can’t be allowed to run JavaScript

What happens if you double-click on a JavaScript file? :-P

GCC is a good compiler

I believe so.

and can be used to produce RISC OS programs,

Yes.

designed for RISC OS,

I would beg to differ. Ceasing support for one of the common and well documented intermediate file formats is… an interesting decision.

that run on RISC OS without any more dependencies than the programs created by the DDE.

…plus SharedUnixLib? Or is that optional?

So why not support the use of it with your library?

I would like to, and maybe in the longer term it may come to be.

if you really hate GCC that much,

I don’t hate GCC, I just don’t agree with turning their back on the de facto standard file formats. It risks making GCC only compatible with itself (at object code level).

Well – we’ll see how this turns out in the future.

I won’t be doing anything on it right now. Too hot. My netbook has its fan hardwired to run at 100%, along with a dual fan cooler widget underneath, and even then it is running at ~65C. There’s a desk fan pointed at my face, and I’m hopefully running at 37C. The Pi has no cooling, and I don’t plan to give it a reason why it might want some. It is hot. Hot enough to cause important electric transformers to overheat and blow up → http://www.ouest-france.fr/coupure-electrique-de-grosses-coupures-en-bretagne-et-pays-de-la-loire-3524643

Is there a tool to convert ALF to ELF?

I was under the impression that ELF stored more data than ALF, so that ELF → ALF was
possible but not ALF → ELF. I would be happy to be corrected.

There’s a desk fan pointed at my face, and I’m hopefully running at 37C.

Which reminds me – I need to connect to work and find out if the comms rooms are back below 32C
Not ALL of them you understand, only 10 out of 22 were cooking when I came home.¹

Yes, there is air-con; no, it isn’t really making the grade.

The Pi has no cooling, and I don’t plan to give it a reason why it might want some.

RPCEmu on the laptop is warming it up a bit…

¹ My office however was at a nice 22C. If it wasn’t some people might find bits round their offices not talking on my network.

Rick,

Thanks for clarifying things for me.

I’m just saying as you are actively maintaining a new version of DeskLib, why not provide a GCC ELF version of the library as well, so users of GCC can use it. It’s entirely up to you of course.

The problem with this is that it would entail setting up and learning an entirely new toolchain. The only time I have ever used GCC was in building firmware for my PVR, and that was from a downloaded archive that had everything set up. I did the hard part – I typed “make”. ;-)
bq. Having said that, the sources of releases will be made available and if somebody more experienced with GCC wants to create a library from that, then I would have no objections merging code modifications (if necessary) back into the main source in order to support both DDE and GCC.

That’s an entirely reasonable approach. I’d rather you concentrated on the library rather than having to learn a new tool. If the developers existed with the time on their hands it would be nice if we could have both.

However, note your comment above “why not provide a GCC ELF version of the library as well”. While it can create RISC OS executables, it no longer seems to want to interact with the library files that have been standard for a quarter century. Perhaps the only thing not making this a weird decision is that a lot of ALF libraries and tools were lost in the 32 bit transition. Prior, there was a lot of library code out there. My “DoorLib”, for instance, simplifies the task of creating doors for ARCbbs (I can’t recall if I supported ARMBBS, I think I did…). It is supplied, like DeskLib, as a library file. The only reason I never bothered to 32 bit it is because the server was never 32 bitted – so it seems a bit pointless… There was also a clever thing that would make BASIC able to output AOF files. ;-)

OK, I see your point here. But we shouldn’t just stick to something because it’s been around a while. Maybe ELF is better for some reason. I’m assuming the GCCSDK developers were smart enough to think this through and judged the gains outweighed the losses. Even if ELF in itself isn’t better, it could be that by using that format mean the porting process is quicker and easier and allows RISC OS to have a modern free compiler that’s easier for them to maintain.

I’m not even sure that I could rename the library. Much of it is not my work. I am continuing something created by others…

Fair enough. It’s a pity you can’t update the riscos info version with your new stuff, so we got back to just one version, but I understand that version went off in a different direction anyway regardless of it’s use of ELF format.

designed for RISC OS,

I would beg to differ. Ceasing support for one of the common and well documented intermediate file formats is… an interesting decision.

I was talking about the final output program being designed for RISC OS. I still don’t believe GCC should be restricted to having to use the same intermediate formats as the DDE. I do agree it would be helpful if it did though.

…plus SharedUnixLib? Or is that optional?

Not sure. If you link to UnixLib you definitely need the SharedUnixLib as well, but I thought you could use GCC to link to the RISC OS C library and then you didn’t need it. I could be wrong though. I thought we were talking about what the ELF format needed, the SharedUnixLib was needed by GCC linked to UnixLib before they moved to ELF format.

that run on RISC OS without any more dependencies than the programs created by the DDE.

…plus SharedUnixLib? Or is that optional?

SharedUnixLib is required if you use UnixLib; it has nothing to do with the compiler. All of my software is compiled using GCCSDK (and goes via ELF object files on the way to AIF), but none requires SharedUnixLib as I link to the SharedCLibrary stubs and not UnixLib.

But we shouldn’t just stick to something because it’s been around a while. Maybe ELF is better for some reason. I’m assuming the GCCSDK developers were smart enough to think this through and judged the gains outweighed the losses. Even if ELF in itself isn’t better, it could be that by using that format mean the porting process is quicker and easier and allows RISC OS to have a modern free compiler that’s easier for them to maintain.

I believe the last point was a key consideration: you can see a discussion of the issues written by Peter Naulls back in 2004 on Drobe at http://www.drobe.co.uk/riscos/artifact1236.html

The key point here is that having to maintain RISC OS-specific back-end tools for a compiler that’s already perfectly capable of generating ARM code is massively wasteful in terms of developer resource when all that you actually need is a bunch of off-the-shelf tools that work with the standard ELF format and an unchanging elf2aif tool to convert the end result into something more familiar to RISC OS.

The only real downside is the existence of libraries which are only distributed in ALF format (something that Rick seems keen to perpetuate with his new DeskLib). In practice I’ve never really found this to be a problem in around 15 years of using GCC; if you’re using the DDE libraries, you’re probably using Norcroft anyway.

I’m not sure that there’s any excuse for current developers refusing to build ELF versions of their libraries. The bigger problem is actually going the other way: a GCC-using developer would need to fork out for the DDE to be able to generate ALF versions of any libraries that they wrote.

The only real downside is the existence of libraries which are only distributed in ALF format

As opposed to the other DeskLib moving to ELF only so that it cannot be used with the “official” (as in “used to be Acorn”) tools?

(something that Rick seems keen to perpetuate with his new DeskLib).

Wow. So supporting the ROOL toolchain is a “bad thing” now?

I’m not sure that there’s any excuse for current developers refusing to build ELF versions of their libraries.

I can give you two immediately:

1. I don’t have GCC installed.
2. Even if I did (which isn’t hard, it’s packaged), I don’t feel confident enough to use a toolchain I’ve not used before in order to produce libraries.
Moreso, libaries with… A full count of the source directory gives 1,445 files. If we divide by three to omit all of the ‘o’ files and count a generous third for the other stuff (like static library, makefiles, etc); this means there are around 500 actual source files, some 50-odd individual MakeFiles and chunks of library to be combined to make the final “DeskLib”.
I wrote some helper programs (straight BASIC) so the library building is now simpler than it was; but I’d like to rationalise this more by having a program that can generate all the MakeFiles too). I think I will probably discard all of the DLL stuff unless somebody pipes up that they’re actually using it.
To think of doing this under GCC… I wouldn’t know where to start.

a GCC-using developer would need to fork out for the DDE to be able to generate ALF versions of any libraries that they wrote.

Or for somebody to make an ELF2ALF tool?

I’m writing this on the Pi today. I’m going to look at some parts of DeskLib – and specifically fix the low level serial port code – I’m kind of embarrassed that that got through; plus check that all of the 32 bit assembler has build options for 32 bit or 26 bit behaviour so it will still be possible to make an APCS-R build. [looks: damn, no, it’s straight 32 bit style code – but most of it will need to be changed anyway as LDMFD sp!, {pc} is just yucky]

As for GCC – would anybody familiar with GCC like to volunteer to help get this working?

Got a little sidetracked with the build process. The current (my revised) method works, but it is a bit messy. So I have decided to write a front-end program that will start when you click on !DLSources that will allow you to select a target (in the future, so RISC OS APCS and GCC will be a click away), the program will then be able to remove all of the object files for a full build, plus verify that the MakeFiles are correct. Once that has been done, a custom build script will be constructed (at runtime) to get the build going.

Inspiration, obviously, from RISC OS’s !Builder. But looking at the build process, I thought to myself why isn’t this stuff clicky-clicky too?

Unlike the original build helper tools, this will be supplied with all sources. ;-)

Inspiration, obviously, from RISC OS’s !Builder. But looking at the build process, I thought to myself why isn’t this stuff clicky-clicky too?

There’s a good reason (in general): as the amount of software gets larger, clicky processes don’t scale. If you have a hundred libraries to build (I forget how many RISC OS Firefox needs, it’s in the dozens), it gets very tedious to do it clicky one by one.
Back in the day you could download any source code, type ‘make’ and you would be done. To some extent that also worked cross-platform too. Unfortunately it isn’t quite as simple as that any more, and typically another layer is needed on top of make (autotools, cmake, ninja, debian/rules).
Even so, every idiosyncratic build process makes the code more complicated to work on for third parties because, not only do you have to understand what the code is doing, you have to unpick the build process too (especially if it’s failing for some non-obvious reason). The simpler you make it for third-parties the more likely you are to receive code contributions.
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.

So I’d suggest just keeping the build to plain Makefiles, no fancy stuff. Makefiles are possible to make cross-platform too (for cross compiling and for porting to other platforms), in the way that piles of Obey files or BASIC programs aren’t. You can pass parameters to Makefiles to select targets etc, they’re quite flexible (if a little arcane at times).
(amu is also a pretty backward implementation of make, but GNU make can be used with the Norcroft tools).

I’m in principle happy to advise with the GCC side – a bit busy at the moment, but prod me repeatedly by email and I might have a chance to give it a go.

Am I correct in thinking that ELF is industry standard and ALF is confined to RISC OS?

Am I correct in thinking that ELF is industry standard and ALF is confined to RISC OS?

Correct.

There is actually some limited ELF support in Norcroft, but I don’t think it’s enough to allow it to be used end-to-end like with GCC.