The Elephant in the Browser

How so? Everything I’ve just read on that page is still pretty accurate.

RISC OS is co-operatively multi-tasked
Not true with third party projects…

RISC OS lacks shared libraries
Not true at all :)

The fastest RISC OS computer you can buy is a 600MHz ARM clone with no floating point and a tiny cache.
Not true either.

The real question is “should NetSurf support RPC and ROS4 computers?”.
With modern hardware, memory is always >=512 MB, and hardware is faster than 600 MHz, with floating point.

RISC OS is co-operatively multi-tasked
Not true with third party projects…

Still completely true for any software that wants to be taken up by non-technical users. Software can’t rely on third-party hacks like Wimp2.

RISC OS lacks shared libraries
Not true at all :)

Aside from the SCL, which doesn’t count in the context cof the NetSurf info, are any ready for rolling out to non-developers?

The fastest RISC OS computer you can buy is a 600MHz ARM clone with no floating point and a tiny cache.
Not true either.

Agreed. However, NetSurf needs to support all the users who still have StrongARM RiscPCs, as they’re a sizable chunk of the userbase. That means 233MHz at best.

The real question is “should NetSurf support RPC and ROS4 computers?”.
With modern hardware, memory is always >=512 MB, and hardware is faster than 600 MHz, with floating point.

Yes: it it doesn’t, that’s a lot of the current RISC OS users who are suddenly unable to use the browser. Remember that a lot of RISC OS users are using RiscPCs with 26-bit software, or still won’t touch RISC OS 5 for political reasons.

it also illustrates nicely how fast the web moves: nowadays, nobody really needs Flash, Java or RealAudio in a browser.

RealAudio? What’s that?

;-)

RISC OS is co-operatively multi-tasked
Not true with third party projects…

Is entirely true.
That said, I have never found the use of co-operative multitasking to be a hardship. Yes, it has flaws, but if you ever get stuck with a zombie application on XP that hogs the screen, won’t minimise, won’t die…you’ll know that pre-emptive has flaws as well.

RISC OS lacks shared libraries
Not true at all :)

Name them.

There is SharedCLibrary and there is UnixLib. And…?

I considered a “shared” version of DeskLib, but I just don’t have the time or concentration to do it properly (by properly, I mean the necessity of a mechanism to cope with the module reloading at runtime, something of a large flaw in CLib but a mammoth headache to deal with).

The fastest RISC OS computer you can buy is a 600MHz ARM clone with no floating point and a tiny cache.
Not true either.

Yes and no. While the entry level machine is probably going to be a Pi, how many people are clinging on to older hardware? I think it says a lot that ROOL produce a ROM set for the RiscPC. That would amount to a much lesser spec that the one you just quoted even in its best incarnation.

With modern hardware, memory is always >=512 MB, and hardware is faster than 600 MHz, with floating point.

My Pi is 256MiB.
That said, if I wanted a browser that peed all over free memory, I’d use FireFox… ;-)

or still won’t touch RISC OS 5 for political reasons.

Duh. Still? <sigh!>

The way forward is for a poll – what spec machines is NetSurf being used on? We could consider dumping RPC/RO3-4 compatibility if this represents a fraction of the user base. On the other hand, if this turns out to be the majority…..

Another obvious question – are there any users of older machines who are getting involved in NetSurf development? This, additionally, should be a necessity – especially for Select/Adjust as they are non-Acorn and non-open (so neither supplied by standard with most machines, nor easily available to developers to test with).

There is SharedCLibrary and there is UnixLib. And…?

Presumably David is referring to the SharedLibs which rolled out with GCC 4. Are there any released applications actually using them? (I haven’t looked too hard, admittedly)

While the entry level machine is probably going to be a Pi, how many people are clinging on to older hardware?

Also, how many people are using RISC OS on an emulated RiscPC? (RPCemu, or Virtual Acorn, or one of R-Comp’s WinPC+emulator solutions) Should we continue supporting them? The emulation issue probably isn’t relevant for a browser, as any sane person will fire up Firefox on the native side, but it’s worth considering for other applications. An emulator on decent hardware will run faster than a real SA RPC, as I understand it.

Browser-wise, I think we should still be supporting Iyonix, at least.

Select/Adjust as they are non-Acorn and non-open (so neither supplied by standard with most machines, nor easily available to developers to test with).

I think you can still buy a set of Adjust ROMs from 3QD, or a CD to softload over RO4. So it is available, at a price. Not much use if you don’t have a RiscPC/A7000 to use it on though. :)

Old RISC OS commercial browsers

• Fresco & Oregano: There is zero point in updating the old RISC OS versions; the web has moved on far too far in the last 15 years. The companies responsible are still developing browsers for TVs. There’s ANT Galio Browser and Oregan Media Browser 5 . I doubt either have been developed with any of the peculiar limitations of RISC OS systems in mind. I suspect you’d need to pay them a fortune to get a port. Last time this was attempted (Oregano 3), was aborted, presumably due to it being difficult to make it run sensibly as a RISC OS app, and because there was practically no market for commercial browsers on RISC OS.
• Browse: Again, far to old; the web has moved on too much to make resurrecting this reasonable.
• WebsterXL: Again, far too old. Also written in BASIC, which might have made more sense when it was first started, but for the demands of the modern web is ridiculous.

In short; forget it.

Porting mainstream browsers

It took a herculean effort to get Firefox running on RISC OS. The result was too slow to be any use on most of the systems of the time. Even on systems that could run it the lack of a native user interface designed for RISC OS meant it clashed with one of RISC OS’s few advantages; the clean efficient UI.

Porting a mainstream browser engine and slapping a RISC OS front end on it

Huge amount of work. They’re written for multi-core processors, running at GHz speeds with GBs of RAM, and for operating systems that are far more advanced than RISC OS. Mobile phones are a far easier environment for a web browser than RISC OS systems. So its questionable whether the result would be satisfactory. Last time I looked, webkit alone was over 17MB of binary. (Not that these aren’t splendidly powerful software, I use them all the time on systems where it makes sense to do so.)

Making NetSurf use a mainstream browser engine

Madness, and completely against the goals for the project. We’re aiming to make a lightweight web browser. Not lightweight UI wrapper around something enormous. RISC OS is not the only resource constrained systems where NetSurf is run. People use it on old m68k systems such as old Amigas and Ataris for example.

JavaScript in NetSurf

NetSurf has been targeting JavaScript since at least 2007. When that document was written around the time of NetSurf 1.0 we were in a similar situation to the commercial RISC OS browsers; we had a browser engine that worked OK for static content, but was quite unsuited to any of the sorts of things JavaScript does to the document. (Although our CSS support was a lot better.)

The version numbers and timescales in section 3.5.1 are no longer relevant, but you’ll see many of the big steps on the road to JavaScript have been done. We’ve written an HTML5 parser, got a proper CSS parser and selection engine, and got a DOM that sends out events when it changes. Remaining bits are to rewrite the layout code to support layout changes driven by DOM events, and to hook the JavaScript interpreter up with the DOM and a few other bits of the browser. (A lot of work.)

Note: NetSurf has had a complete JavaScript interpreter (SpiderMonkey) for the whole 3.x release series. Of course that isn’t much use on its own and NetSurf is lacking a lot of the stuff that makes JavaScript worthwhile.

We have begun to evaluate using Duktape instead of SpiderMonkey. It certainly seems more in keeping with NetSurf’s aims, but the question of which JS engine to use is a small matter. Actually hooking it up with the browser and DOM is the complex part.

I think NetSurf’s RISC OS Caveat needs to be updated!

True, it’s probably missing a few things. It ought to mention the dreadfully slow disc IO on old RiscPCs and on the modern systems that run off SD cards. Also the fact that the IO is blocking.

A while ago one of the core developers added a disc cache feature. This was obviously a great boon on most systems, but on RISC OS it was another matter. Writing the files out to disc was so slow that people on some systems complained that their desktops were grinding to a halt. Also reading the files back off the disc was pretty painful too. So it turned out its faster just to fetch things again from the internet than it is to keep a local cache on disc. In the end we had to add some instrumentation to measure the disc performance, and just disable the disc cache on systems were its too slow.

I was surprised to see RISC OS users taking issue with the caveats in that document. It was written to ensure that NetSurf continues to run well on RISC OS.

There is SharedCLibrary and there is UnixLib. And…?

UnixLib isn’t shared: it’s statically linked¹. The “Shared UnixLib” module isn’t the library: it’s a few small memory-resident routines required by all the statically-linked instances of the library itself.

¹ That’s one of the reasons why NetSurf’s executable is so large: it uses UnixLib, and not the Shared C Library, to get access to the posix-y bits required by the ported libraries.

I was surprised to see RISC OS users taking issue with the caveats in that document. It was written to ensure that NetSurf continues to run well on RISC OS.

Apparently it’s not the done thing to be honest about the limitations of RISC OS… :-)

Apparently it’s not the done thing to be honest about the limitations of RISC OS… :-)

It might help if the information provided was, you know, up to date? I think the best available RISC OS device is a multicore 1.5GHz (maybe!) device with a suitably big chunk of memory that running Android in it shouldn’t be difficult. The Pi2? That gives us nearly a GHz, four cores, and a GiB of RAM. That’s a better spec than my first mobile phone!

It might be worth reconsidering the reason against porting WebKit. Sure, it is the madness approach, but I think you will find that a WebKit based browser will be working “satisfactorily” (if not wonderfully) on far crappier hardware than that which you listed. Look at the plethora of low end phones and cheapy tablets. 800MHz single core? Hell, I have only just got myself a Samsung Galaxy S5 Mini and it is comparable to your given spec but it is by far the most advanced Android device I have ever had. I think it may be a better performer than the iPad? At any rate, there is the hardware that stuff like WebKit may be designed to run upon, and then there’s the stuff that it actually does run on…

So, now, to the caveats:

1 RISC OS is co-operatively multi-tasked

Yes. This just means it’s way of passing control between tasks is a little different (and you can’t sleep at the wheel and just expect the OS to handle multitasking for you). ;-)

2 RISC OS has a limited number of shared-namespace file descriptors

True. I think the 255-counting-down dates from the BBC MOS era? There have been discussions regarding increasing this, but I think people are worried about how much stuff it might break? As far as I’m concerned, I’d like to have a build switch in the OS where I can use a 16 bit file handle (start at 16335 (or whatever) and count back) and run it like that and actually see how much stuff does break.

3 RISC OS has a limited number of shared-namespace socket descriptors

I can’t comment as I’m not that familiar with the stack, but 64 handles sounds a bit pitiful, doesn’t it?

4 RISC OS’s environment variables are global to the system

Yup. I prefer it that way, instead of the quirks where PATH in the (DOS) console can be two completely different things in the two instances.

5 Memory is valuable

You know, there might be a case of saying “don’t be stupid and expect a modern browser to run on a quarter century old bit of kit”. My RiscPC has 32MiB on board. ;-)

6 RISC OS hardware is slow

So is a lot of Android kit running either the generic browser or Chrome, as mentioned above. I think my second mobile phone had a spec roughly equivalent to a Beagle xM, the first having a spec similar to the Pi.

Regarding points 5 and 6 – isn’t NetSurf available for Atari? What is it, 16MHz 68xxxx CPU and 4MiB or more of RAM?

7 RISC OS is delicate and lacks wide-spread memory protection

Yes. Some really dumb things can bring down the OS way too easily. Personally, I would have an iron fist here and state that modules must provide an API for passing data to user mode applications, then zero page (actually, anything below &8000) and the entire RMA would be marked entirely off limits to user mode code. But that won’t happen for the same reason a lot of useful changes won’t happen – how useful is the change if it risks wiping out a significant portion of the available software?

8 RISC OS lacks shared libraries

Steve has pointed out that UnixLib is not shared, as such. So, then, that just leaves CLib I guess. :-(

Perhaps one of the problems is related to what I wrote earlier about DeskLib (my version), and something that does affect CLib. Namely – which version is loaded? Technically one cannot replace CLib in situ. The reason it appears to work is because the generic users (in the OS) are linked to the version held in ROM so that will not be affected if a later one is softloaded. However, once a version is softloaded and software is using it, you cannot softload a different version. The end result is that you need to be sure to distribute the latest CLib and to load it from System and not a locally held copy. But this is making the user responsible for the library management and it means upgrading may require a system reset. I talk about this boringly a lot because it is a situation that may affect any shared library that wishes to set up some sort of jumptable mechanism to avoid the overheads of SWI calls.

Rick: I failed to follow your point with the Android comparisons. Anyway, consider that to RISC OS, all CPUs are single core. Whether a device running RISC OS has a quad-core is irrelevant. Also, yes, Chrome runs on low spec phones, but it runs slowly. And that’s in spite of being able to optimise all sorts of things with NEON, hardware acceleration of decryption, being able to throw all the rendering at the GPU, etc. On RISC OS, the CPU has to do all the rendering and compositing that a browser has to do. Also Chrome on a slow phone still has all the advantages of an advanced OS under it. It does not need to be (and has not been) designed to work around all the issues that affect RISC OS apps.

Yes. This just means it’s way of passing control between tasks is a little different (and you can’t sleep at the wheel and just expect the OS to handle multitasking for you). ;-)

You may put a smiley after that, but it’s significant. Writing something complex (like a browser) for a platform that supports preemptive multitasking and threading is a very different thing to doing it on RISC OS. On RISC OS, you have to implement algorithms that break nicely into short chunks so that you can yield back to the OS while also maintaining state between bursts of activity. On other platforms, you can just get on with writing the algorithm in a clear, maintainable way and let the OS worry about keeping the rest of the desktop alive.

To reiterate my Android comparisons:

Huge amount of work.

Probably, yes. If porting WebKit was easy, it would have been done a lot for other systems if not RISC OS.

They’re written for multi-core processors,

Mid to high end devices have multi core processors. Lower end devices do not. As a personal observation, by older Xperia U (my first multicore phone) was generally less fluid and more jittery in use than my Xperia Mini Pro (single core) suggesting that extracting the best performance is more complicated than just throwing more resources at a problem. Example? The former (U) would “glitch” about twice per song while playing mp3s with the phone in standby mode. The latter (Mini Pro) never did this despite being rather less capable hardware.
My current phone is a later Android, much faster quad core, I’d be quite upset if it was unable to perform a task that can be handled by a 16MHz Z80 clone with 64KiB RAM and a DSP attached…

running at GHz speeds with GBs of RAM,

My phone specs are:

• Moto DEFY – 800MHz single core OMAP3, 512MiB RAM. While this phone dates from 2010, it seems approximately the same sort of spec as the lower end tablets on sale today.
• SonyEricsson Xperia Mini Pro – 1GHz single core A8 CPU with 512MiB RAM. Could handle HD which was “interesting” given the display was only 320×480!
• Sony Xperia U – 1GHz dual core A9 CPU with 512MiB RAM and, annoyingly, a fixed 4GiB flash (no SD card). Lesson learned!
• Samsung S5 Mini (current) – 1.4GHz quad core A7 (!) with 1.5GiB RAM. Interesting that it’s the oldest generation ARM core on the newest phone. Finally a spec that makes Android fun.
• iPad Mini – 1GHz dual core A9 with 512MiB RAM, surprisingly less than I expected given how it behaves in use…

and for operating systems that are far more advanced than RISC OS.

Fair comment… :-/

Essentially, I was shooting down this as being unrealistic compared with reality: They’re written for multi-core processors, running at GHz speeds with GBs of RAM

Right, but remember that mobile versions of web sites are far less demanding than desktop versions.

The CortexA7 is one of the newer ARM cores. It came around the same time as the CortexA15 (for use in big.LITTLE combinations).

Right, but remember that mobile versions of web sites are far less demanding than desktop versions.

I prefer the desktop view (is usually the default on the iPad and the S5) because mobile sites tend to really suck.

The CortexA7 is one of the newer ARM cores.

Whoa… Just looked it up, and yes, the A7 is about half a decade later than the A8/A9. Weird – why the out of sequence numbering?

Writing the files out to disc was so slow that people on some systems complained that their desktops were grinding to a halt. Also reading the files back off the disc was pretty painful too. So it turned out its faster just to fetch things again from the internet than it is to keep a local cache on disc.

While Acorn never succeeded in making a fast IDE bus onboard, and saddling everything else with the antiquated 8MHz tops podule interface didn’t help expansion possibilities….I have gone through the pain of unpacking the RISC OS source code (and deleting the older version) a couple of times now and I am wondering if there isn’t some sort of inherent lag in the design of FileCore itself?
Am I the only one who has noticed that file access is…. a little less than zippedy-doo on modern (Pi) hardware?

“Am I the only one who has noticed that file access is …. a little less than zippedy-doo on modern (Pi) hardware?”
Can’t say I’ve noticed any particular issue compared to other RISC OS systems of my acquaintance (Iyo, RPCEmu, RiscPC). My Pi B running at 900MHz has poorer SD card access times than the Iyo (about half as fast across the board), according to !Speed, but its USB stick access is /much/ faster than the latter (Read = 12x to 2x faster depending on block size (smaller better), Write = 9x faster regardless of block size), and the same is true of RAMdisc access. Consequently my working files are all on the USB stick, not the SD card. In general use the Pi B at 900MHz feels faster than the Iyo, as various benchmarks would suggest: https://www.riscosopen.org/forum/forums/5/topics/466?page=10

Back on topic, I think NetSurf is the only game in town from a practical standpoint, and only wish I had the skills to do something helpful.

Rick: Yes I think because much of it was designed around 30 year old hardware. It isn’t noticeable because our application sizes are so small – if we had the application file sizes seen on other platforms we would notice it. I think a lot of that is because the OS tries to do a lot of the command-queueing itself rather than pass it on to the hardware to do the command queues.

On RISC OS, you have to implement algorithms that break nicely into short chunks so that you can yield back to the OS while also maintaining state between bursts of activity. On other platforms, you can just get on with writing the algorithm in a clear, maintainable way and let the OS worry about keeping the rest of the desktop alive.

Alas, that isn’t really the case—while you want the desktop to remain responsive you also want the app concerned to remain responsive too. On Android, for example, an app that fails to repond to an event within 5 seconds causes an ANR (application not responding) error—the OS puts up a dialog inviting you to kill the app concerned, so long-running processes need to be executed with care (I.e. In a different thread); in fact the Android API provides a number of classes to assist.

I’m sure this is much easier than under RISC OS, but it’s not just leaving the OS to take care of everything. In Netsurf I assume it is downloading and uploading files to or from the network? I’m assuming here that there is no thread support in RISC OS?

Porting mainstream browsers It took a herculean effort to get Firefox running on RISC OS.

The port was done in a comparatively short timeframe, so I cannot believe that “herculean” is the right word. Any numbers? Maybe in comparison to the amount of effort that went into NetSurf up to now?

The result was too slow to be any use on most of the systems of the time.

The last released version performed surprisingly well on a StrongARM Risc PC and quite good on an IYONIX pc. On today’s hardware, I am sure that a port of Firefox or WebKit would run just fine, especially if you consider that the Firefox port had to do all its stuff through a less-than-ideal XWindow emulation layer.

Even on systems that could run it the lack of a native user interface designed for RISC OS meant it clashed with one of RISC OS’s few advantages; the clean efficient UI.

This is indeed a problem. However, it is a problem that can be tackled later on – what kind of UI does a minimal browser really need? A writable input field for the URL and a few buttons. Everything else can be done externally (see BookMaker).

Anyway, compared to the problem that the lack of a capable browser itself poses (e.g. “can I configure my new router/NAS/phone etc. with it”), I am sure that the RISC OS world could live with having a nicely integrated lightweigt fast browser like NetSurf and use a slow resource-hogging badly-integrated port of Firefox or WebKit for the cases where NetSurf does not work.

Really, pulling out 15+ year old browsers because “they support JavaScript” is one of the most idiotic things I’ve ever heard.

Here’s, ultimately, what needs to happen to make a modern browser run on RISC OS.

• System-wide PMT subsystem that’s multicore aware (and Unixlib needs to be aware of this subsystem, and dispatch pthreads to it, rather than handle them itself) – the whole system doesn’t need to be PMT, but PMT threads need to be able to run in the background and yield to the UI (even if the UI is CMT)
• Accept that the RiscPC is ancient, and is not an acceptable target for modern software. I know RISC OS is all about low resource usage, but at least make something like the Pi 1 or the Iyonix the baseline. Maybe a rolling, “performance must be acceptable on native platforms available new 10 years ago” line would be decent – that’d include the Iyonix until 2018 (and, if ROOL ever supports it, the A9home), but not the RiscPC (not even the Kinetic).

Now, once that’s done… pick a mainstream engine based on performance, and do a native UI for it. NetSurf is nice for some things, but ultimately, the WWW moves faster than a small volunteer team can keep up with.

Also, glitches in Windows XP window management are not an argument against PMT, they’re an argument against badly implemented PMT. Granted, any RISC OS PMT implementation would count as “badly implemented” relative to modern ones, seeing as the entire userland would be running in CMT and merely offloading processing to other threads (see Mac OS 7.5-8.5 for the simpler implementation (PMT threads running in their own CMT “process”), Mac OS 8.6-9.2 for the more complex implementation (CMT processes running in their own special-cased very-high-priority PMT process that is the only one that can make thread-unsafe calls)).

Accept that the RiscPC is ancient, and is not an acceptable target for modern software.

As I said in another thread, RO5 on RPC is what I regard as an interesting experiment.
For some people it might be the bridge¹ so that they don’t have to shell out a whole 25 quid for a new machine (yes, that’s irony). It does of course have it’s place being used in an emulator, but once applications that use new facilities appear the emulators have to emulate new machines or be mere curiosities.
Time to move on.

¹ Silly as it might sound a few tweaks of the GUI (key shortcuts) seem to be a key missing component for some users of the other variant. Devotees may never change, that’s no reason not to make those small modifications particularly as the rather larger group of regular Windows and Linux users expect keyboard shortcuts and dismiss things that don’t have them.

NetSurf is nice for some things, but ultimately, the WWW moves faster than a small volunteer team can keep up with.

A lot of RISC OS software is developed these days because it’s fun and interesting, not because it’s the best way to achieve a certain end. I get the impression that NetSurf is as much about the developers creating their own useful browser than it is about solving a problem for RISC OS users in the fastest way possible.

Unless you’re prepared to pay developers commercial rates and give them full-time employment to replace their day jobs, that’s not going to change for any of our platform’s software.

Accept that the RiscPC is ancient, and is not an acceptable target for modern software.

It would be very interesting to see a breakdown of NetSurf users by machine type before commenting (and no, I haven’t either).

It would be very interesting to see a breakdown of NetSurf users by machine type before commenting (and no, I haven’t either).

I suspect that where you look only at RO users the plot would probably be an almost exact match for the RO users by machine type. i.e. if you did a RO user “what browser do you use on RO” it will come out as mostly NetSurf.
To go back a little way as you said: “However, NetSurf needs to support all the users who still have StrongARM RiscPCs” but as people have pointed out the development of RO Netsurf is slowed by needed to deal with the CMT.
So with that argument you either have to implement PMT in the OS and ditch support for RPCs or implement a PMT all the way back to RPC builds.
Interesting choice?

It would be very interesting to see a breakdown of NetSurf users by machine type before commenting (and no, I haven’t either).

The alternative to Steve’s response is also to note that clinging to the past for far longer than is reasonable will affect us moving forward. I am aware that there are probably still people using A-series hardware to access the Internet. Heck, there’s probably somebody still using ArcWeb if you look hard enough.
I would not expect a decade old piece of hardware to give great performance for Internet use nor be still supported. Microsoft finally managed to ditch XP, and for many people the Android baked into their phone is the one they’re stuck with. iOS devices get updates but the effect of a newer release on older hardware is clear.
Now consider the RiscPC. It is nearly three times older, built in a time when processors were only straying into three digit megahertz speeds and saddled with an interface system that was getting dated before the machine was built and a system clock and memory speed of a previous era.
The RiscPC was quite a marvel…
…in the mid nineties.

Steve’s response is also to note that clinging to the past for far longer than is reasonable will affect us moving forward

t’other Steve I presume, as I think we need to move on.

Microsoft finally managed to ditch XP

Hmmm? I know of over 4000 XP machines with updates and patches issued at regular intervals.
Pry peoples grip from XP and move them to Win7 seems to be the case (note that MS don’t want people to hang on to Win7 either).
BTW. Big contemplation about a PC in the home office(t’other halfs stuff). All data backed up to a 6TB storage array, but the PC is running Win 2000. The machine was made by Apricot. Clock speed around the StrongARM level.