hzn (+0.1)
18/3/06 8:38AM |
Good news and bad news in one:
1. Good that this issue is being addressed and perhaps the new library will then even be happy with other compilers and as time passes by join the CLib and UnixLib in one?
2. Bad news since I hoped that the issues as for the A9 to be a formal product were solved by now. |
nodoubt73 (+1.0)
18/3/06 9:53AM |
As already discussed in the comments of "Investing in RISCOS Ltd..." poll, this news really brings sadness.
Quoting the above news:
"The SCL is a core operating system component that provides applications with a fundamental level of functionality"
This means there's such a mess in RiscOS world that such an important componet is being developed by.... an INDIPENDENT
PROGRAMMER.
Hail  to Graham, but how could an OS pretend to fight market when it's all about an indipendent programmer???
Ofcourse, add all the points we did raise in the poll discussion.
This is taking us nowhere. Really.
Little OS, barely known, no real HW supporting it, and now we must rely on a private progammer to have somethign
working.
This sounds bad, really bad. |
Sawadee (+0.6)
18/3/06 10:28AM |
Well I guess that an independent programmer like Graham may give RISC OS a 1% chance which is better than zero.... or a minus number factor 
While there may be so so many things that Windows can do that RISC OS can not do these days, I have recently come to the conclusion that there are still lots of good points about my old 1994 RiscPC 600 with RISC OS 4 that are really good.
My recent conclusions resulted from some of my dumb questions about PC to my IT teacher to make it work like RISC OS. Yes, I not kidding how dumb but the answers were no, no no.... impossible or not really the way to do it!
One question was, can I stop my laptop PC from that stupid shutdown where it writes back my settings to the hard disk.
My RISC OS does not do that and it is annoying on the PC when I make errors and it save all those wrong settings.
My IT teacher says it can't be done, Windows must save all your changed settings (even if they were an error! I asked) or you will lose them.
But I rarely ever want to change the desktop of style settings, if I do I like to manually change that one or two just like I do on RISC OS.
Well, I got nowhere with that one. Does anyone out there know the answer or has a solution to stop Windows from messing me up on that?
Steve. |
adamr (+0.3)
18/3/06 10:36AM |
In reply to nodoubt73:
"This sounds bad, really bad"
I disagree. What's the problem with the development of an open-source alternative to a module? If it's successful the OS developers can concentrate on other areas and it might even lead to new functionality as Graham hints at above.
I really fail to see the problem. In fact, re-reading your post, I'm not even sure how to properly respond to you since apart from shouting about "independant" programmers (so what?) I can't make out what your arguments are.
Adam |
bluenose (+1.1)
18/3/06 10:52AM |
Great though it is to see Garham taking up doing a new SCL, I tend to agree with NoDoubt73 on this one.
What we need is consolidation of RISCOS not yet more fragmentation. ROL and Castle should really get this sorted out starting with the release of a common SCL and Toolbox set that is used by ALL version sof RISCOS.
The release of the A9 and Select4 should be the start of this consolidation. |
gdshaw (+3.4)
18/3/06 11:26AM |
In reply to nodoubt73:
By your reasoning the UNIX-compatible market should be in a far worse state than RISC OS. Not only have most of their users deserted the official C library for glibc, they went and replaced the rest of the OS too.
In reply to bluenose:
Fragmentation is an issue which I am very much aware of, which is why any changes to the interface have to be very carefully thought through.
A good example of what I have in mind is better cooperation between the SCL and UnixLib when a program using one calls a program using the other.
This doesn't break the documented interface, and is much more likely to fix undesirable behaviour than to cause it.
The having several implemtations of the SCL is not a problem. Having different interfaces is. |
Cogs (+0.3)
18/3/06 12:50PM |
I don't see what the fuss about. Sure, technically it's duplication of effort, but if it leads towards a more open RISC OS this can only be a good thing. |
SimonC (+2.1)
18/3/06 3:34PM |
In reply to Cogs:
Only because the people who are supposed to be moving it on don't always seem to be getting on with that. |
cmj (+0.9)
18/3/06 5:51PM |
The big problem with having two Shared C Libraries is you can't have both installed at the same time. If some things require the RISCOS Ltd one and some things require the Castle one you have a problem. This isn't such a problem with Linux (and to some extent Windows), as you can have different version of the same library installed. |
hzn
18/3/06 6:46PM |
In reply to most and especially to cmj:
I think your did put your finger into the interesting issue: RISC OS does not allow for different Shared C Libraries in use at the same time as is easy in Linux. Adding to this the fact that there are two of them around, both are official by OS suppliers and the two suppliers seem to not want to co-operate. Perhaps this could work: Write a CLib loader for the ROL and the CTL CLib which replaces the SWI bases and Module names thus allowing both to be loaded and a new CLib module which is a wrapper for both.
Thus I applaud Grahams intention and I hope that his library will be happy to work with all three Stubs, i.e. the ROL one, the CTL one and with StubsG. Pity this is necessary due to the A9home not considered to be a valid product. |
ajb (+1.1)
18/3/06 7:27PM |
Have I missed something.
In an earlier Drobe article, dated 18th Jan 2006, Castle's John Ballance stated:-
"that when the A9 is a formal product Castle will be happy to release an appropriate SharedCLibrary".
If this course is not followed, surely all applications will have to be written to check which of the three SCL modules is installed and have separate code to be used for each. |
adamr (+0.2)
18/3/06 10:56PM |
In reply to ajb:
"Have I missed something" Yes 
With regards the Castle statement, Graham says specifically in the article above that that is not the reason he's developing an open source CLib.
Your second point is also way out. If the APIs are the same, then the applications which use the module needn't care which module is loaded. This is already the case on a RiscPC where most applications work quite happily regardless of whether the Castle or ROL module is present.
Adam |
Sawadee (+1.0)
19/3/06 1:46AM |
*In reply to adamr:*
I agree with what your comments say, no problems with extra help.
The extra help no matter if it is big or small Graham still contributes to free up programmers for other much needed work.
This is the sarcasm I mean by my comment "1% is better than zero..." otherwise without and support we are in the "MINUS %"?
While Windows is ahead in many ways, RISC OS still has it's unique difference that is "peace of mind" to the user, it just need a lot of catch up.
I don't think that I would like to see RISC OS become too like Windows (style guide wise), just be able to do anything you need it to do is all we need.
Steve. |
arenaman (+1.0)
19/3/06 12:44PM |
"just be able to do anything you need it to do is all we need"
That would require more powerful hardware (to do nice things with DVDs and audio), some expensive software licencing (for things like a Flash player and Java virtual machine) and a concerted effort by developers to develop software to plug the gaps (of which there are many). I don't think it's going to happen... |
druck (+3.0)
20/3/06 9:36AM |
Right,
1) Any implementation following the Castle 32bit SCL pattern is full compatible with all correctly written programs linked against the new 32bit/C99 stubs, the old 26bit/C90 stubs, and ROL's intermediate C90 stubsG used in 26bit or 32bit modes.
2) It is ridiculous this has become necessary to support the A9, all three parties involved need putting in a room and given a good kicking until the correct licences are sorted out, and an officially supported 26/32bit C90/C99 SCL is released for all RISC OS machines.
3) An open source implementation of the SCL would still be useful in some other ways so it wouldn't be a complete waste of time even if the official version gets sorted out. For example easier debugging of callback based code, and also to allow core SCL functions to be performed natively on emulators. |
SimonC
20/3/06 10:10AM |
In reply to arenaman:
In the case of DVDs isn't more a case of being able to access the hardware we already have (in the Iyonix, at least), rather than needing more powerful hardware? Most other platforms don't have to rely on it all being done in software. |
nodoubt73 (-0.1)
20/3/06 1:55PM |
In reply to adamr:
"bla bla bla ....shouting about "independant" programmers (so what?) I can't make out what your arguments are."
As I stated, I was connecting back to the interesting thread after the poll *Investing in RISCOS Ltd*, a poll you didn't post a single line
and probably missed (?).
I've nothing against this programmer developping something. It's ok. But Where is RiscOS going if one of the most important libraries
are not clearly supported by a real company?
All written above (when replies go over unix topic, the fact that riscos allows to "switch" between more than one SCL easily....) is correct and I agree. And even like it, just because I use RiscOS for fun, I use RiscOs because I like it and am interested in computers. But when we pretend to have
an OS that should placed by the side of Win or Mac, how could we stand these facts? I mean, Mr.User will ever be able to switch between different
SCL?
It's all ok, if WE use RISC OS. But RiscOS market won't get out of where it is stuck now.
That was my point. |
druck
20/3/06 4:43PM |
In reply to nodoubt73:
I repeat; there is no need to ever switch between SCLs, when a 32bit-C99 and 26/32bit-C90 SCL is available. The RISC OS way is to have a single active copy of a module, which if introducing new features must maintain backwards compatibility. This avoids the situations on other platforms where half a dozen mutually incompatible versions of the same shared library must be loaded by different applications. |
gdshaw (+1.0)
20/3/06 5:30PM |
In reply to nodoubt73:
I may not be a real company, but I am a real person.
In any case, anyone can support a program once it has been released as open source. Surely that is better than being dependent on a single company? |
nodoubt73 (-0.1)
21/3/06 7:36AM |
In reply to gdshaw:
I may not be a real company, but I am a real person. In any case, anyone can support a program once it......
I know you're a real person. The problem is that RiscOs exists "thanks" to real companies.
I'd be the 1st one going for an open source RISC OS. The problem we have is that there are coupla companies out there that should do
things like the one you're doing... or, at least, should pay you for that.
I repeat: it's ok for me. Write what you want and even send it to me so I'll be another tester for your work. This is fine. Let's re-write every single
library and modulee. I am fine with that. But then we should stop all those topics about RiscOS vs others OS, on a matter of market share. Let's stop with everything.
Ah, we should even start building our own hardware at home |
gdshaw (+2.2)
21/3/06 11:30AM |
In reply to nodoubt73:
I have full confidence that ROL and/or CTL will resolve the Shared C Library issue by the time the A9 becomes a fully released product. At most this project it a bit of friendly competition.
What I presume they won't be doing is releasing the source code to their versions, and that's where I can make a difference. |
nodoubt73
21/3/06 3:27PM |
In reply to gdshaw:
well, good luck |
| |
An alternative Shared C Library module suitable for both A9 and Iyonix users is currently in development by an independent programmer. Graham Shaw, also known for his work on 
