I've got a bug report from a user using some of my software on an A9.
He comments that the software *RMEnsures SharedCLibrary 5.17 , but he's running version 5.02 (!)
In the dim and distant past, the RMEnsure of version 5.17 or later was used to ensure that a bug-free enough version of the SharedCLibrary produced by Pace was used on all previously available machines.
Now, with the advent of the A9, it seems that RISC OS Developments have produced their own 32-bit version of the SharedCLibrary. If one was being particularly bitter one might assume that there's still a big dispute between ROD and Castle ;-) .
Presumably this version of the SharedCLibrary is going to find it's way onto other ROD products (maybe even Select 4!) so I'm going to have to bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of the other SharedCLibrary isn't lurking around anywhere.
In message <19f529b24d.phi...@philipnet.com> Philip Ludlam <nos...@philipnet.com> wrote:
> Now, with the advent of the A9, it seems that RISC OS Developments have > produced their own 32-bit version of the SharedCLibrary. > If one was being particularly bitter one might assume that there's still > a big dispute between ROD and Castle ;-) .
Irrespective of that, the A9 requires _a_ 32-bit SCL of some description.
> Presumably this version of the SharedCLibrary is going to find it's way > onto other ROD products (maybe even Select 4!) so I'm going to have to > bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of > the other SharedCLibrary isn't lurking around anywhere.
"its way", perhaps. But the situation is more complex than you presume. Castle's SCL contains quite a number of extra functions that ROL's doesn't. In practice, this means that any program linked with Castle's stubs or indeed GCC's stubs will refuse to load at all on an A9 since ROL's SCL will not contain the extra chunks that refer to the extra functions. Programs can of course be linked with StubsG, which may or may not be practical.
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.
Another more drastic, but perhaps ultimately more flexible solution, would be for developers to take the bull by its horns, and develop their own open source SCL, starting by taking code from UnixLib. This would level the playing field, and avoid inter-company politics. I believe the amount of work involved would not be that large.
----== 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 =----
Philip Ludlam wrote: > I've got a bug report from a user using some of my software on an A9.
> He comments that the software *RMEnsures SharedCLibrary 5.17 , but he's > running version 5.02 (!)
> In the dim and distant past, the RMEnsure of version 5.17 or later was > used to ensure that a bug-free enough version of the SharedCLibrary > produced by Pace was used on all previously available machines.
You could (and I'm not saying this is a good idea) probably come up with various RMEnsures on the UtilityModule to work out if you have a 32bit ROL RISC OS and lower the requirement in that case. This sort of stuff should not be necessary.
> Now, with the advent of the A9, it seems that RISC OS Developments have > produced their own 32-bit version of the SharedCLibrary. > If one was being particularly bitter one might assume that there's still > a big dispute between ROD and Castle ;-) .
I'm in a similar situation, only my software depends on C99 features and I've been informed by users that the Castle SCL is incompatible with the A9 version of RISC OS. The workaround appears to be to use StubsG though in my case, StubsG is no help as old 26bit SCLs don't support C99 :-(
> Presumably this version of the SharedCLibrary is going to find it's way > onto other ROD products (maybe even Select 4!) so I'm going to have to > bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of > the other SharedCLibrary isn't lurking around anywhere.
We really shouldn't be having these problems with such an important module...
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.
Well, given that I appear to have a softloadable 32bit variant of SCL 5.53 sat in the EndUser directory of my C tools tree, not very much, I should think. It appears this hasn't made its way into the download on iyonix.com
> In message <19f529b24d.phi...@philipnet.com> > Philip Ludlam <nos...@philipnet.com> wrote: > > Now, with the advent of the A9, it seems that RISC OS Developments have > > produced their own 32-bit version of the SharedCLibrary. > > If one was being particularly bitter one might assume that there's still > > a big dispute between ROD and Castle ;-) .
> Irrespective of that, the A9 requires _a_ 32-bit SCL of some > description.
> > Presumably this version of the SharedCLibrary is going to find it's way > > onto other ROD products (maybe even Select 4!) so I'm going to have to > > bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of > > the other SharedCLibrary isn't lurking around anywhere.
> "its way", perhaps. But the situation is more complex than you > presume. Castle's SCL contains quite a number of extra functions that > ROL's doesn't. In practice, this means that any program linked with > Castle's stubs or indeed GCC's stubs will refuse to load at all on an A9 > since ROL's SCL will not contain the extra chunks that refer to the > extra functions. Programs can of course be linked with StubsG, which > may or may not be practical.
To further confuse the situation it appears that while the version on the A9 wont have the C99 functions, it does seem to mesh with the Castle 32bit stubs allowing 32bit C code to run, but god knows what happens if it tries to use any C99 features.
One of the early A9 adoptors had a harddisc problem and reported there were able to get DiscKnight to run after commenting out the RMEnsure line, and it appeared to run correctly.
However I'm reluctant to make any change to applications without being able to test the implications of C99 support not being present. So am waiting for some guidelines which hopefully STD (bugger all chance of hearing from ROL) will be issuing if they want their machine to be supported.
In article <7af638b24d.dr...@druck.freeuk.net>, druck <n...@druck.freeuk.com> wrote:
> One of the early A9 adoptors had a harddisc problem and reported there were > able to get DiscKnight to run after commenting out the RMEnsure line, and it > appeared to run correctly.
Some programs (not DiscKnight IIRC) try to RMEnsure a RISC OS 5 module but run OK without the RMEnsure. If they ran OK without the module then maybe that was there specifically to check that it was running on an Iyonix? Shouldn't they be making a generic check for 32-bit (and even then only if they are special programs like DK and need that info) - rather than for a specific machine?
Do you know which RMEnsure line wasn't needed in DiscKnight? OK I know the Iyonix was the only 32-bit machine when you wrote the program (if that was the case there) - but I don't understand the need to check for a module when it will work without the module.
NB I'm asking. I've examined the !Run files of lots of programs recently and can't make sense of many that have been produced to run on the Iyonix.
-- 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 <4db27493e5j...@cartmell.demon.co.uk> John Cartmell <j...@cartmell.demon.co.uk> wrote:
> In article <7af638b24d.dr...@druck.freeuk.net>, > druck <n...@druck.freeuk.com> wrote: >> One of the early A9 adoptors had a harddisc problem and reported there >> were able to get DiscKnight to run after commenting out the RMEnsure >> line, and it appeared to run correctly.
> Some programs (not DiscKnight IIRC) try to RMEnsure a RISC OS 5 module > but run OK without the RMEnsure. If they ran OK without the module > then maybe that was there specifically to check that it was running on > an Iyonix? Shouldn't they be making a generic check for 32-bit (and > even then only if they are special programs like DK and need that > info) - rather than for a specific machine?
I doubt there are any programs REQUIRING 32-bit mode. There may be a few programs REQUIRING an Iyonix. Therefore, a generic check for 32-bit mode in the !Run file does not make any sense. Regarding DiskKnight: Contrary to your assumption, DK is NOT a special program that would care at all on which machine it runs. All it needs is the Castle 32-bit CLib because it is linked with the Castle 32-bit Stubs.
In general, this issue is very complicated because there are FOUR loosely related things a program might want to check or enforce: i) Iyonix vs. RISC OS 3/4/Select/Adjust/Adjust32 ii) 26-bit vs. 32-bit operation iii) 26-bit CLib vs. 32-bit CLib iv) ROL Clib vs. Castle CLib and there are TWO main places where such checks are done: A) In the !Run file B) in the main application code.
Which makes 8 combinations. Depending on the place, it is easy or difficult to make the one check or the other, so quite often, an easier check is used instead of a more complicated one and the result is inferred based on certain assumptions. This is unfortunate but has happened in many programs, including my own. For instance, in ARM code, it is very quick to test the processor mode and slightly more difficult to check module versions. So, the usual assumptions were: [32-bit mode => Iyonix] and [32-bit mode => Castle CLib], both of which are no longer true on the A9. Conversely, in the !Run file it is difficult to check the processor mode, so the usual assumption was: [UtilityModule < 5.00 => 26-bit operation], which is no longer true. The same goes for CLib. The usual assumptions are [CLib < 5.17 => 26-bit CLib], [CLib < 5.17 => ROL CLib], [CLib >= 5.17 => 32-bit CLib], [CLib >= 5.17 => Castle CLib], and [32-bit CLib => Castle CLib], the first and last of which are no longer true on the A9.
> Do you know which RMEnsure line wasn't needed in DiscKnight? OK I know > the Iyonix was the only 32-bit machine when you wrote the program (if > that was the case there) - but I don't understand the need to check > for a module when it will work without the module.
You misunderstood. The RMEnsure reference in DiskKnight was for the 32-bit CLib. The line in DiskKnigh is the official way of testing and ensuring a 32-bit CLib. The same line is found in many programs (including most of my own).
Unfortunately, you cannot see from this line whether the program wanted to check for iii) or for iv). Some programs DO require the Castle CLib, some only require some 32-bit CLib. In the former case, you cannot simply remove the RMEnsure, in the latter case you can.
The only way to avoid the CLib headaches at the moment is to link with StubsG and then not check for any CLib in the !Run file at all. Unfortunately, this requires lots of programs to be recompiled and relinked by their authors, which not all will want to do. If the program uses C99 features, it depends on the Castle CLib and may require extensive rework to make it work with StubsG (just done that for EasiWriter but there are still issues with the A9 version).
Alternatively, if a way was found to softload the Castle CLib on the A9, then most software could run unchanged.
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]
> > I've got a bug report from a user using some of my software on an A9.
> > He comments that the software *RMEnsures SharedCLibrary 5.17 , but he's > > running version 5.02 (!)
> > In the dim and distant past, the RMEnsure of version 5.17 or later was > > used to ensure that a bug-free enough version of the SharedCLibrary > > produced by Pace was used on all previously available machines.
> You could (and I'm not saying this is a good idea) probably come up with > various RMEnsures on the UtilityModule to work out if you have a 32bit > ROL RISC OS and lower the requirement in that case. This sort of stuff > should not be necessary.
> > Now, with the advent of the A9, it seems that RISC OS Developments have > > produced their own 32-bit version of the SharedCLibrary. > > If one was being particularly bitter one might assume that there's still > > a big dispute between ROD and Castle ;-) .
> I'm in a similar situation, only my software depends on C99 features and > I've been informed by users that the Castle SCL is incompatible with the > A9 version of RISC OS. The workaround appears to be to use StubsG though > in my case, StubsG is no help as old 26bit SCLs don't support C99 :-(
> > Presumably this version of the SharedCLibrary is going to find it's way > > onto other ROD products (maybe even Select 4!) so I'm going to have to > > bite the bullet and ammend the RMEnsure and hope that 5.17 or earlier of > > the other SharedCLibrary isn't lurking around anywhere.
> We really shouldn't be having these problems with such an important > module...
> James
How true - I had 90% decided to buy an A9 - that's just dropped to 50%, I'll cetrainly be putting it off from buying next month........ - I don't have the time or interest to be sodding around in !Boot just to get things to work......
ROD & Castle need to get their act together *now*, as a user I don't give a dam about any petty squabbles, 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.........
Richard -- www.beamends-lrspares.co.uk sa...@beamends-lrspares.co.uk Running a business in a Microsoft free environment - it can be done Powered by Risc-OS - you won't get a virus from us!! Boycott the Yorkshire Dales - No Play, No Pay
> In message <4db27493e5j...@cartmell.demon.co.uk> > John Cartmell <j...@cartmell.demon.co.uk> wrote: > > In article <7af638b24d.dr...@druck.freeuk.net>, > > druck <n...@druck.freeuk.com> wrote: > >> One of the early A9 adoptors had a harddisc problem and reported there > >> were able to get DiscKnight to run after commenting out the RMEnsure > >> line, and it appeared to run correctly.
> > Some programs (not DiscKnight IIRC) try to RMEnsure a RISC OS 5 module > > but run OK without the RMEnsure. If they ran OK without the module > > then maybe that was there specifically to check that it was running on > > an Iyonix? Shouldn't they be making a generic check for 32-bit (and > > even then only if they are special programs like DK and need that > > info) - rather than for a specific machine? > I doubt there are any programs REQUIRING 32-bit mode. There may be a > few programs REQUIRING an Iyonix.
[Snip]
Very many thanks for taking the time to respond Martin.
If I read it correctly it's the reliance on Castle's CLib that is central to the problem. I understood that, in most cases, there wouldn't need to be "extensive rework" to use the freely available StubsG and it could easily be done by the author making their software available across all currently supported RISC OS machines.
-- 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
> I doubt there are any programs REQUIRING 32-bit mode. There may be a > few programs REQUIRING an Iyonix. Therefore, a generic check for > 32-bit mode in the !Run file does not make any sense. Regarding > DiskKnight: Contrary to your assumption, DK is NOT a special program > that would care at all on which machine it runs. All it needs is the > Castle 32-bit CLib because it is linked with the Castle 32-bit Stubs.
> In general, this issue is very complicated because there are FOUR > loosely related things a program might want to check or enforce: > i) Iyonix vs. RISC OS 3/4/Select/Adjust/Adjust32 > ii) 26-bit vs. 32-bit operation > iii) 26-bit CLib vs. 32-bit CLib > iv) ROL Clib vs. Castle CLib > and there are TWO main places where such checks are done: > A) In the !Run file > B) in the main application code.
> Which makes 8 combinations. Depending on the place, it is easy or > difficult to make the one check or the other, so quite often, an > easier check is used instead of a more complicated one and the result > is inferred based on certain assumptions. This is unfortunate but has > happened in many programs, including my own. For instance, in ARM > code, it is very quick to test the processor mode and slightly more > difficult to check module versions. So, the usual assumptions were: > [32-bit mode => Iyonix] and [32-bit mode => Castle CLib], both of > which are no longer true on the A9. Conversely, in the !Run file it is > difficult to check the processor mode, so the usual assumption was: > [UtilityModule < 5.00 => 26-bit operation], which is no longer true. > The same goes for CLib. The usual assumptions are [CLib < 5.17 => > 26-bit CLib], [CLib < 5.17 => ROL CLib], [CLib >= 5.17 => 32-bit > CLib], [CLib >= 5.17 => Castle CLib], and [32-bit CLib => Castle > CLib], the first and last of which are no longer true on the A9.
> > Do you know which RMEnsure line wasn't needed in DiscKnight? OK I know > > the Iyonix was the only 32-bit machine when you wrote the program (if > > that was the case there) - but I don't understand the need to check > > for a module when it will work without the module.
> You misunderstood. The RMEnsure reference in DiskKnight was for the > 32-bit CLib. The line in DiskKnigh is the official way of testing and > ensuring a 32-bit CLib. The same line is found in many programs > (including most of my own).
> Unfortunately, you cannot see from this line whether the program > wanted to check for iii) or for iv). Some programs DO require the > Castle CLib, some only require some 32-bit CLib. In the former case, > you cannot simply remove the RMEnsure, in the latter case you can.
> The only way to avoid the CLib headaches at the moment is to link with > StubsG and then not check for any CLib in the !Run file at all. > Unfortunately, this requires lots of programs to be recompiled and > relinked by their authors, which not all will want to do. If the > program uses C99 features, it depends on the Castle CLib and may > require extensive rework to make it work with StubsG (just done that > for EasiWriter but there are still issues with the A9 version).
> Alternatively, if a way was found to softload the Castle CLib on the > A9, then most software could run unchanged.
> Martin
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
and so forth for all the permutations that might matter to RO programmers, either now or in the foreseeable future? Then the problem merely becomes one of parsing a few system variables.
I'd be glad to set such system variables manually, (if I knew how best to present them for the programmers' maximum convenience) but obviously a runnable utility that did a full suite of tests would simplify matters for non-technical users. I would suggest taking the presence of Aemulor into account as well.
-- Simon Smith
When emailing me, please include the word 'Usenet' in the subject line, or your message will be deleted unread. Or use my preferred email address, which is on my web site at http://www.simon-smith.org
> How true - I had 90% decided to buy an A9 - that's just dropped to 50%, > I'll cetrainly be putting it off from buying next month........ - I don't > have the time or interest to be sodding around in !Boot just to get things > to work...... > ROD & Castle need to get their act together *now*, as a user I don't give a > dam about any petty squabbles, 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. The present problems are caused by the forking of the OS with RO5 and would have been worse had it continued. Your worry about the A9 is hardly likely to be realised - much software works immediately and more when developers amend their Iyonix-specific !Run files. And the A9 hasn't even been given a retail release yet.
-- 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 <4db27e8bc4j...@cartmell.demon.co.uk> John Cartmell <j...@cartmell.demon.co.uk> wrote:
> In article <88bf79b24d.mar...@bach.planiverse.com>, > Martin Wuerthner <spamt...@mw-software.com> wrote: > > In message <4db27493e5j...@cartmell.demon.co.uk> > > John Cartmell <j...@cartmell.demon.co.uk> wrote:
> If I read it correctly it's the reliance on Castle's CLib that is > central to the problem.
There are extra features in the Castle CLib that some programs use - so if you want to use the StubsG library extra programming may be required - and then the program would have to be tested over again.
Probably requiring access to a 26bit and a 32bit machine & maybe a second 32bit machine - for testing.
Far easier in my opinion to use one CLib module for RO3.1 - RO5.x including VRPC.
> I understood that, in most cases, there wouldn't need to be "extensive > rework" to use the freely available StubsG and it could easily be > done by the author making their software available across all > currently supported RISC OS machines.
This this info - I presume comes from you programming in 'C' :-|
It does't help those who don't have access to the 'C' sourse code - and want to 32bit programs that others have abandoned..
Someone with a Iyonix and a A9 - could perhaps use a utitily like 'RMSave' and save out the Iyonix CLib and run it on the A9 and see if the 'C' programs still work.
Only one CLib is allowed to be run - other than the one in ROM.
> On 30 Sep in comp.sys.acorn.programmer, beamendsltd > <beamends...@btconnect.com> wrote:
> [Snip]
> > How true - I had 90% decided to buy an A9 - that's just dropped to 50%, > > I'll cetrainly be putting it off from buying next month........ - I don't > > have the time or interest to be sodding around in !Boot just to get things > > to work......
> > ROD & Castle need to get their act together *now*, as a user I don't give a > > dam about any petty squabbles, 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. The present problems are caused by the forking > of the OS with RO5 and would have been worse had it continued. Your worry > about the A9 is hardly likely to be realised - much software works immediately > and more when developers amend their Iyonix-specific !Run files. And the A9 > hasn't even been given a retail release yet.
The point is I can't even contemplate being without a computer - the work involved in transferring even one days trading, and the obvious inability to respond to on-line orders and query's, is far too scary - manual back-up systems are great, but eveything still needs to go on to the computer at some stage......
I was going to buy one under the pre-release scheme thingie, as the retail release date is still slipping every month and I need to decide once and for all soon whether to stay with ROS or move to the Dark Side, I can't put off the decision indefinately. Asking around, I'm was led to believe that the A9 would be ok for what I need in it's current state.
Now I'm not convinced...... and "The Keepers Of The OS" *still* being stupid does not inspire much confidence.
Richard
-- www.beamends-lrspares.co.uk sa...@beamends-lrspares.co.uk Running a business in a Microsoft free environment - it can be done Powered by Risc-OS - you won't get a virus from us!! Boycott the Yorkshire Dales - No Play, No Pay
> In article <88bf79b24d.mar...@bach.planiverse.com>, > Martin Wuerthner <spamt...@mw-software.com> wrote: > > In message <4db27493e5j...@cartmell.demon.co.uk> > > John Cartmell <j...@cartmell.demon.co.uk> wrote:
> > > In article <7af638b24d.dr...@druck.freeuk.net>, > > > druck <n...@druck.freeuk.com> wrote: > > >> One of the early A9 adoptors had a harddisc problem and reported there > > >> were able to get DiscKnight to run after commenting out the RMEnsure > > >> line, and it appeared to run correctly.
> > > Some programs (not DiscKnight IIRC) try to RMEnsure a RISC OS 5 module > > > but run OK without the RMEnsure. If they ran OK without the module > > > then maybe that was there specifically to check that it was running on > > > an Iyonix? Shouldn't they be making a generic check for 32-bit (and > > > even then only if they are special programs like DK and need that > > > info) - rather than for a specific machine?
> > I doubt there are any programs REQUIRING 32-bit mode. There may be a > > few programs REQUIRING an Iyonix.
> [Snip]
> Very many thanks for taking the time to respond Martin.
> If I read it correctly it's the reliance on Castle's CLib that is central > to the problem. I understood that, in most cases, there wouldn't need to be > "extensive rework" to use the freely available StubsG and it could easily > be done by the author making their software available across all currently > supported RISC OS machines.
Unless, of course, the developer wants to use any of the 300 or so functions which are present in Castle's CLib and not ROL's; at which point attempting to build against StubsG will require various levels of code rewriting and wheel reinvention.
As for the RMEnsure lines in application Run files, they're the recommended incantation from the C tools documentation. Unless I'm much mistaken, the same advice was given with the beta 32bit tools distributed by ROL.
As for what happens if you try to run a program that needs the library chunks that contain the functions mentioned above, I believe the program aborts with an "Unknown library chunk" error message (that's token C02, for those who care).
In article <98a385b24d.cfer...@cferris.freeuk.com>, <cfer...@freeRemoveuk.com.invalid> wrote:
> Probably requiring access to a 26bit and a 32bit machine & maybe a > second 32bit machine - for testing.
It's hardly an answer to the specific problem, which I'm sure will be solved - but any software developer who can get to our Qercus office is welcome to use our range of equipment on which to test their programs. A small contribution but it may help some.
-- 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
> > I understood that, in most cases, there wouldn't need to be "extensive > > rework" to use the freely available StubsG and it could easily be > > done by the author making their software available across all > > currently supported RISC OS machines.
> This this info - I presume comes from you programming in 'C' :-|
You probably guessed correctly that it doesn't! -;) It does come from a couple of people who do do program in C quite successfully though.
> It does't help those who don't have access to the 'C' sourse code - and > want to 32bit programs that others have abandoned..
I understand that these problems only arise with programs compiled since the Iyonix surfaced so production of 32-bit generic versions will be no more difficult than producing one for just the Iyonix or just the A9. If that's not possible then you can use Aemulor on the Iyonix and A9.
[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
> On 30 Sep in comp.sys.acorn.programmer, beamendsltd > <beamends...@btconnect.com> wrote:
> [Snip]
>> How true - I had 90% decided to buy an A9 - that's just dropped to 50%, >> I'll cetrainly be putting it off from buying next month........ - I don't >> have the time or interest to be sodding around in !Boot just to get things >> to work......
>> ROD & Castle need to get their act together *now*, as a user I don't give a >> dam about any petty squabbles, 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. The present problems are caused by the forking > of the OS with RO5 and would have been worse had it continued. Your worry > about the A9 is hardly likely to be realised - much software works immediately > and more when developers amend their Iyonix-specific !Run files. And the A9 > hasn't even been given a retail release yet.
Let's not forget the A9 version of Aemular, which works very well.
Regards -- Paul Stewart - Bletchley, Milton Keynes
> 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
This really shouldn't be necessary. The vast majority of software, I suspect, will only need either any old SharedCLibrary (in which case they can link with StubsG) or Castle's C99 SharedCLibrary (in which case they can link with its stubs).
What is needed is a 32bit Castle SharedCLibrary which will work on everything. Whether this requires an alteration to Adjust32 or to the SharedCLibrary, I don't know, but at least one of them is at fault.
> On 30 Sep in comp.sys.acorn.programmer, beamendsltd > <beamends...@btconnect.com> wrote:
> [Snip]
> > How true - I had 90% decided to buy an A9 - that's just dropped to 50%, > > I'll cetrainly be putting it off from buying next month........ - I don't > > have the time or interest to be sodding around in !Boot just to get things > > to work......
> > ROD & Castle need to get their act together *now*, as a user I don't give a > > dam about any petty squabbles, 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. The present problems are > caused by the forking of the OS with RO5 and would have been worse had > it continued.
No, that is your opinion and the opinion of some others. Don't make sweeping statements.
> Your worry about the A9 is hardly likely > to be realised - much software works immediately and more when > developers amend their Iyonix-specific !Run files. And the A9 hasn't > even been given a retail release yet.
And much software doesn't, mostly because of this precise issue.
----== 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 <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.
As I also named, the only solution is for some party to make available a SCL for the A9 which does. Presumably Castle, but other options exist such as an open source version.
----== 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 <4db2a07097steve.pampl...@dsl.pipex.com> Steven Pampling <steve.pampl...@dsl.pipex.com> wrote:
> 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.
Sigh. It's really very, very simple[1]:
1) The SharedCLibrary in Adjust32 is a 32bit version of the one present in the 26bit Adjust (it may well have had other improvements besides being 32bitted but, as I've not seen it, I can't comment, nor is that relevant to this discussion).
2) The SharedCLibrary available for download from iyonix.com is _not_ 32bit compatible. Therefore, it won't work on an A9 because the A9 is running in 32bit mode (nor, incidentally, would it softload on an Iyonix, for the exact same reason).
3) Existing applications which use the SCL and which are able to run on 32bit machines come in two possible forms:
a) Linked against StubsG. b) Linked against the Castle stubs.
4) Applications which fall into category "a", above, should work perfectly well on the A9 (as they're already mode neutral and don't care about the SCL that they're using)
5) Applications which fall into category "b", above, are more complex:
i) They may only use the functionality of the SCL which is provided by the 26bit variants and that on the A9. ii) They may use the enhanced functionality present in the Castle SCL.
Both categories of application currently perform something akin to:
RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib RMEnsure SharedCLibrary 5.34 Error Foo needs SharedCLibrary 5.34 or later
in their !Run file and therefore will not immediately run on the A9 (as the SCL version check will fail).
So, it is only applications that are covered by point 5 that will have difficulty running on the A9:
a) Applications in category 5i may work perfectly well already, if the SCL version checking is removed from their Run file. I don't advise doing this as it could well have unforeseen side effects.
b) Applications in category 5ii will not work, even with the SCL version check removed (as I documented in another post in this thread, the application will abort with the message "Unknown library chunk")
So, what are the solutions to the above mess?
a) Application developers could rebuild their code against StubsG. For applications in category 5i, this is likely to be highly trivial. For applications in category 5ii, the amount of work and/or wheel reinvention required depends upon the application.
b) Castle could release a 32bit compliant build of their SCL which can be softloaded on the A9.
I'll leave you to decide which of the solutions is likely to result in A9 support for the most applications in the shortest possible period of time.
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?
> The present problems are caused by the forking > of the OS with RO5
No it is *not* !
The Castle 32bit SCL existed *before* the A9's one. It is the "defacto" standard for developers producing 32bit neutral code (many of whom use Iyonix). The characteristics of Castle's SCL are *known*. ROL had three years to match them - they did not.
ROL should have done their best to ensure their SCL was compatible for code built to use the Castle 32bit SCL.
They sadly didn't.
>Your worry about the A9 is hardly likely to be realised - much software works > immediately and more when developers amend their Iyonix-specific !Run files.
That won't fix C99 compatibility in cases where code uses it. As to the A9 it can't currently run all the code Iyonix can and this would tarnish it's appeal somewhat unless this problem is resolved. I hope ROL have enough wisdom and wit about them to do the needful to address this, but as ever only time will tell.
> John Cartmell wrote: > > The present problems are caused by the forking > > of the OS with RO5
> No it is *not* !
> The Castle 32bit SCL existed *before* the A9's one. It is the "defacto" > standard for developers producing 32bit neutral code (many of whom use > Iyonix). The characteristics of Castle's SCL are *known*. ROL had > three years to match them - they did not.
The SCL isn't part of RISC OS 5, but part of the C/C++ development suite, which Castle obtained from Pace and have been developing further. Access to new versions are obtained by a subscription scheme (sound familiar?).
We are now benefit from the new C99 features which have been introduced, significant performance improvements and many bug fixes to the compiler and associated tools.
This is the preferred version used by developers, and requires the Castle 32bit SCL and stubs. Code may work with the 26bit SCL and ROLs 32bit if compiled with the -c90 flag and linked against StubsG. However there are significant danagers of using stubsG which I have detailed in the past, and it should be avoided.
> ROL should have done their best to ensure their SCL was compatible for > code built to use the Castle 32bit SCL.
> They sadly didn't.
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. Indeed the version 4 compiler was still used for some parts up to a couple of years ago.
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. This in itself would still require a large amount of QA as the 32bit code is be signifincantly different from the 26bit even from the same compiler.
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.
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. This then will allow all existing 32bit compiled code to work, with out risk of missmatch with the ROL one. There may of course still be other problems with software on the A9 due to other API differences between RO5 and Adjust32.
|
