Graham Shaw has released an early experimental build of his open source SharedCLibrary module. The unofficial SCL is billed as a free re-implementation of the RISC OS core module by the same name. It is hoped Graham's module will offer various enhancements and features over the existing SCLs from Castle and RISCOS Ltd - such as extra debugging to SysLog.

The SCL provides a toolkit of useful functions for all applications to use when they need to work with files, manage resources, display text, and so on.

For the moment, Graham's module is suitable for 32bit safe versions of RISC OS only, although he hopes to address this later. Graham also said the module needed a speed boost, but he was focused on getting the library working first before optimising it later.

Graham, pictured, said: "The free SharedCLibrary should be able to act as a drop-in replacement. Don't even think about doing any performance tests at the moment, unless you want a good laugh. Some rather critical functions are written in C.

"Due to the nature of this module it has the potential to cause widespread disruption to a machine if it fails. For this reason, it is being released for the purpose of evaluation and compatibility testing only in the first instance. Please read the supplied documentation before attempting to use it."

While it's regrettable that such duplication has occured (especially by ROL, who can hardly have had the resources to write a new SCL when they've got so much else to do), Graham's effort is certainly welcome. Hopefully, if the ROOL effort ever materialises, Graham's work can feed back into that, adding thenew features he's created and allowing the platform to standardise back on to a single version usable on all machines.

I don't see why having separate implementations is such a problem provided that they work to the same API. If you find a difference of behaviour then it is either a bug in your program or a bug in the library, and in either case the sooner it is eliminated the better.

I aim to match any implementation-defined behaviour of the existing SCL implementation, and programs should not rely on unspecified or undefined behaviour in the first place. I've also made it very clear that in its experimental phase, the SCL should be considered the prime suspect for any problems that occur and they should not be reported to other developers.

I haven't had chance to evaluate this version yet, but there is considerable scope for improvement of the SCL in an open source version, which would immediately benefit a huge number of applications. For example the UnixLib implementation of some of the stdio functions such as sprintf are far more efficient than either RISC OS SCL, and recent work on utilising the XScale's Application Accelerator engine could be used to drastically speed up large memcpy and memset operations.