ROL release C99 SCL to A9home users - RISC OS News, Software and Information

ROL release C99 SCL to A9home users

Published: 17th Apr 2006, 17:49:22GMT Source: drobe.co.uk
By Chris Williams

Page 1 of 1

Testers see future RISC OS 4 features

RISC 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 logo

A9home 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.

Links
A9home website

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

druck (-1.6) 17/4/06 9:03PM	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.
TonyStill (+0.2) 17/4/06 10:22PM	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
jbyrne (+1.2) 17/4/06 11:52PM	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.
xyzzy (+1.2) 18/4/06 12:12AM	*In reply to druck:* StubsG has been out six months longer than the Iyonix? From the A9home perspective, this all sounds good though.
knutson (+0.1) 18/4/06 8:50AM	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.
hEgelia (+0.2) 18/4/06 10:26AM	*In reply to 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.
jools (+1.5) 18/4/06 12:34PM	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?
wuerthne (+3.5) 18/4/06 3:52PM	*In reply to 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.
Loris (+1.0) 18/4/06 4:26PM	"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.
jools 18/4/06 4:32PM	*In reply to 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.
gdshaw (+1.5) 18/4/06 7:32PM	*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.
bucksboy 18/4/06 7:35PM	*In reply to 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.
wuerthne 20/4/06 9:18AM	*In reply to 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.
AMS 22/4/06 6:27PM	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*)?
hEgelia 22/4/06 8:00PM	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 - http://www.drobe.co.uk/riscos/artifact1526.html
AMS 23/4/06 5:58PM	*In reply to 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?).