Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Alternative Shared C Library in development

By Chris Williams. Published: 18th Mar 2006, 01:05:49 | Permalink | Printable

The hare and tortoise face new competition

32bit motifAn alternative Shared C Library module suitable for both A9 and Iyonix users is currently in development by an independent programmer. Graham Shaw, also known for his work on RiscPkg, has confirmed that he is preparing a 26/32bit neutral C99 supported SCL. The project is separate to Castle and RISCOS Ltd's efforts to maintain their own streams of the module.

He said: "I'm able to run quite a few command-line programs [built with it] now - for example, ping and decaof."

Much of the library's functionality requires testing, according to Graham, who also recently drafted updates for the RISC OS port of the GCC compiler package to aid in the creation of a SCL module.

He added: "Initially I'll be testing against the Iyonix and A9. Older systems, and Aemulor, will be supported eventually, but probably only back as far as the ARM6.

"Note that while the A9 was obviously a consideration in writing this module, it is not really my primary motivation: I could solve that problem much more easily by buying the latest compiler, or probably just by waiting. I'm much more interested in what can be done with the SCL once it is ours to play with, although some care will certainly be needed."

The SCL is a core operating system component that provides applications with a fundamental level of functionality, and both Castle and RISCOS Ltd each provide a flavour of the module to end users. Castle's publicly available SCL is compatible with computers running a non-32 bit RISC OS, such as RiscPCs; Iyonix machines ship with a suitable module included in RISC OS 5. This means software built for the Castle SCL will not appear to work on 32bit RISC OS 4, as found on the A9home. RISCOS Ltd and AdvantageSix, the latter of whom manufacture the selectively available A9home, have yet to announce their plans to release a new so-called C99 capable Shared C Library module that may well be compatible with future streams RISC OS 4 and 5; likewise for Castle, who say they will release "an appropriate Shared C Library when the A9 is a formal product".

RISCOS Ltd are believed to be gaining ground in terms of developers using their StubsG library, which allows software to use either the Castle or RISCOS Ltd SCL. However unlike the current ROL SCL, the Castle SCL also provides C99 functions, which some applications require, and it's understood that ROL have added C99 support to their SCL in preparation for the release of Select 4 later this year.

Although some developers have questioned whether or not creating an alternative Shared C Library is worth the time and effort required, a lot of the source code involved can be pulled in from other projects: for example, from the GCCSDK's UnixLib component. In the midst of the debate over whether or not RISC OS should be made open source, it was suggested late last year that components such as the SCL are ideal to be made open source for all developers to get involved in, even if this means producing a new one mostly from scratch.


What's a standard C library?
What's the deal with two streams of the SCL module? Send us news

Previous: RiscPC emulator ported to Linux
Next: Inside an unofficial Shared C Library


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Good news and bad news in one: 1. Good that this issue is being addressed and perhaps the new library will then even be happy with other compilers and as time passes by join the CLib and UnixLib in one? 2. Bad news since I hoped that the issues as for the A9 to be a formal product were solved by now.

 is a RISC OS Userhzn on 18/3/06 8:38AM
[ Reply | Permalink | Report ]

As already discussed in the comments of "Investing in RISCOS Ltd..." poll, this news really brings sadness. Quoting the above news: "The SCL is a core operating system component that provides applications with a fundamental level of functionality"

This means there's such a mess in RiscOS world that such an important componet is being developed by.... an INDIPENDENT PROGRAMMER. Hail :) to Graham, but how could an OS pretend to fight market when it's all about an indipendent programmer??? Ofcourse, add all the points we did raise in the poll discussion.

This is taking us nowhere. Really. Little OS, barely known, no real HW supporting it, and now we must rely on a private progammer to have somethign working. This sounds bad, really bad.

 is a RISC OS Usernodoubt73 on 18/3/06 9:53AM
[ Reply | Permalink | Report ]

Well I guess that an independent programmer like Graham may give RISC OS a 1% chance which is better than zero.... or a minus number factor :-(

While there may be so so many things that Windows can do that RISC OS can not do these days, I have recently come to the conclusion that there are still lots of good points about my old 1994 RiscPC 600 with RISC OS 4 that are really good.

My recent conclusions resulted from some of my dumb questions about PC to my IT teacher to make it work like RISC OS. Yes, I not kidding how dumb but the answers were no, no no.... impossible or not really the way to do it!

One question was, can I stop my laptop PC from that stupid shutdown where it writes back my settings to the hard disk.

My RISC OS does not do that and it is annoying on the PC when I make errors and it save all those wrong settings.

My IT teacher says it can't be done, Windows must save all your changed settings (even if they were an error! I asked) or you will lose them.

But I rarely ever want to change the desktop of style settings, if I do I like to manually change that one or two just like I do on RISC OS.

Well, I got nowhere with that one. Does anyone out there know the answer or has a solution to stop Windows from messing me up on that?


 is a RISC OS UserSawadee on 18/3/06 10:28AM
[ Reply | Permalink | Report ]

nodoubt73:"This sounds bad, really bad" I disagree. What's the problem with the development of an open-source alternative to a module? If it's successful the OS developers can concentrate on other areas and it might even lead to new functionality as Graham hints at above.

I really fail to see the problem. In fact, re-reading your post, I'm not even sure how to properly respond to you since apart from shouting about "independant" programmers (so what?) I can't make out what your arguments are.


 is a RISC OS Useradamr on 18/3/06 10:36AM
[ Reply | Permalink | Report ]

Great though it is to see Garham taking up doing a new SCL, I tend to agree with NoDoubt73 on this one.

What we need is consolidation of RISCOS not yet more fragmentation. ROL and Castle should really get this sorted out starting with the release of a common SCL and Toolbox set that is used by ALL version sof RISCOS.

The release of the A9 and Select4 should be the start of this consolidation.

 is a RISC OS Userbluenose on 18/3/06 10:52AM
[ Reply | Permalink | Report ]

In reply to nodoubt73:

By your reasoning the UNIX-compatible market should be in a far worse state than RISC OS. Not only have most of their users deserted the official C library for glibc, they went and replaced the rest of the OS too.

In reply to bluenose:

Fragmentation is an issue which I am very much aware of, which is why any changes to the interface have to be very carefully thought through.

A good example of what I have in mind is better cooperation between the SCL and UnixLib when a program using one calls a program using the other. This doesn't break the documented interface, and is much more likely to fix undesirable behaviour than to cause it.

The having several implemtations of the SCL is not a problem. Having different interfaces is.

 is a RISC OS Usergdshaw on 18/3/06 11:26AM
[ Reply | Permalink | Report ]

I don't see what the fuss about. Sure, technically it's duplication of effort, but if it leads towards a more open RISC OS this can only be a good thing.

 is a RISC OS UserCogs on 18/3/06 12:50PM
[ Reply | Permalink | Report ]

Cogs: Only because the people who are supposed to be moving it on don't always seem to be getting on with that.

 is a RISC OS UserSimonC on 18/3/06 3:34PM
[ Reply | Permalink | Report ]

The big problem with having two Shared C Libraries is you can't have both installed at the same time. If some things require the RISC OS Ltd one and some things require the Castle one you have a problem. This isn't such a problem with Linux (and to some extent Windows), as you can have different version of the same library installed.

 is a RISC OS Usercmj on 18/3/06 5:51PM
[ Reply | Permalink | Report ]

In reply to most and especially to cmj: I think your did put your finger into the interesting issue: RISC OS does not allow for different Shared C Libraries in use at the same time as is easy in Linux. Adding to this the fact that there are two of them around, both are official by OS suppliers and the two suppliers seem to not want to co-operate. Perhaps this could work: Write a CLib loader for the ROL and the CTL CLib which replaces the SWI bases and Module names thus allowing both to be loaded and a new CLib module which is a wrapper for both.

Thus I applaud Grahams intention and I hope that his library will be happy to work with all three Stubs, i.e. the ROL one, the CTL one and with StubsG. Pity this is necessary due to the A9home not considered to be a valid product.

 is a RISC OS Userhzn on 18/3/06 6:46PM
[ Reply | Permalink | Report ]

Have I missed something.

In an earlier Drobe article, dated 18th Jan 2006, Castle's John Ballance stated:-

"that when the A9 is a formal product Castle will be happy to release an appropriate SharedCLibrary".

If this course is not followed, surely all applications will have to be written to check which of the three SCL modules is installed and have separate code to be used for each.

 is a RISC OS Userajb on 18/3/06 7:27PM
[ Reply | Permalink | Report ]

ajb:"Have I missed something" Yes ;)

With regards the Castle statement, Graham says specifically in the article above that that is *not* the reason he's developing an open source CLib.

Your second point is also way out. If the APIs are the same, then the applications which use the module needn't care which module is loaded. This is already the case on a RiscPC where most applications work quite happily regardless of whether the Castle or ROL module is present.


 is a RISC OS Useradamr on 18/3/06 10:56PM
[ Reply | Permalink | Report ]

*In reply to adamr:*

I agree with what your comments say, no problems with extra help.

The extra help no matter if it is big or small Graham still contributes to free up programmers for other much needed work.

This is the sarcasm I mean by my comment "1% is better than zero..." otherwise without and support we are in the "MINUS %"?

While Windows is ahead in many ways, RISC OS still has it's unique difference that is "peace of mind" to the user, it just need a lot of catch up.

I don't think that I would like to see RISC OS become too like Windows (style guide wise), just be able to do anything you need it to do is all we need.


 is a RISC OS UserSawadee on 19/3/06 1:46AM
[ Reply | Permalink | Report ]

"just be able to do anything you need it to do is all we need"

That would require more powerful hardware (to do nice things with DVDs and audio), some expensive software licencing (for things like a Flash player and Java virtual machine) and a concerted effort by developers to develop software to plug the gaps (of which there are many). I don't think it's going to happen...

 is a RISC OS Userarenaman on 19/3/06 12:44PM
[ Reply | Permalink | Report ]


1) Any implementation following the Castle 32bit SCL pattern is full compatible with all correctly written programs linked against the new 32bit/C99 stubs, the old 26bit/C90 stubs, and ROL's intermediate C90 stubsG used in 26bit or 32bit modes.

2) It is ridiculous this has become necessary to support the A9, all three parties involved need putting in a room and given a good kicking until the correct licences are sorted out, and an officially supported 26/32bit C90/C99 SCL is released for all RISC OS machines.

3) An open source implementation of the SCL would still be useful in some other ways so it wouldn't be a complete waste of time even if the official version gets sorted out. For example easier debugging of callback based code, and also to allow core SCL functions to be performed natively on emulators.

 is a RISC OS Userdruck on 20/3/06 9:36AM
[ Reply | Permalink | Report ]

arenaman: In the case of DVDs isn't more a case of being able to access the hardware we already have (in the Iyonix, at least), rather than needing more powerful hardware? Most other platforms don't have to rely on it all being done in software.

 is a RISC OS UserSimonC on 20/3/06 10:10AM
[ Reply | Permalink | Report ]

adamr: "bla bla bla ....shouting about "independant" programmers (so what?) I can't make out what your arguments are."

As I stated, I was connecting back to the interesting thread after the poll *Investing in RISCOS Ltd*, a poll you didn't post a single line and probably missed (?). I've nothing against this programmer developping something. It's ok. But Where is RiscOS going if one of the most important libraries are not clearly supported by a real company? All written above (when replies go over unix topic, the fact that riscos allows to "switch" between more than one SCL easily....) is correct and I agree. And even like it, just because I use RiscOS for fun, I use RiscOs because I like it and am interested in computers. But when we pretend to have an OS that should placed by the side of Win or Mac, how could we stand these facts? I mean, Mr.User will ever be able to switch between different SCL? It's all ok, if *WE* use RiscOS. But RiscOS market won't get out of where it is stuck now. That was my point.

 is a RISC OS Usernodoubt73 on 20/3/06 1:55PM
[ Reply | Permalink | Report ]

nodoubt73: I repeat; there is no need to ever switch between SCLs, when a 32bit-C99 and 26/32bit-C90 SCL is available. The RISC OS way is to have a single active copy of a module, which if introducing new features must maintain backwards compatibility. This avoids the situations on other platforms where half a dozen mutually incompatible versions of the same shared library must be loaded by different applications.

 is a RISC OS Userdruck on 20/3/06 4:43PM
[ Reply | Permalink | Report ]

In reply to nodoubt73:

I may not be a real company, but I am a real person.

In any case, anyone can support a program once it has been released as open source. Surely that is better than being dependent on a single company?

 is a RISC OS Usergdshaw on 20/3/06 5:30PM
[ Reply | Permalink | Report ]

gdshaw: I may not be a real company, but I am a real person. In any case, anyone can support a program once it......

I know you're a real person. The problem is that RiscOs exists "thanks" to real companies. I'd be the 1st one going for an open source riscos. The problem we have is that there are coupla companies out there that should do things like the one you're doing... or, at least, should pay you for that. I repeat: it's ok for me. Write what you want and even send it to me so I'll be another tester for your work. This is fine. Let's re-write every single library and modulee. I am fine with that. But then we should stop all those topics about RiscOS vs others OS, on a matter of market share. Let's stop with everything. Ah, we should even start building our own hardware at home :)

 is a RISC OS Usernodoubt73 on 21/3/06 7:36AM
[ Reply | Permalink | Report ]

In reply to nodoubt73:

I have full confidence that ROL and/or CTL will resolve the Shared C Library issue by the time the A9 becomes a fully released product. At most this project it a bit of friendly competition.

What I presume they won't be doing is releasing the source code to their versions, and that's where I can make a difference.

 is a RISC OS Usergdshaw on 21/3/06 11:30AM
[ Reply | Permalink | Report ]


well, good luck ;)

 is a RISC OS Usernodoubt73 on 21/3/06 3:27PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Drobe talks to the organisers of Codecraft #3: Let's talk graphics

     25 comments, latest by piemmm on 11/3/04 2:07PM. Published: 31 Jan 2001

  • Random article

  • Boffin claims security holes found in ARM chips
    Researcher set to present findings later this month
     Discuss this. Published: 7 Apr 2007

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "We've written to our solicitor, you'll hear from them"
    Page generated in 0.1932 seconds.