John-Mark Bell wrote: > Sigh. It's really very, very simple[1]:
<snip>
Thank you for the voice of sanity.
I've been reading this thread wondering why everyone thinks it is so hard - I compile my stuff with StusbG which gives me greater compatibility. It was a very little change to my makefile (although there was a bit of intrepidation, as I'd been using the same makefiles for years). -- Jason Tribbeck
An odd assertion; I disagree. It appears in the RISC OS 5 ROM.
> but part of the C/C++ development suite, which Castle obtained from > Pace and have been developing further.
One does not require a subscription to the C/C++ development suite in order to run C or C++ applications on the Iyonix, because the shared C library functions are included as part of the OS by the RISC OS module colloquially referred to as "the SCL".
Castle obtained RISC OS from Pace, which included many modules that are part of a ROM build process. The Shared C Library module is amongst the set of modules built during that process. In addition to the main OS, there are numerous other components in the source tree including the C/C++ development suite tools. These are constructed as part of a separate build and marketed as a separate product.
> We are now benefit from the new C99 features which have been > introduced, significant performance improvements [...]
As indeed is anybody using an up to date RISC OS 5 ROM, whether or not they have access to the C/C++ development suite.
> However there are significant danagers of using stubsG which I have > detailed in the past, and it should be avoided.
On this, I generally agree. However, my primary objection to StubsG - which IMHO is built upon a set of admirable goals - is its lack of C99 support.
> To be fair to ROL changing to a later version of the compiler for > building an operating system is a significant undertaking, and > requires a huge amount of QA work to ensure the behaviour of any APIs > have not changed in an undesirable way.
Actually, you put the effort into testing the compiler. It's smaller!
The OS goes through the usual QA prior to any release regardless of which compiler you used to build it (or at least, it should do so in theory!). This is because there are other variables that can make your OS build invalid in subtle ways irrespective of the compiler used. This includes, but is not limited to, accidentally requesting the wrong version of one of the hundreds of components making up RISC OS from CVS in the build process, or attempting to create an OS build from an existant tree that has not been fetched clean from CVS, with that tree also improperly cleaned before the build commences.
I assume RISC OS Ltd. use a similarly rigorous process of management via CVS as Castle, though I've only direct experience of the latter. If ROL were producing a 32-bit version of the OS anyway, they've really *no* excuse to use an out of date compiler because the entire OS is going to have to be thoroughly shaken down regardless.
> Indeed the version 4 compiler was still used for some parts up to a > couple of years ago.
A shame. The current compiler has an *awful* lot of bug fixes over v4.
> So its possible ROL under time constraints for the development of the > A9 decided to stick with the same compiler and just do a straight > 32bit conversion of the existing SCL.
I suspect they did the latter because of lack of resource. Adding C99 support to the SCL is a significant undertaking.
> Hopefully ROL will move to using the latest compiler, with all of its > advantages of improved code generation and bug fixes, and then > incorporate the Castle 32bit SCL in to any OS's they build.
Seconded.
> But in the meantime Castle need to release a softloadable version of > their SCL which can be softloaded on to other 32bit machines such as > the A9.
Yeah, now, you know, I'm really not sure why that isn't done. I hadn't realised there was only the 26-bit version on the Iyonix site until reading this thread. Curious. It's a 10 minute job to build a clean RAM loading module out of CVS and bung it on the site as an unsupported downloaded. I wonder if there are tedious wider legal and/or political issues at hand.
On 1 Oct 2005 Andrew Hodgkinson <ahodg...@rowing.org.uk> wrote:
> druck wrote:
> > The SCL isn't part of RISC OS 5
> An odd assertion; I disagree. It appears in the RISC OS 5 ROM.
Well I didn't put that too well. It isn't specifically a part of RO5, and can be supplied as a standalone component, as it is for softloading on 26bit machines. It never gets softloaded on RISC OS 5, because the Iyonix has a flash ROM, the latest version is always incorporatated in to ROM image releases.
> > but part of the C/C++ development suite, which Castle obtained from > > Pace and have been developing further.
> One does not require a subscription to the C/C++ development suite in > order to run C or C++ applications on the Iyonix, because the shared C > library functions are included as part of the OS by the RISC OS module > colloquially referred to as "the SCL".
The subscription is for developers, the SCL is provided as a freely distributable component for machines which do not have a suitable version in ROM, but only 26bit machines at present.
[Snip]
> > But in the meantime Castle need to release a softloadable version of > > their SCL which can be softloaded on to other 32bit machines such as > > the A9.
> Yeah, now, you know, I'm really not sure why that isn't done. I hadn't > realised there was only the 26-bit version on the Iyonix site until > reading this thread. Curious. It's a 10 minute job to build a clean RAM > loading module out of CVS and bung it on the site as an unsupported > downloaded. I wonder if there are tedious wider legal and/or political > issues at hand.
Well I wasn't aware of the situation with the A9 until someone contacted me. I suspect Castle hasn't been formally asked by STD for a suitable 32bit softloadable version because ROL would have told their theirs is sufficent.
In article <vOC%e.10954$0w.10...@newsfe5-gui.ntli.net>, Andrew Hodgkinson <ahodg...@rowing.org.uk> wrote:
> druck wrote:
> > But in the meantime Castle need to release a softloadable version of > > their SCL which can be softloaded on to other 32bit machines such as > > the A9.
> Yeah, now, you know, I'm really not sure why that isn't done. I hadn't > realised there was only the 26-bit version on the Iyonix site until > reading this thread. Curious. It's a 10 minute job to build a clean RAM > loading module out of CVS and bung it on the site as an unsupported > downloaded. I wonder if there are tedious wider legal and/or political > issues at hand.
I think that's probably it - there are similar tedious reasons why the RISC OS 5 version of BASIC hasn't been released for machines other than Iyonix, rendering all of the additional features pretty useless. There are no technical reasons stopping it.
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
> In article <vOC%e.10954$0w.10...@newsfe5-gui.ntli.net>, > Andrew Hodgkinson <ahodg...@rowing.org.uk> wrote: > > druck wrote:
> > > But in the meantime Castle need to release a softloadable version > > > of their SCL which can be softloaded on to other 32bit machines > > > such as the A9.
> > Yeah, now, you know, I'm really not sure why that isn't done. I > > hadn't realised there was only the 26-bit version on the Iyonix > > site until reading this thread. Curious. It's a 10 minute job to > > build a clean RAM loading module out of CVS and bung it on the site > > as an unsupported downloaded. I wonder if there are tedious wider > > legal and/or political issues at hand.
> I think that's probably it - there are similar tedious reasons why > the RISC OS 5 version of BASIC hasn't been released for machines > other than Iyonix, rendering all of the additional features pretty > useless. There are no technical reasons stopping it.
Plus the Font manager :-(
By the way do the later versions of RO5 BASIC have ADRL?
On 2 Oct 2005 cfer...@freeRemoveuk.com.invalid wrote:
> In message <4db33fe9b3steve.revill.DEL...@dsl.pipex.com> > "Ste (news)" <steve.revill.DEL...@dsl.pipex.com> wrote: >> I think that's probably it - there are similar tedious reasons why the >> RISC OS 5 version of BASIC hasn't been released for machines other than >> Iyonix, rendering all of the additional features pretty useless. There are >> no technical reasons stopping it.
> Plus the Font manager :-(
If things were working as they are supposed to be there would be an exchange of code developed by ROL and Castle, so it could be integrated in to both Select and RO5, and eventually one combined OS.
> By the way do the later versions of RO5 BASIC have ADRL?
No.
> If not - could it be added?
Yes, but its probably not a priority at this stage.
cfer...@freeRemoveuk.com.invalid wrote: > Plus the Font manager :-(
The Shared C library is pretty fundamental, allowing things to run *at all*. I suppose BASIC could be considered similar. If you were going to include the Font Manager too, then why stop there? There's the USB stack for a start; quite a few fixes and extensions in the 32-bit Wimp; and more besides.
I can understand some reluctance on Castle's part to release *all* of that for free. If other people are using the OS, and ROL haven't provided compatible features, then:
(1) Why haven't ROL licensed these from Castle if they haven't got time to develop the features themselves?
(2) Why haven't the A9 developers licensed them from Castle if the A9 developers are unsatisfied with ROL's OS functionality?
Bear in mind that the development of the new Font Manager, BASIC and C library tools took quite a lot of time and effort to develop and therefore cost quite a bit of money. Castle might choose to release them for free, but that would only be even remotely viable if the development cost had already been completely met by sales of the C tools, Iyonix PCs, or other business. Even then, Castle would still be taking an effective loss by releasing all that for free.
The C library is so fundamental that I could consider it an exception, but higher level languages and independent OS features are a tougher call. Perhaps I'm wrong to single out the C library. But if Castle are supposed to release extra RISC OS 5 features for free, what about RISC OS Ltd.? Why can't I develop software using all the image file renderer plug-in stuff on an Iyonix - shouldn't ROL release that for free too? Why one rule for Castle, another for ROL?
It's not a straightforward issue. As far as I can see, the only true solution involves merging back to one version of the OS. Otherwise it would seem that sadly, everyone loses out in the long term.
In article <1jS%e.12285$0w.8...@newsfe5-gui.ntli.net>, Andrew Hodgkinson <ahodg...@rowing.org.uk> wrote:
[...]
> (2) Why haven't the A9 developers licensed them from Castle if > the A9 developers are unsatisfied with ROL's OS functionality?
This, of course, raises an interesting point which, AFAICR, hasn't really been mentioned in this thread.
The thread started with someone saying that they'd had a bug report from a user of their software on an A9. Specifically, the SCL version being RMEnsured.
That user is beta testing the A9 so, IMO, that bug report should have gone to the A9 developers.
If people are reporting problems such as this to the software developers, then it may well be that the A9 developers are unaware of the problem in the first place, unless they just happen to be reading this newsgroup and see this thread. If they know there's a problem, they may actually decide to try and get it sorted, but if it isn't brought to their attention, there's no guarantee they'll even be aware of it, let alone be able to try resolving it.
This is something that has been complained about in these groups time and time again.
On 30 Sep, Steven Pampling wrote in message <4db2a07097steve.pampl...@dsl.pipex.com>:
> In article <e0f58db24d%beamends...@btconnect.com>, > beamendsltd <beamends...@btconnect.com> wrote:
> > Now I'm not convinced...... and "The Keepers Of The OS" *still* being > > stupid does not inspire much confidence.
> At the risk of start some kind of major flame war, I think it should be > pointed out that the development of the OS on the A9 was done by ROL > while they had full knowledge of the existing 32 bit systems set in use > by users (Iyonix). If there are incompatibilities it would appear they > did it deliberately.
> Why?
Sadly, Select subscribers with longish memories will remember the fun we had when Select 2 prevented users from loading Castle's 32-bit C library. This was shortly after the big push to '32-bit' applications, and rendered a lot of software unusable on Select for a short while. ROL have *never* been able to provide a convincing technical reason for the block, which was taken out in a subsequent release, so we can only speculate as to the motivation.
On 1 Oct 2005 Steve Fryatt <n...@stevefryatt.org.uk> wrote:
> Sadly, Select subscribers with longish memories will remember the fun we > had when Select 2 prevented users from loading Castle's 32-bit C library. > This was shortly after the big push to '32-bit' applications, and rendered > a lot of software unusable on Select for a short while. ROL have *never* > been able to provide a convincing technical reason for the block, which > was taken out in a subsequent release, so we can only speculate as to the > motivation.
Good point. I'd forgotten about that adaptable patch that I had to write to re-enable softloading of the SCL regardless of the changing ROM contents on each release.
The explanation for it never held up to technical scruitiny, and caused more support work from people complaining about it, than from the tiny number of programs that got tripped up by it.
>In article <1jS%e.12285$0w.8...@newsfe5-gui.ntli.net>, > Andrew Hodgkinson <ahodg...@rowing.org.uk> wrote:
>[...]
>> (2) Why haven't the A9 developers licensed them from Castle if >> the A9 developers are unsatisfied with ROL's OS functionality?
>This, of course, raises an interesting point which, >AFAICR, hasn't really been mentioned in this thread.
>The thread started with someone saying that they'd had a >bug report from a user of their software on an A9. >Specifically, the SCL version being RMEnsured.
>That user is beta testing the A9 so, IMO, that bug report >should have gone to the A9 developers.
>If people are reporting problems such as this to the >software developers, then it may well be that the A9 >developers are unaware of the problem in the first place, >unless they just happen to be reading this newsgroup and >see this thread. If they know there's a problem, they may >actually decide to try and get it sorted, but if it isn't >brought to their attention, there's no guarantee they'll >even be aware of it, let alone be able to try resolving >it.
>This is something that has been complained about in >these groups time and time again.
Vince has got a point. I've just fired off an email to the AdvantageSix guys asking how best to deal with the situation.
What primarily went through my mind when I first got the bug report was: "Why was this the first time I had heard about such a problem"?
With the developer-only A9 being available for months, surely someone had come across this problem before?
All I wanted to know was how best to proceed.
In fact I originally worded the usenet posting as a question.
However, before posting I concluded that in this instance there was nothing lost in RMEnsureing a lower version number as functionality would not be affected.
> In message <1f7582b24d.zen44...@zen.co.uk> Simon Smith > <simon_sm...@zen.co.uk> wrote: > [huge snip] > > Given the mounting complications of dealing with all the different CLib > > and hardware versions we are now blessed with, may I suggest a simple > > utility that runs a full battery of tests and then sets system variables > > accordingly? As in
> > IF <complicatedtest> THEN OSCLI("set clib$bits 32"> IF <complicatedtest> > > THEN OSCLI("set clib$source Castle"> IF <anothercomplicatedtest> THEN > > OSCLI("set adjust$bits 32"> IF <anothercomplicatedtest> THEN OSCLI("set > > select$bits 0">:REM 0 = not present > You can have any number of convoluted checks, but none of that solves the > underlying issuse that John-Mark and myself have named - namely that the > functions required by some programs simply aren't present on the A9, and > these programs will refuse to load, even if the SCL check is taken out.
If so then that's a problem to solve. It's not the case generally as some (a good few) programs say they need the additional functions - but don't.
-- John Cartmell john@ followed by finnybank.com 0845 006 8822 Qercus magazine FAX +44 (0)8700-519-527 www.finnybank.com Qercus - the best guide to RISC OS computing
In article <1128176815.871478.6...@o13g2000cwo.googlegroups.com>, Ams
<a...@globalcafe.ie> wrote: > John Cartmell wrote: > > On 30 Sep in comp.sys.acorn.programmer, beamendsltd > > <beamends...@btconnect.com> wrote: > [snip] > > >I just need to be very confident that I can spend one Sunday afternoon > > > coying files over and then carry on as before. Silly, silly > > > people.........
> > That's why we need one OS produced by one OS developer. > > It cannot be Castle or any other hardware developer. > What like Acorn was, they developed both hardware and OS? I Can't imagine > this sorry mess happening when they were running things can you?
At that time there was only one OS and one hardware developer. No problem. Whilst multiple hardware developers is OK, multiple OS developers leads to forking.
[Snip]
-- John Cartmell john@ followed by finnybank.com 0845 006 8822 Qercus magazine FAX +44 (0)8700-519-527 www.finnybank.com Qercus - the best guide to RISC OS computing
In message <4db3ad6f28j...@cartmell.demon.co.uk> John Cartmell <j...@cartmell.demon.co.uk> wrote:
> > You can have any number of convoluted checks, but none of that solves the > > underlying issuse that John-Mark and myself have named - namely that the > > functions required by some programs simply aren't present on the A9, and > > these programs will refuse to load, even if the SCL check is taken out.
> If so then that's a problem to solve.
Yes, as been stated here ad naseum - why are you repeating it?
> It's not the case generally as some (a good few) programs say they > need the additional functions - but don't.
It is the case in a large number of cases, for precisely the reasons that have been stated. Stop trying to pass judgement on matters for which are not qualified to comment on.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
In message <4db3adf0ecj...@cartmell.demon.co.uk> John Cartmell <j...@cartmell.demon.co.uk> wrote:
> At that time there was only one OS and one hardware developer. No problem. > Whilst multiple hardware developers is OK, multiple OS developers leads to > forking.
Nonsense. A completely unjustified sweeping statement. In the case of Windows, we have multiple versions with degrees of incompatibility from just one vendor. For Linux we have hundreds of developers and although various branches, no forking (at least, certainly not in any way you think you mean).
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
In article <4db3bd9507steve.pampl...@dsl.pipex.com>, Steven Pampling <steve.pampl...@dsl.pipex.com> wrote:
> In article <4db3ae6955usenet-nos...@segfault.co.uk>, pv > <usenet-nos...@segfault.co.uk> wrote: > > Indeed, and I'm also sceptical over the point they've only had 36 > > enquiries from Iyonix users wanting Select - especially as I know > > about 15 users myself who are waiting! > I think they are only counting Select users who want to use it on > an Iyonix. Strangely enough there are a fair few Iyonix users who > have no use whatsoever for a 26 bit Select and therefore are part
> The C library is so fundamental that I could consider it an exception, but > higher level languages and independent OS features are a tougher call. > Perhaps I'm wrong to single out the C library. But if Castle are supposed > to release extra RISC OS 5 features for free, what about RISC OS Ltd.? Why > can't I develop software using all the image file renderer plug-in stuff > on an Iyonix - shouldn't ROL release that for free too? Why one rule for > Castle, another for ROL?
Well, ROL released 32-bit compatible toolbox modules for free isn't it? I think they could do some source code exchange here, so that the Iyonix could include the latest ToolBox modules in their Flash ROMs while ROL includes the 32-bit SCL.
In message <01622cb24d.pe...@chocky.org> Peter Naulls <pe...@chocky.org> wrote:
> AIUI, Castle's distributed SCL cannot be loaded onto the A9, and it's > designed to be loaded onto 26-bit systems. I don't know how practical > it would be (legalities aside) to load the SCL from RO5 ROM on the A9. > One solution would be for Castle to make their loadable SCL suitable for > the A9. I don't know what would be involved with this.
I asked someone with an A9Home to test a softloaded 32-bit version of Castle's CLib 5.53 and it turned out to work just fine on the A9Home. So, simply distributing that allows all software linked with Castle's stubs to work unmodified on the A9Home. From earlier conversation with Castle I got the impression that Castle is determined to support all available RISC OS platforms with their development tools, so I do not think it will be a problem to get a download for A9Home users sorted.
It certainly solves problems with EasiWriter/TechWriter on the A9Home. A straightforward recompilation with StubsG (involving some rework to remove C99 dependencies) resulted in a copy that worked on the RiscPC and Iyonix but had problems on the A9Home - so, it was a waste of time. With the softloaded 32-bit CLib 5.53, the standard release version works straight out of the box. So, the path to take seems to be pretty clear to me.
Martin -- --------------------------------------------------------------------- Martin Wuerthner MW Software http://www.mw-software.com/ ArtWorks 2 -- Designing stunning graphics has never been easier spamt...@mw-software.com [replace "spamtrap" by "info" to reply]
On 2 Oct, Philip Ludlam wrote in message <9febabb34d.phi...@philipnet.com>:
> What primarily went through my mind when I first got the bug report was: > "Why was this the first time I had heard about such a problem"?
> With the developer-only A9 being available for months, surely someone > had come across this problem before?
It has been seen, though not publicly mentioned AFAIK. I had a report of problems with one of my apps at the start of September (my response being along the lines of "ROL need to fix it", IIRC), but I gather that previous releases of the same app ran fine on the A9.
Guessing slightly, but I think the main change between versions was me upgrading to the latest version of GCC and compiling with that. Also, I wonder how many apps use the C99 capabilities of the Castle library, and would therefore show the problem up?
On 2 Oct, John Cartmell wrote in message <4db3ad6f28j...@cartmell.demon.co.uk>:
> In article <a4ea92b24d.pe...@chocky.org>, Peter Naulls <pe...@chocky.org> > wrote:
> > You can have any number of convoluted checks, but none of that solves > > the underlying issuse that John-Mark and myself have named - namely > > that the functions required by some programs simply aren't present on > > the A9, and these programs will refuse to load, even if the SCL check > > is taken out.
> If so then that's a problem to solve. It's not the case generally as > some (a good few) programs say they need the additional functions - but > don't.
Do you have any basis for this bizarre assertion? Very few programs are going to actively look for resources they don't need, and suggesting to users that they can safely remove checks from !Run files is unhelpful in the extreme.
In message <09b8c6b44d.st...@helvellyn.stevefryatt.org.uk> Steve Fryatt <n...@stevefryatt.org.uk> wrote:
> Guessing slightly, but I think the main change between versions was me > upgrading to the latest version of GCC and compiling with that. Also, I > wonder how many apps use the C99 capabilities of the Castle library, and > would therefore show the problem up?
SunFish does, there are probably others that can be found without too much hassle. Some of these fuctions deal with 64-bit arithmetic. In addition, any libraries or code you've got that uses assert() and was compiled against the Castle headers will reference the __assert2 function, which isn't present in StubsG. In short, it's best that this problem is solved properly.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Peter Naulls wrote: > In message <09b8c6b44d.st...@helvellyn.stevefryatt.org.uk> > Steve Fryatt <n...@stevefryatt.org.uk> wrote: > > Guessing slightly, but I think the main change between versions was > > me upgrading to the latest version of GCC and compiling with that. > > Also, I wonder how many apps use the C99 capabilities of the Castle > > library, and would therefore show the problem up? > SunFish does, there are probably others that can be found without too > much hassle. Some of these fuctions deal with 64-bit arithmetic.
> On 2 Oct, John Cartmell wrote in message > <4db3ad6f28j...@cartmell.demon.co.uk>:
> > In article <a4ea92b24d.pe...@chocky.org>, Peter Naulls > > <pe...@chocky.org> > > wrote:
> > > You can have any number of convoluted checks, but none of that > > > solves the underlying issuse that John-Mark and myself have > > > named - namely that the functions required by some programs > > > simply aren't present on the A9, and these programs will refuse > > > to load, even if the SCL check is taken out.
> > If so then that's a problem to solve. It's not the case generally > > as some (a good few) programs say they need the additional > > functions - but don't.
> Do you have any basis for this bizarre assertion? Very few programs > are going to actively look for resources they don't need, and > suggesting to users that they can safely remove checks from !Run > files is unhelpful in the extreme.
It can happen. It shouldn't, but it does.
For example, when re-compiling a program to make it 32 bit compatible. The programmer "RMEnsures" the version of CLib used during compilation but as it's an old program and the code was originally written to work with a much older library it may not *need* the latest version and may even work on a 26 bit machine with the original CLib.
However, it certainly doesn't solve the problem on the A9 where code may have been written to require the later functions.
> On 4-Oct-2005, Steve Fryatt <n...@stevefryatt.org.uk> wrote: > > On 2 Oct, John Cartmell wrote in message > > <4db3ad6f28j...@cartmell.demon.co.uk>:
> > > In article <a4ea92b24d.pe...@chocky.org>, Peter Naulls > > > <pe...@chocky.org> > > > wrote:
> > > > You can have any number of convoluted checks, but none of that > > > > solves the underlying issuse that John-Mark and myself have > > > > named - namely that the functions required by some programs > > > > simply aren't present on the A9, and these programs will refuse > > > > to load, even if the SCL check is taken out.
> > > If so then that's a problem to solve. It's not the case generally > > > as some (a good few) programs say they need the additional > > > functions - but don't.
> > Do you have any basis for this bizarre assertion? Very few programs > > are going to actively look for resources they don't need, and > > suggesting to users that they can safely remove checks from !Run > > files is unhelpful in the extreme. > It can happen. It shouldn't, but it does. > For example, when re-compiling a program to make it 32 bit compatible. > The programmer "RMEnsures" the version of CLib used during compilation > but as it's an old program and the code was originally written to work > with a much older library it may not *need* the latest version and may > even work on a 26 bit machine with the original CLib. > However, it certainly doesn't solve the problem on the A9 where code > may have been written to require the later functions.
But is a first step to check if it's one of Steve's 'bizarre' (but not uncommon) cases or something requiring more work.
-- John Cartmell john@ followed by finnybank.com 0845 006 8822 Qercus magazine FAX +44 (0)8700-519-527 www.finnybank.com Qercus - the best guide to RISC OS computing
> On 4-Oct-2005, Steve Fryatt <n...@stevefryatt.org.uk> wrote:
>> On 2 Oct, John Cartmell wrote in message >> <4db3ad6f28j...@cartmell.demon.co.uk>:
>> > If so then that's a problem to solve. It's not the case generally >> > as some (a good few) programs say they need the additional >> > functions - but don't.
>> Do you have any basis for this bizarre assertion? Very few programs >> are going to actively look for resources they don't need, and >> suggesting to users that they can safely remove checks from !Run >> files is unhelpful in the extreme.
> It can happen. It shouldn't, but it does.
> For example, when re-compiling a program to make it 32 bit compatible. > The programmer "RMEnsures" the version of CLib used during compilation > but as it's an old program and the code was originally written to work > with a much older library it may not *need* the latest version and may > even work on a 26 bit machine with the original CLib.
No, that is completely wrong. A program recompiled for 32-bit compatibility REQUIRES a 32-bit CLib. It NEVER works on a 26-bit machine with the original CLib.
> However, it certainly doesn't solve the problem on the A9 where code > may have been written to require the later functions.
This is not an A9 problem at all, although this discussion was sparked off when discussing the A9. The only reason why it matters for the A9 is because there is no official softload copy of Castle's CLib for it. The softload 32-bit version supplied with Castle's C/C++ suite works fine, however, and allows all software to run.
For the record: There are two completely unrelated extensions of CLib: A) 32-bit support B) Presence of C99 extensions
Up to now, we only had CLibs that either had neither (ROM versions in RO 3.x and 4.x) or both (ROM versions in RO 5.x and softload CLib from iyonix.com). The A9Home comes with a CLib that has A but not B. Checking for two unrelated orthogonal features is not practical with a one-dimensional version number.
There has not been any official information about CLib support on the A9Home, so all programs released up to now are doing the right thing: They check for the minimum version of CLib that guarantees the feature(s) they neeed. Whether they check solely for A or for (A and B) cannot be seen from the !Run file.
Martin -- --------------------------------------------------------------------- Martin Wuerthner MW Software http://www.mw-software.com/ ArtWorks 2 -- Designing stunning graphics has never been easier spamt...@mw-software.com [replace "spamtrap" by "info" to reply]
|
