At a time when things are beginning to lookup for RISC OS it appears as if some (ROL/VA/MD for example) seem intent on moving it over to Windows.

As I see it the "worse case" scenario (no RO native hardware) I'd suggest a portable microkernel that is compatible with the HAL in RO5 - then it might be possible to port RO without the inherent bloat of Linux (no offense intended - but it seems a bit over the top to have to run one whole OS in order to use another one !!!!).

As we've not reached the worse case scenario (and hopefully will not) how about supporting the RO hardware vendors who still prove there *is* an alternative to the PC and Windows.

As we've not reached the worse case scenario (and hopefully will not) how about supporting the RO hardware vendors who still prove there *is* an alternative to the PC and Windows.

Ah, the thing is, I don't much care if RISC OS survives, as long as I can
use a sufficiently similar GUI.

The approach I'm suggesting is a very usable and easy to learn alternative
to KDE and Gnome for Linux; perhaps some applications will be developed
specifically for it, others would be ported (from RO or Gnome/KDE) and all
the other Linux applications would be available via an X server.

The hardware would never fall far behind, since it runs on standard hardware
*as well as* ARM hardware. It's also not an impossibly huge job (providing
much of the functionality of the RO API using GNU/Linux libraries).

At a time when things are beginning to lookup for RISC OS it appears as if some (ROL/VA/MD for example) seem intent on moving it over to Windows.

That's just not true though is it? It's a fun way to interpret the "Alpha" portable if you like to discredit the non-Castle part of the market, but that's all.

Is the effect of providing a laptop and emulation software, WindowsXP and Select 3 a thing that will make it *easier* for people to (in effect) move to Windows the answer *must* be yes.

First off the laptop is expensive enough (soaks up some money people might have kept for buying *actual* RISC OS compliant hardware (the curious one in this is that would also hit *MD* - why would they do something that damages their own soon to be released Omega ?). Then you have the slice for VA and ROL - and (the bigger slice of the software component of the sale) to Messrs Gates and Balmer.

The least damaging option would have been to make RO4/Select3 + VA available for existing PC laptop owners (that at least doesn't suck as much money out of the RO market).

As to RO on another platform (aka the worst case scenario) then a limited kernel/ARM processor emulator is the way to go. Yes Linux is more bloated than RO - but no where near as badly as (say) Windows, but the point is can we do better than Linux ?

I mean VA needs a raft of specific Windows calls to do what it does, there is *still* no full RO emulation on Linux - it would therefore be more sensible (IMHO) to produce low level x86 (or whatever) kernel - with an ARM (just the processor) emulated (the other hardware can be handled by the HAL and the relevant drivers). You'd probably wind up with something that runs rings around VA (I stress not due to any deficiency in VA - I am rather impressed with it - but rather that you'd have cut the middle man (Windows) out of the process.

If you honestly believe that anyone using RISC OS couldn't, if they wished, move all their essential computing across to Windows at relatively low cost, you're in a dream world.

People use RISC OS because they like it, and possibly in one or two cases, because they've invested a lot in it and can't afford to move. A Windows laptop won't suddenly change any of that.

You might as well say that RComp are intent on moving people to Windows with their UniPrint and other Windows-specific netwroking products - it all makes it easier to use Windows alongside RISC OS and so clearly encourages the use of Windows, no?

The portable is exploiting the market for a RISC OS portable, and no one is likely to say "I really want to pay £1000 for a mid-range Windows portable which can just match the speed of my current RiscPC under emulation" unless they actually want a portable.

It would be a mammoth job however you chose to do it, and trying to implement it on top of the smallest kernel you can find wouldn't make it any easier to access the range of graphics cards, sound devices, NICs, etc. that are out there.

Anyway, that has nothing to do with the thread really, which was about re-implementing something with a GUI at least as good as RISC OS rather than finding ways to emulate RISC OS better.

Open source RISC OS is stupid. Get you heads screwed on.

Open Source RISC OS _is_ Stupid.

Let's state the reasons:

It's not as if RISC OS isn't being actively developed (BeOS for example) - it is, by two parties with a commerical interest in improving it.

No disrepsect, but most of the people posting to this thread don't really understand OS design. Much the same was true when such a thing was attempted 2 years ago as a result of a similar thread here. It never got off the ground for lots and lots of reasons, but this was an underlying theme.

Doing an OS from scratch (or substantially from scratch or some variation thereof) is an enormous amount of effort. Let's say 20 people full time for 3 years, then we might be thinking about the first alpha.

The same effort applied to RISC OS in terms of applications, utilities, promotion of the OS itself would have an *ENORMOUS* impact on the ability of the OS to grow, and be useful to a much greater audience.

But then, I fear that I will fail to convince those who think an OS RO is the way forward.

Open Source RISC OS _is_ Stupid.

A great soundbite but lacking in context, meaning and justification.

It's just that people are concerned that aside from the remedying of various architectural showstoppers, there isn't any hardcore re-plumbing going on in the bowels of the operating system itself.

Doing an OS from scratch (or substantially from scratch or some variation thereof) is an enormous amount of effort. Let's say 20 people full time for 3 years, then we might be thinking about the first alpha.

And for many people, that isn't interesting for the reasons also given by certain contributors in this thread.

The same effort applied to RISC OS in terms of applications, utilities, promotion of the OS itself would have an *ENORMOUS* impact on the ability of the OS to grow, and be useful to a much greater audience.

That depends on whether you're a man on an impossible mission.

Open source RISC OS is stupid. Get you heads screwed on.

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving)

It's possible, of course, that a brand new Open Source Windowing Sever will never happen and you'll end up implenting OpenSourceDecentGUI as an X11 library, with yet another window manager and session manager...

Of course, you'll never end up doing any of this, so it's largely academic.

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort

That's simply not true. I've already demonstrated that with my porting project. And Unix programs are emminetly more portable than RISC OS programs for lots of reasons.

Forget unique selling points (bit I snipped) - RISC OS needs fundamentaly important points such as big applications.

Yes, but what about all those POSIX-like APIs

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.

Now consider RISC OS, consider what would happen if it were replaced by something comparably better, and consider the change in mindset that

Yes, but what about all those POSIX-like APIs

Relatively few.

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.

Having studied the matter in a great deal of detail, this is an utterly ridiculous conclusion.
Because RISC OS programs are so unportable in comparison.

Now consider RISC OS, consider what would happen if it were replaced by something comparably better, and consider the change in mindset that

Which, as we say, is nothing other than academic because people aren't willing to take on board the practicalities. They'd prefer hand waving and talking instead.

And indeed, hiding behind nicks like "GuestX".

Yes, but what about all those POSIX-like APIs

Relatively few.

Well, isn't threading one of the big ones with respect to various client applications?

was that by choosing a UNIX-like operating system as the foundation, with some kind of non-X11 graphics system on top, it's easier to port things to the operating environment in question than it is to RISC OS.

The contributor whose suggestions you were busy criticising wasn't merely (if at all) discussing the portability of the few RISC OS applications that anyone would be bothered to port to his UNIX-based environment;

Anyway, on the subject of making RISC OS applications work in his environment, we can already see emulators doing a fair job of that.

And indeed, hiding behind nicks like "GuestX".

I find that people who post with their real name are automatically granted much more of a realistic world-view. Oh, hold on...

Now consider RISC OS

At which point we discover the gap between reality and your view of the situation. pthreads is being actively worked on for Unixlib, and isn't exactly a "Big API". There's very little else that doesn't already have some kind of support and couldn't be improved.

The contributor whose suggestions you were busy criticising wasn't merely (if at all) discussing the portability of the few RISC OS applications that anyone would be bothered to port to his UNIX-based environment;

But I was. The question is implicit, and underlies the whole argument.

What I was suggesting was an Open Source GUI for Linux that allows Linux programs to be written in the style of RISC OS WIMP programs.

Given a Filer and an X Server, I believe this would be a good environment to work in.

Significant applications (e.g. web browsers) could be incrementally "ported" by modifying the GUI behaviour (starting with file loading/saving); porting them to RO is significantly more effort and doesn't provide a unique selling point for RO since the original is already available on Linux.

Anyway, on the subject of making RISC OS applications work in his environment, we can already see emulators doing a fair job of that.

No, that's a _completely_ different topic, and has no place in a discussion like this. Emulators are emulators, and they do _NOT_ help provide an open source RISC OS on any platform. The technologies are very disctinct.

It gives you some kind of credibitlity, instead of sitting anonymously on your high hourse and dishing out random declarations about what can and can't happen.

No, that's a _completely_ different topic, and has no place in a discussion like this.

But as I say, your comments continue to demonstrate that all you want to do is talk, and in some cases above, facts and practicality be damned.

Right, this is where you're completely wrong.

I was thinking along the lines of using DirectFB (http://www.directfb.org/) as the basis for the BNSOSWS. They've already written an implementation of GTK+ for it, at least.

Why couldn't I search for, e.g. "gtk_file_selection_new" in an application and modify that part of the code to use a different set of widgets including an icon to drop on a Filer window?

You originally said that you wanted a way to be able to write in the style of RISC OS WIMP applications.

You haven't addressed the concern of having more than one toolkit.

GTK may be nice, but it doesn't make for RISC OS' style. You'd be looking into a new toolkit, which is why I suggest that incremental porting won't work.