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

ROL release C99 SCL to A9home users

By Chris Williams. Published: 17th Apr 2006, 17:49:22 | Permalink | Printable

Testers see future RISC OS 4 features

32bit RISC OSRISC OS 4.42 rolled out to A9home users this month includes a 32bit SharedCLibrary with C99 functionality. It is hoped this will address the messy issue of the split caused by Castle and RISCOS Ltd developing their own separate SCLs, as this new module from ROL is intended to be compatible with software built for the Castle SCL. AdvantageSix now say that all users should be happy using the SharedCLibrary installed in their computers' ROMs, and developers should switch to using StubsG to maximise compatibility. The new C99 SCL is understood to be included in Select 4, the belated next release of RISC OS 4.

The SCL is a core operating system component that provides applications with a set of common resources, and Castle and RISCOS Ltd each provide a flavour of the module to end users. Software on their computers use the installed SCL to perform basic tasks, such as accessing files and asking for memory.

In the days before 32bit RISC OS 4, Castle made available a SCL for RiscPCs and other computers using a 26bit RISC OS. A 32bit version of this SCL was included in RISC OS 5, shipped with Iyonixes. Software programs that intended to work on both 26bit and 32bit RISC OS were rebuilt with Castle's SCL in mind. However, after the arrival of the A9home and 32bit RISC OS 4, a lot of software refused to run with the RISCOS Ltd SCL, due to version number checks or missing features. ROL's solution was to bring their SCL up to match or exceed the features of the Castle SCL. By luck, the version number of the RISCOS Ltd C99 SCL is 5.59 - higher than Castle's current version of 5.53, so existing third party software will accept it.

Matt Edgar of AdvantageSix, who manufacture the A9 range, said the version numbering was not deliberate, but added that since the split in development of RISC OS, version numbering of common components has 'gone out the window'.

He said: "We are simply not going to play the version numbers game. People should use the version of the SCL in ROM in their machines. Developers should ideally use StubsG, because then there's no need to mess about making sure the 'right' SCL is installed, and distribution becomes easier."

A C99 capable version of StubsG is in testing, pending release. The library acts as a hook for applications, allowing them to use whichever SCL is installed. Castle provide their own 'stubs' library, for their own SCL, with their C/C++ compiler package. A number of leading developers, including MW Software and R-Comp, have recently turned to using StubsG for their products.

A couple of messages were spotted in the new version of the A9home's operating system which would appear to warn the user if they attempt to use an "unsuitable" SharedCLibrary module. The warning text reads: "This version of the SharedCLibrary is known to be unsuitable for this operating system version and may cause instability with certain components. Please contact your supplier for an upgrade."

AdvantageSix said the messages were included accidentally in the beta ROM release, and as they are not used by the OS, they should be ignored.

A9home logoA9home development
The latest ROM issued to A9home users, who form the pool of selected beta testers of the ARM9 powered machine, declares itself as being 'RISC OS Select 4pre8 (32bit)'. The A9home's Flash memory is updated using a tiny and basic version of Linux in the Flash ROM image - although the two OSes are separate, drivers on the Linux side have been reportedly fed into the mainstream Linux kernel sources, and AdvantageSix stress that they will only look into a full Linux port for the A9home after the RISC OS product is done and dusted.

The team have spent time on a recent stability drive in RISC OS to really tighten up the operating system and block badly behaving applications from trashing the desktop. One example of this is to prevent software that doesn't have an 'AIF header' from running. The OS can use the information stored in this header to properly tell if an application claims to be 32bit compatible, amongst other details. Acorn mandated a decade ago that software should use this header, so this new check is expected to mainly catch poorly constructed programs. Another example of tightening up system stability was seen by the developers of text and source code editor StrongED. The application would crash when the user interacted with a search results window on the A9; it turned out to be a fault in the application that caused it to access memory that didn't belong to it.

After pin-pointing the bug and fixing StrongED, programmer Fred Graute said: "What's astounding is that this bug has been in every version of StrongED since at least 4.60, and hasn't resulted in abort errors before. Presumably the A9 has a version of RISC OS that guards better against this kind of thing."

In addition, an update to protect operating workspaces from being scribbled over by badly behaving or poorly written software should prevent the scenario of an application causing a system crash several minutes later, just when the user is about to do something critical, such as save the document they've been working on for a hour.

The OS also includes 'abortable dynamic areas', meaning that when software accesses parts of the DA, a smaller piece of software can be notified and perform some extra activity related to it - opening up the possibilities of a third-party developer implementing, for example, a virtual memory system. DAs can also be created and mapped to physical memory, enabling hardware drivers to more easily access devices. An initial glimpse of ROL's new debugger is included in the ROM build, which will eventually form part of a tool that will allow developers and testers to easily follow a 'bread crumb'-like trail through the system in search for the cause of a bug or crash. The tool has already been used to address an obscure fault in the Filecore module and other components, and can track faults in device driver level code.

RISC OS 4.42 now features automatic monitor detection, allowing the system to be optionally configured to switch to different screen modes depending on the monitor it's plugged into. This builds upon Ad6's goal of encouraging A9home users carry their diminutive computers to and from work and home; there's the possibility that this feature may be expanded so that the system will switch to a user-defined 'home' configuration (with suitable network, pinboard and other settings) when it's plugged into the living room large plasma screen, and then switch to another user-defined configuration (with productivity applications loaded and so on) when the unit is plugged into the office LCD monitor.

Support for accessing CDs via USB is included and has been tested for some time, although serial port and CMOS memory support are still on the to-do list - the latter being a somewhat headache to implement given the level of hardware abstraction now in the operating system and the fact that it relies on accessing the keyboard hardware early into the boot sequence. The team have also worked out a way to increase the wimpslot size but have not implemented any changes in this area; they are reluctant to extent it in order to maintain compatibility with software running on RiscPCs.

AdvantageSix are said to be comfortable that the A9home should be ready in time for a formal launch at the Wakefield show, or the weeks immediately after.


A9home website

Previous: Printing over a network with ease on RISC OS
Next: Euro Expo 2006 confirmed


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

I wish people who should know better would stop recommending developers use StubG, as after 4 years there still is not a released version which doesn't feature broken libraries. Its also a backwards step as it prevents modern more efficent compiler features to be used.

I'm afraid I tuned out after reading that.

 is a RISC OS Userdruck on 17/4/06 9:03PM
[ Reply | Permalink | Report ]

I think it would have been a magnanimous gesture by Castle to have allowed their existing Shared C Library to have been distributed with the A9. I frankly doubt that many people do not have a valid licence for it (you get one from a developer who distributes code that relies upon it) and it would have been a low (no?) cost contribution to the market as a whole.

It does no-one any good that scarce developer time is spent duplicating basic resources. It may be politically impossible to stop people duplicating the 32-bit OS but, surely, something like this is not damaging anyone's position :-(

 is a RISC OS UserTonyStill on 17/4/06 10:22PM
[ Reply | Permalink | Report ]

What amazes me is that people are prepared to spend days of time pointlessly reinventing a wheel, but are apparently unable to invest any time whatsoever in sorting out their differences to avoid such a thing being necessary.

 is a RISC OS Userjbyrne on 17/4/06 11:52PM
[ Reply | Permalink | Report ]

druck: StubsG has been out six months longer than the Iyonix?

From the A9home perspective, this all sounds good though.

 is a RISC OS Userxyzzy on 18/4/06 12:12AM
[ Reply | Permalink | Report ]

Sounds like a number of improvements to RISC OS are going to appear with the A9. The improvements to the core operating system sound good and can only help to improve the end users experience.

A lot of "duplicated effort" has occurred but at the end of the day both Castle and Advantage Six have to provide a point of difference to ensure they win sales. They are in competition with each other and need to sell machines to stay afloat. It is hardly surprising that things happen the way they do.

USB serial ports will be quite useful to many people. The A9 as an upgrade to RiscStation based EPOS systems would be a possibility with the addition of serial ports.

 is a RISC OS Userknutson on 18/4/06 8:50AM
[ Reply | Permalink | Report ]

knutson: "They are in competition with each other and need to sell machines to stay afloat."

Competition okay, but needing to sell machines to stay afloat? Unlikely, since they most probably couldn't - our market (the desktop RO market) is simply a nice, welcome side-benefit to their primary developments marketing. Embedded stuff or whatever that is.

As a RO user, I feel confused about some of this news. You know, I don't even know if I want to upgrade, since I just don't know what I'm gonna get! I greatly value Drobe for bringing us this news, but it still worries me. I hope when the A9home gets released (at Wakefield?) it will be presented with a nice piece of product marketing, including wtf its version of RO means/does since outside of Drobe, there's no way of knowing. I'm also interested if besides playing, recording audio works.

Am I such an idiot that I just expect a product page somewhere?

Because "RISC OS Select 4pre8 (32bit)" implies to me it will be 32 bit Select 4, which has, for the most part, been paid for by subscribers. If I buy an A9Home, will it be 'dirty' in that sense? I will not be sitting pretty with an A9home, which was paid by fellow dedicated enthusiasts who got nothing for it in return, except the satisfaction of supporting certain 'developments'. Yes, I know those that re-subscribed after ... / xxx will get a BETA release of Select 4, to encourage them to pay again to get the real deal. Will A9home's Select 4 also be a Beta? No, don't think so. What will be the differences...?

Furthermore, I am not content with paying for duplicate developments, because the kids-in-charge can't play nice. They are scaring me away, while I love RO. Now there are 3 Shared C Libraries, of which I hope the Open Source one will be adopted by both Castle and RISCOS Middleton Developments Ltd. Thanks for your patience.

 is a RISC OS UserhEgelia on 18/4/06 10:26AM
[ Reply | Permalink | Report ]

Will developers have to alter their applications' !Run files to correctly load a C99-capable SCL, or are they fine as they stand? If StubsG isn't used?

What does it mean to (not) 'play the version numbers game'? Certainly, Castle and A6 shouldn't have competing version-number schemes - that renders them useless. Even if they had different implementations, they could still agree on which versions introduce which functionality, couldn't they?

 is a RISC OS Userjools on 18/4/06 12:34PM
[ Reply | Permalink | Report ]

jools: No, unfortunately, with two independent development strands there is no way to have compatible version numbering schemes unless both parties always add exactly the same features in exactly the same order, which is unlikely. As soon as one party adds feature A but not B and the other party adds B but not A, there simply is no possible numbering scheme that allows any third party to determine whether one particular feature is present.

 is a RISC OS Userwuerthne on 18/4/06 3:52PM
[ Reply | Permalink | Report ]

"As soon as one party adds feature A but not B and the other party adds B but not A, there simply is no possible numbering scheme that ..."

Yes there is ... bit array

Of course, that would require an unprecedented amount of communication between developers, and also isn't how RISC OS does it, but it is a theoretical possibility.

I suppose that in practice you'd want a hybrid approach with a linear version number as well, if you were seriously implementing such a system.

 is a RISC OS UserLoris on 18/4/06 4:26PM
[ Reply | Permalink | Report ]

wuerthne: You're right, of course, if they're free to choose what feature to add next. But since it's the C library, at least they could standardize on coarse version numbers for coarse features e.g. C89, C95, C99. !Run files can look for just those, leaving the !System installer to deal with the finer details.

 is a RISC OS Userjools on 18/4/06 4:32PM
[ Reply | Permalink | Report ]

In reply to jools:

If the two branches simply went off in their own direction then we would already have a complete disaster, because it is rather important that each function within a given library chunk have a unique and well-defined interface. Fortunately, that hasn't happened.

Given that this basic level of cooperation is essential, it would not be difficult to arrange for the version number to increment each time the interface is changed.

What would be needed for this to happen is agreement that the version number identifies the interface to which a module conforms rather than a specific implementation.

 is a RISC OS Usergdshaw on 18/4/06 7:32PM
[ Reply | Permalink | Report ]

knutson: competition is fine, but I don't agree that this latest development is either inevitable or desirable. It seems to me that developers are being asked to back either one horse or the other, or (at increased expenditure of time & effort), both.

 is a RISC OS Userbucksboy on 18/4/06 7:35PM
[ Reply | Permalink | Report ]

bucksboy: I cannot think of anyone who uses both solutions at the same time, and why would anyone want to? If you link against StubsG it will run everywhere without any worries about CLib versions etc. If that works for you, why would you even want to look for alternatives?

The latest releases by ROL have narrowed the gap considerably. The C99 enabled CLib in the A9Home allows executables to run that previously required the Castle CLib. The C99 enabled StubsG allows programs to link against StubsG that previously required the Castle Stubs (and hence the Castle CLib on 26-bit systems).

So, with these new releases, it matters less and less which linking solution a program uses, both solutions are converging.

 is a RISC OS Userwuerthne on 20/4/06 9:18AM
[ Reply | Permalink | Report ]

ROL's production of a 32bit Shared CLib for the A9Home is a useful development, and should be welcomed. Its a pity that they could not have come to some arrangement with Castle to obtain the standard 32bit SCL - but given that they didn't/coundn't this solution is a fair alternative.

I am a little puzzled though by the comment about WimpSlot size limitations not being lifted in order to maintain compatibility with RPC variants of RISC OS. Surely any applications will either be 32bit clean (in which case the RPC WimpSlot limitation need not apply - on the Iyonix it doesn't), or the code is 26bit - in which case it *can't run* in which case incompatibilities with Wimpslot size are the least of its problems - alternatively A9 users could use Aemulor which would allow the old code to run (and AFAIK) also limits the WimpSlot to the same as the RPC (a limitation that should *only* be in effect while required - ie., when Aemulor/26bit only code runs).

Why put limits in where none are required (especially when there's a solution at hand - Aemulor)?

 is a RISC OS UserAMS on 22/4/06 6:27PM
[ Reply | Permalink | Report ]

Just a thought, but who says Castle didn't formally allow the use of their SCL?

I couldn't find any direct reference of that in the article, except for "It is hoped this will address the messy issue of the split caused by Castle and RISCOS Ltd developing their own separate SCLs, as this new module from ROL is intended to be compatible with software built for the Castle SCL."

I remember an article about such a dispute between CTL and ROL about it. I believe Castle did offer them to use it, when certain conditions were met. For details, see -


 is a RISC OS UserhEgelia on 22/4/06 8:00PM
[ Reply | Permalink | Report ]

hEgelia>Indeed you appear to be correct, that article you linked to *would appear* to indicate that Castle were willing to license the SCL, that being the case one can only speculate as to why that didn't happen. It would have made sense to use the Castle one (in that it *is* known to work on a 32bit machine and has done for some time (the Iyonix)) whereas whatever ROL offer at this point is bound to have a whiff of "beta" about it (I expect it'll settle in - but then why make life more complicate than it needs to be eh?).

 is a RISC OS UserAMS on 23/4/06 5:58PM
[ 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

  • The Editor's Decision is Final - Part One
    We kick off a new series of lighthearted news coverage with some articles which didn't quite make it to your screens
     6 comments, latest by peprice on 4/8/01 5:11PM. Published: 1 Aug 2001

  • Random article

  • Castle introduces Iyonix cube
    Cheap and cheerful
     24 comments, latest by AMS on 2/8/05 7:05PM. Published: 1 Aug 2005

  • 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
    "The Drobe 'Best of 2005 awards' seems to have been infiltrated by a form of favouritism or censorship"
    Page generated in 0.1641 seconds.