What does RISCOS bring to the RPi party

Also, there is a huge world wide and still growing community supporting Linux and there has been for a long time.

I can not argue that.
Though do you remember Linux as it was in he ealy 1990s? Very obscure and off to the side.

Even though RISC OS is older than Linux, it has never before got much exposure outside of the UK. Now RISC OS is just beginning to get that exposure, this puts todays RISC OS in the same boat as the Linux of the early 1990s.

THOUGH: RISC OS has a huge head start, most Operating Systems that are just beggining to get exposure have almost no applications available for them. RISC OS on the other hand already has a huge library of software thanks to twenty-five years of development by those that use RISC OS. And RISC OS has the advantages that I previousely stated.

We can not know what the end result will be. Maybe it will become a quite common OS, maybe it will fade out, maybe it will stay lean and fast even if it gains wide spread use, or maybe it will go the way of Linux & Amiga OS and become bloated with out reason. We will have to see, I would love to see it become a reasonably common place OS and staying well written with good lean programms and modules.

Remember that in the mid 1990s the x86 CPU was the most used seris of CPUs in the world, no one would have believed that they would be displaced, now the ARM is way more common than any one could ever have dreampt, all in only 15years. Yet so many do not think that the OS that was developed along side of the ARM CPU, and desined for the ARM CPU should be given its fair shot?

It will take time to get the applications for RISC OS up to par with what is expected, though we have the opertunity to do this with out introducing unwanted and unneeded bloat. I do not think that any one would argue that RISC OS needs a bit of work, tough as it becomes better known this work is getting done more and more.

Well, I read this thread earlier today and was reminded of Usenet threads in the mid 90s...

However, I just wanted to thank the developers of this version of RISC OS for a wonderful effort. Only tried it today for half an hour and can honestly say I'm excited by this. As a user of RISC OS some time ago I'm fully aware of certain limitations. However, running !Draw on a very large desktop in 16 million colours was a very pleasant experience - interpolating two shapes in a millisecond was something I'd never seen before.

This OS really is very suitable for the hardware - after using Raspbian for a while with child, it was pleasant to see window redraw and responsiveness as quick as I remember from many years ago. And to find ChangeFSI in the utilities (now in Apps) was very pleasant.

Thanks again!

This OS really is very suitable for the hardware - after using Raspbian for a while with child, it was pleasant to see window redraw and responsiveness as quick as I remember from many years ago. And to find ChangeFSI in the utilities (now in Apps) was very pleasant.
!

Getting back on topic again, !FSI_Batch works beautifully with !ChangeFSI as well. Highly recommended. http://roevalley.com/newsbrowser/english/software.htm

What is the state of play with RISC OS and fork()? i.e. with UnixLib etc these days?

Most TCPIP based servers use a thread that listens on a socket. When something arrives it forks and one thread goes back to listening on the socket and the other thread deals with the request.

If I remember correctly RISC OS did not allow use of fork() and at the time this meant a big problem with porting server applications. Is that still the case or have things changed?

With UnixLib and pthreads what is to stop some non UnixLib based application not doing a Wimp_poll and locking things up. I have a vague recollection of some timer being used to issue a callback for the next time the system was called and it issuing a wimp_poll to avoid a process being able to lock the system out as it were.

What is the state of play with RISC OS and fork()? i.e. with UnixLib etc these days?

I know that UnixLib supports multithreading, though I can not remember the details at the moment. I do remember that there is a version that supports threads, and a version that does not, and in the version that does, it implements a subset of PThreads.

I think I remember reading that it uses the centasecond timer (or somthing like that) to do thread swaps.

Though I would imagine that it would b fairly simple to implement a fake method of threading under WIMP2 with out all of the buld that comes with UnixLib. I will look into this a bit and get back to you with a bit better information.

Ok, I can say for sure that UnixLib does suport threading to a limmited extent. Unfortunately there is a little more overhead than would be ideal.

And from experience WIMP2 works well, providing a Premptive Multitasking enviroment that still allows cooperative multitasking applications to run outside of the Preemptive envirement. You should be able to use WIMP2 to implement multithreading.

Some critisize WIMP2, though the only two things that I know of that are problems in WIMP2 are:
[list]
PROBLEM 1:) Patching binaries to use WIMP 2 when they were compiled to run in WIMP.
SOLUTION TO 1:) Do not patch the applications. Let them run in the original WIMP, they will still run
\ as Cooperative Multitasking apps outside of WIMP2.
PROBLEM 2:) WIMP2 makes Wimp_Poll calls on for the applications running under it at each task
\ switch and defers forwarding them until the application requests it. This can potentially lead to
\ issues with applications that wait to long getting an event incorect.
SOLUTION 2:) Code well writen applications.

FAIR WARNING:
I almost forgot WIMP2 will need to be updated to be useable on the RPi, I have been attempting to hunt down the source code to do this with out any luck so far. After doing looking into things a bit I may write my own PMWIMP (Preemptive Multitasking WIMP).

There is also this:
http://www.riscos.info/index.php/Special:AWCforum/?action=st%2Fid30%2FReplacement_RISC_OS_Components_Released_Under_GPL

I almost forgot WIMP2 will need to be updated to be useable on the RPi, I have been attempting to hunt down the source code to do this with out any luck so far.

http://www.nedprod.com/programs/RISC-OS ... index.html

Although I don't believe that it will provide a particularly satisfactory solution wrt threading etc

Nick

Still looking for an answer on support of Fork(). If Fork is not supported then that explains a lot. i.e it is not possible to just port a server application from Unix etc and needs to be rewritten and hence why a lot of Unix facilities are not available for RISC OS.

I think people have too much faith in Wimp2 as a panacea. From what I have read Wimp2 is anything but a panacea.

1) Applications need to be rewritten to have certain wimp events in a different thread.
2) There is a patch to avoid re-writing applications, but its a bit of a kludge and the result often has problems.
3) There are some applications that are just not going to multitask.

Running problem applications as standard cooperative is not a solution they can lock the whole system out by not calling wimp_poll for long periods of time.
i.e. It only takes one application that runs non multitasking to spoil the show.

Still looking for an answer on support of Fork(). If Fork is not supported then that explains a lot. i.e it is not possible to just port a server application from Unix etc and needs to be rewritten and hence why a lot of Unix facilities are not available for RISC OS.

I think people have too much faith in Wimp2 as a panacea. From what I have read Wimp2 is anything but a panacea.

1) Applications need to be rewritten to have certain wimp events in a different thread.
2) There is a patch to avoid re-writing applications, but its a bit of a kludge and the result often has problems.
3) There are some applications that are just not going to multitask.

Running problem applications as standard cooperative is not a solution they can lock the whole system out by not calling wimp_poll for long periods of time.
i.e. It only takes one application that runs non multitasking to spoil the show.

It is true that WIMP2 is far from a perfect solution. Remember that there are many server applications on Windows NT, and NT only garanties that a task wil be swiched out with in 3 minutes (180 seconds). Though as far as cooperative multitasking outsie of the Preemptive multitasking enviroment goes: this is one of the benifits of RISC OS, WE CAN SINGLE TASK when it is needed without the OS getting in the way.

So if you are doing stuff that requires multitasking do not run anything that is single tasking, or that forgets to call Wimp_Poll for long periods of time.

******** A NOTE **********
I have been studying this issue for some time: And I am thinking about writing a Preemptive multitasker that will allow you to dissable support for single tasking and add a safty by running all cooperative multiasking apps inside of a single preemptive task. Though this would require replacing a large portion of the WIMP.

this is one of the benifits of RISC OS, we can single task when it is needed without the OS getting in the way.

When would this be advantageous? I mean, the OS will be "getting in" the way regardless such as whenever there is a hardware interrupt (eg. hardware clock) or your code calls an SWI. Maybe on very limited hardware such as embedded systems it *might* be good to capture the entire system and go with it, but on the RPi (or even an RPC) when would it ever be a good thing?

I have run Linux on hardware far less powerful than an RPi and actually the scheduler tends to be pretty good. Even the argument that you might want to run some intensive task such as a game, given a good enough scheduling algorithm then it should still be able to service other tasks without a particularly noticeable drop in performance (and provide many benefits also.)

I suppose it is a question of control; I think the programmer has enough to worry about and the correct place to make choices about scheduling are on the target system during runtime which the user can tune.

Nick

There are very very few situations where single tasking is an adantage, usualy these have to do with precise timing beyond what even a Hard Real Time schedular can provide. As a result of the extreme rarity of this, in the above post I said:

******** A NOTE **********
I have been studying this issue for some time: And I am thinking about writing a Preemptive multitasker that will allow you to dissable support for single tasking and add a safty by running all cooperative multiasking apps inside of a single preemptive task. Though this would require replacing a large portion of the WIMP.

And I have every intention of following through with this. As point of fact I have put the development of my operating system on hold until such time that I succeed at this as well as some other tasks related to RISC OS, in order of priority with the highest priority first:

1:) Implement a good clean CPU Emulation layer for running RISC OS applications that are not 32-bit safe.
2:) Implement a preemptive multitasking enviroment in RISC OS, as well as rewrite enough of the WIMP to correctly support this.
3:) Write a utility for managing the FAT32 partitions, and FileCore filesystems on a SDCard so that another OS will no lnger be dneeded in this process.
4:) Port a WebKt based web browser, and optimize it for ARM CPUs.
5:) Replace the video driver components to allow correct support for all standard RISC OS modes inaddition to the native modes on the RPi.

There are very very few situations where single tasking is an adantage

On the contrary, if you're into robotics or physical computing in general, there are many, many situations where single tasking is not just an advantage, it's often vital.

RISC OS makes an excellent OS for such purposes because it can single task instantly, in the process offering a quiet, near real-time OS that's still just a couple of clicks away from a versatile, full GUI environment. Throw in BBC BASIC with its quick, easy interpreted code, in-line assembler and ability to access the very lowest levels of the hardware and IO ports, and you have a great package for physical computing.

And no bloat code, libraries or endless dependencies to bother about either.

On the contrary, if you're into robotics or physical computing in general, there are many, many situations where single tasking is not just an advantage, it's often vital.

RISC OS makes an excellent OS for such purposes because it can single task instantly, in the process offering a quiet, near real-time OS that's still just a couple of clicks away from a versatile, full GUI environment. Throw in BBC BASIC with its quick, easy interpreted code, in-line assembler and ability to access the very lowest levels of the hardware and IO ports, and you have a great package for physical computing.

That is one of the those very rare reasons. If you do this kind of thing frequently then it is common for you (and me to), I think that it probably is not so comon for 90% of the users out there. Though this is why I wish to make it a user choice to retain this ability even with the preemptive multitasker that I am working on.

And I guess this is as good as a place as any to give a bit of an update on the multitasker:
I have decided to go through everything and figure out what all of the possible issues with preempting existing tasks could be, figure out solutions, and have all WIMP tasks preempted AFTER THEY CALL Wimp_Poll the first time (thus alowing single tasking in the WIMP), and non WIMP applications will still be allowed to single task merrilly.

Also I have just berily began to rewrite the WIMP, this is going to be a huge task. Though it is made a litte easier and quicker because I chose to do it in 100% Assembly Language .

Though I am making significant progress on the CPU emulation for suporting older non 32bit safe programs. Thankfuly the ARM instruction set is fairly small.