WebsterXL

Hi
Is anyone here using !WebsterXL RO5.25 – have just dug out my old copy v1.99u14 (20 Oct 2004)

(some 32bit patching was required)

Is it supposed to handle ‘https’ – or perhaps there is a upgrade?

Like ROOL site?
It has a go at displaying the ROOL site – that has been saved to HD.

Seems to work with ‘RCOMP’ ‘CJE’ web sites.

For a 1Mb BASIC program – quite interesting!

There was a native 32bit version of WebsterXL – I got it from R-Comp for an IYONIX pc presentation in Germany when the IYONIX was brand-new. Not sure if it was ever released officially, since development of WebsterXL stopped somewhere between 2002 and 2003 IIRC.

I am fairly sure that Webster XL handled https via the SecureSockets module.

The R-Comp Webster XL website is still active and amusing to read after all those years.

I wonder if they’d be interested in releasing the source code for amusement value? I mean, a browser written in BASIC?! ☺

The source to Webite is on my site. I briefly looked at it, but it has a heavy dependence in the Termite stuff (of which I have no source).

I mean, a browser written in BASIC?!

I actually quite like the idea…though I have no idea why!

The 32bit version works fine (or seems to) on modern hardware – darned fast too, thanks to modern CPU uplifts. Not saying that it is particularly useful (except for developing basic HTML sites) as the web has changed a lot in the intervening time, but it makes me smile to see it fly given the stick it got back in the day performance-wise.

SSL used SecureSockets. However, I’ve found that it seems to “pause” using more recent versions of SSL module (1.04 onwards). It seemed to work best with 32bit 1.03 version, but that likely doesn’t work on high-vector builds.

It is also worth noting that there was a not-inconsiderable chunk of assembler in there too, for certain operations that were either time-critical or beyond the scope of BASIC (long string handling was one area, I think).

It stopped development for two reasons. Primary reason was that the author’s job changed and he was moved on “temporary” assignment from Manchester to Slough. This left him living out of a suitcase for what turned into a couple of years until the job became “permanent” and he could formally move.

At the same time, everyone got the “Netsurf fever” and couldn’t praise it enough (despite lack of JS etc). This was kind of the nail in the coffin, I think, because it was quite demoralising on top of everything else. Note, I’m not knocking Netsurf in any way – goodness knows it’s now our default browser – but rather reporting on what happened. The irony was that most people criticised WXL’s speed, yet on “then current” hardware – VRPC, Iyonix, A9 it was fine.

The problem was always on RiscPCs with slow hard drives and old operating systems (3.7 and earlier). Unlike C programs, WXL scaled pretty much linearly with CPU clock speed, so was approx 10x faster on SA than RPC600 and three times (or more) faster on Iyonix thanks to 600Mhz CPU and fast hard disc. The reason disc speed was such an issue is that it downloaded images to cache and then decoded them to sprite, which it also stored for speed. The sprites were always larger, of course, and that meant quite a lot of disc IO. The disc IO also showed up the bugs in 3.70 ADFSbuffers with >2GB drives – I had numerous instances of people blaming WXL for lock-ups that were caused by the bug in 3.70 (thanks Acorn!).

The other aspect that made it feel slow was that table sizing often required knowledge of the objects inside the table (eg images). It would “peek” these, but nesting of tables etc could create a heavy workload. This was done so that it didn’t have to keep re-calculating and re-flowing the page, which would have incurred other speed penalties and made the renderer more complex. Other browsers re-rendered on-the-fly so could begin plotting sooner. This meant WXL would sometimes take a long time for content to appear. The worst was large nested tables with lots of unsized photos – I recall an iconbar.com show report taking a minute or more to appear simply because it was having to fetch and peek all these photos before it could work out what size to make the nested tables.

These days (well, pretty much since 2005) I tend to give WXL away with any other purchase/product if people want it, stressing that it is no longer suitable for most tasks, but remains interesting (it does frames, tables, some javascript, GIF/JPEG/PNG, some basic CSS but no layout, and has a few nice features for page design and export, global clipboard and so on). It also implemented a range of Acorn protocols (including “plugin” protocol) and is I think the only program that can act as both a plugin client and server. It can host plugins like Java, but it can also be a plugin to render HTML in other programs.

I always wondered if it we should bundle WXL with Mpro and use that feature to render HTML emails, but in all honesty, I think the Javascript would actually be a curse (there are quite a few JS-based “nasty” emails). Netsurf would be the ideal browser for this, but my requests for acting as a HTML renderer-plugin never received any positive feedback :(

The actual BASIC is crunched from a range of source code, overlays and libraries. It had a whole “build system” associated with it to bring together the various chunks of code and spit out the main program.

The author, Andrew Pullan, still comes to all the shows and helps on our stand. I’m sure he’d be happy to chat about how it was produced if anyone’s interested. Just don’t expect any updates (I always hoped he’d have time to add UniPrint compatibility so that I could click on links to pass over to PC as it’d be handy for HTML emails).

Interesting BASIC programs – like Rick says – it would be nice to be able to download the source/s.

Some interesting things I have found out – what is the lastest version of the FontManager program that can be loaded on RO4.02?

There is a little module called FontBlend ver 0.01 (13 Nov 1996) 32bitted that improves the quality of the print – used with RO5.25 – effect seen on IconBar site.
This module doesn’t seem to be needed with the softloaded FontManager on RO4.02.

With the IconBar site – WebsterXL – seems to want to print white on a white background – maybe my version of WebsterXL (1.99u14 20-Oct-2004) – or changes I have made to the BASIC code.

Also on IconBar site !Phoenix is allowed to use HTTP where WebsterXL must use HTTPS.

Also Andrew’s note about using Module SecureSockets v1.03 – with IconBar site – trouble is !Hermes likes v1.05 – with gmail.

It looks as if !WebFetch does all the ‘Securesocket’ work – a download of the source would be interesting – Rick seems to be able to get !Manga working with SecureSocket v1.05 ok.

Jumping back and forth RO5.25/RO4.02 can produce some interesting changes to the sprite decoding Apps!

The fontblend module (I think) enabled background font blending for wimp icons over coloured backgrounds. If I recall correctly, it was something that was in the font manager but not enabled in the Wimp prior to RO4. Matthew Bullock did it as a Wimp Patch and did a version to include in WXL. RO4 (of which Matthew was one of the two main RISC OS Ltd programmers) onwards should have font blending in the Wimp enabled by default (it may be a configurable option in “Windows” section of !Configure). I would be shocked if this wasn’t enabled by default in RO5, although I have never checked.

If it isn’t then someone needs to ensure that it is, as it would be very noticeable for desktop themes with non-grey window textures, as well as when plotting icons on the pinboard without background-boxes. I believe it is merely a case of using the appropriate SWIs from the “background blending” font manager produced around the time !Browse was released. There’s a tiny performance hit, but not that would be worth mentioning on modern CPUs. And I’ll “have words” with anyone who says we should gimp such features to maintain performance on 30Mhz cpus.

as the web has changed a lot in the intervening time

And is still changing. It was always going to be hard coding a moving target. But, come on, hats off to somebody doing in in BASIC/assembler.

The reason disc speed was such an issue is that it downloaded images to cache and then decoded them to sprite, which it also stored for speed. The sprites were always larger, of course, and that meant quite a lot of disc IO.

Do you know if there’s a specific reason why system-supported formats couldn’t be handled directly? I’m thinking here specifically of JPEG which lends itself to larger images and are plentiful on the web. One of the primary design decisions with Manga was to handle JPEGs directly because, even on a Pi with SD card, decoding them to sprite for display was slow and used a huge amount of disc space. It also seemed pointless since the OS could deal with JPEG directly.
[and, then, I implemented auto-scale which uses ChangeFSI – one of the slowest JPEG processors in the history of RISC OS!]

Of course, things like GIF and PNG don’t have native support, but luckily many of those are more icons than big images…

This was done so that it didn’t have to keep re-calculating and re-flowing the page, which would have incurred other speed penalties and made the renderer more complex. Other browsers re-rendered on-the-fly so could begin plotting sooner. This meant WXL would sometimes take a long time for content to appear.

Turns out, this plan isn’t as crazy as it might seem. A desktop browser on a PC clocking several GHz can afford to reflow on the fly. But if you’ve used an Android phone of recent vintage, you may have noticed that it tends to try to fetch as much data as it can and then draw the page. You don’t tend to notice this with ADSL, but if using 3G/4G in marginal conditions (like a moving car), it can be quite obvious. Especially if you’re holding the phone up to try to get the signal before entering a forest (because if the signal drops, it won’t even attempt to render, it’ll throw everything away in favour of an error message).
In cases where battery life and efficiency are important, constant re-rendering and reflow are frowned upon.

Personally, I’d prefer a compromise where it would fire a redraw maybe every 5-10 seconds while awaiting the data. But you look at how much stuff does data transfer behind the scenes (somewhat thrashing the efficiency argument!) and you quickly come to believe that developers of these things use a perfect fast connection and barely (if at all) test their product in marginal conditions. Like Google? https://www.heyrick.co.uk/blog/index.php?diary=20141202

I think the Javascript would actually be a curse

It often is… my head nearly exploded when I saw options for JavaScript in Adobe’s PDF reader. WTF? Turned all that off…

There are some useful validation things that JavaScript can do, like block you entering a credit card if the number is too long/short or the check doesn’t match up. Or if your email address doesn’t look valid. But the number of useful things JavaScript can do is far outweighed by the amount of stupid it is for, like obfuscated advert links, kicking off bitcoin mining, and stupid visual fluff.
<cough>my blog, real browser, try the Konami code…</cough>

Just don’t expect any updates

The perfect reason to consider open sourcing something…

Rick seems to be able to get !Manga working with SecureSocket v1.05 ok.

• I wait for the SSL return code to be != 5. The example program seems to wait for ‘6’ (or is it not 6? I don’t recall) but this never seemed to work for me.
• The SSL module sometimes seems to insert rubbish into the data stream. This is identified as an [0d][0a] at the end of a received block, followed by four hex digits and an [0d][0a] at the beginning of the next block. Is this some debug code that was left in by mistake?
  As there’s a definite pattern, Manga detects this and suppresses it. There may be the four hex digits at the start of a file, but the rest should be removed.
  I think this happens for larger files. Not sure what counts as “larger”, but if you open Manga’s cache, you probably won’t see it in the mr*_P files, but probably will see it at the start of the mrindex file…

Other than that, just follow the spec – open a port, open the SSL, then read/write via the SSL. It’s simple. Simple to the point that if RO5’s proposed SSL enhancements don’t do it that simply, it would be… annoying…

I would be shocked if this wasn’t enabled by default in RO5, although I have never checked.

I don’t see an option, but it might just be done “automatically” these days.

Ah, there’s a -FontBlending option to WimpVisualFlags. It’s set on my system, even though WindSetup has no option for this, so I’m guessing it’s just “always done”.

I believe it is merely a case of using the appropriate SWIs from the “background blending” font manager

It’s a flag to Font_Paint – bit 11.

There’s a tiny performance hit, but not that would be worth mentioning on modern CPUs.

True, but the performance hit information was written when many systems used 3xMHz ARM610 and 40MHz ARM710. The slowest RISC OS 5 machine (Iyonix) clocks over ten times faster, and contemporary machines are around the GHz mark. So there’s no reason not to have it enabled by default.

And I’ll “have words” with anyone who says we should gimp such features to maintain performance on 30Mhz cpus.

You know my thoughts of the mesolithic systems: If my software works on them, then that’s good, but there’s zero support or consideration for such machines, and if there’s a choice of a convoluted old way or a nice RISC OS 5 way, then I will pick the RISC OS 5 way.

Or, to look at it differently: If you use RISC OS a lot, then the cost of a Pi (plus keyboard, mouse, and VGA adaptor for your existing monitor) is likely to be recouped by the difference in running costs. As I said a couple of months ago:

I’ve not metered the Pi2, however the Pi1 with HDMI adaptor (too much hassle to turn it off) and the Vonets WiFi thingy, all together, draw 9.4W at 230VAC. That’s about a tenner per year in electricity (106.38 hours per kWh unit; ~82kWh per year; €0,13 per kWh gives about €10,50). If I turn off the HDMI as well, it drops to a mere 7.7W at 230VAC. That’s less than the EeePC’s power brick charging a machine in standby, that’s about half of the consumption of the Livebox. It’s probably on par with a single LED lightbulb.
The PC? The one with the huge heatsink? It chews through around 200W (230VAC) when running. Every hour my PC is on would run the Pi for twenty one and a bit hours. Or, to look at it differently – 5 hour per kWh unit; ~1,752kWh per year; €0,13 per kWh gives about €228. The maths holds up – 228 divided by 21 (the difference per hour) is ten and a bit.
So there you go. Big PC is ~€228 a year to run if on 24/7. The Pi? ~€10 a year.

I would imagine a RiscPC to be somewhere in between.

In other words, many reasons to work with the new, and diminishing reasons to keep purposefully supporting the ancient.

And I’ll “have words” with anyone who says we should gimp such features to maintain performance on 30Mhz cpus.

I think we should all go back to the “system font” experience – all this shiny outline anti-aliased font stuff is just bells and whistles that no one seriously needs :-)

think we should all go back to the “system font” experience

Doable… ;-)

[https://i.imgur.com/hbmeL18.png]

Rick – WXL could do JPEG rendering using the OS modules, but also had to support (shudder) back to RISC OS 3.1, with all that that entailed. It was a tough time to be writing complex software! So, the software had options for this – you could decode to sprite or do OS-based rendering.

In practise, it was almost always better to do decoder-based rendering (although again, the program could peek a bit to decide) because the RISC OS 3.6+ JPEG stuff was pretty (how do I say this politely) inflexible and lethargic in redraw. The inflexibility meant that quite a few JPEGs would simply not happen because the OS renderer took umbrage to them (eg. progressive JPEG, JPEGs with thumbnails, JPEGs with metadata etc etc).

The lethergy wasn’t in the overall decode time, but rather that it made no attempt to ram-cache the results, so every redraw meant re-calculating the JPEG. You can see this right now by using a large JPEG as pinboard backdrop and watch the OS glacially re-painting as you move windows. Imagine a bunch of JPEGs, on a slow computer, and you get the picture (nasty).

As a result, decoding the JPEG was often the best solutions. And that’s before we get to issues where images would be incorrectly typed (ie. a JPEG that’s actually PNG data and so on). That still causes trouble.

The “in-page” image decode of NetSurf remains one if its highlights, to be honest, and its reflow/CSS/layout. That being said, it actually feels slower than WXL on modern hardware (depending on test)!

I would be shocked if this wasn’t enabled by default in RO5, although I have never checked.

A peek at the source suggests that it should be enabled by default for Wimp versions that target RISC OS 4+.

There’s a tiny performance hit, but not that would be worth mentioning on modern CPUs. And I’ll “have words” with anyone who says we should gimp such features to maintain performance on 30Mhz cpus.

If it’s slow then that’s usually an indicator that it needs optimising, not that it should be disabled :-) (I can see some obvious areas for improvement, for both new machines and old)

Or if it really bothers people, they can just use *WimpVisualFlags to turn it off.

Hmm – Just tried 20 size Blue writing ontop of a Grey background rectangle in !Draw – it shows the effect.

Using the FontBlend module or the *command – removes the effect.

*WimpVisualFlags -FontBlending
seems to only work one way – ie on.

Rick is there info on how to use the ‘SecureSockets’ module – and how it is supposed to work?
Thanks

but also had to support (shudder) back to RISC OS 3.1, with all that that entailed.

[…]

the RISC OS 3.6+ JPEG stuff was pretty (how do I say this politely) inflexible and lethargic in redraw.

Ah, yes. In the intervening forever, I forgot how bad the support for “standard” formats used to be, plus the legal issues around “progressive” JPEGS (and, back in the day, GIF) meaning support was pretty much non-existant.

You can see this right now by using a large JPEG as pinboard backdrop and watch the OS glacially re-painting as you move windows.

<looks at computer effortlessly redrawing from an 1280×1024 JPEG>

Nope. I guess a 900MHz CPU hides such issues. ;-)

where images would be incorrectly typed (ie. a JPEG that’s actually PNG data and so on). That still causes trouble.

Yes, I believe imgur used to do that.

Rick, I assume you’re being facetious with the 1280×1024 JPEG reference – I was talking about the 8+ Megapixel type images that most phones/cameras etc output, and customers have a habit of using as their backdrops ;)

Rick is there info on how to use the ‘SecureSockets’ module – and how it is supposed to work?

https://www.heyrick.co.uk/blog/index.php?diary=20180312

☺

In a nutshell: You connect and open the port as usual. At the point where you’d start sending data you instead hand over to the SSL module to establish a connection. Then you write/read via the SSL module.
Think of it as making a connection within a connection.

For “official” information, search this forum for “SSLsource”. Download the archive (it’s around 20MB). Inside the SSL subdirectory is a “Docs” file. There’s a client within the “Test” subdirectory in there, and it’s pretty easy to tweak it to fetch from a live site.

It doesn’t notice borked certificates… amend the top of the program to:

Port%=443
InetAddr%=(91<<0)+(203<<8)+(57<<16)+(172<<24)
Message$="GET /forum/posts HTTP/1.1"+CHR$13+CHR$10+"Host: xxx.riscosopen.co.uk"+CHR$13+CHR$10+CHR$13+CHR$10+CHR$0

(change the “xxx” to “www” – blame Textile…)

and customers have a habit of using as their backdrops ;)

Wait… what?!?!?

They don’t pass them through ChangeFSI so they’re not insanely oversized? <facepalm>

Well – I don’t use a custom backdrop on my Pi, with a 3840×2160 (8 Megapixel) screen. I don’t know how the default backdrop is generated, but it’s not noticeably slow to redraw.

I tried doing just that a couple of years ago (Pi 1), with just the effect described. Converting it to a sprite solved the issue.

I notice that the Windows desktop pictures are quite small files.

Trying to get !BasDT to work on RO4.02/RO5.25.
(seems to work ok with RO4.02 – works somewhat on RO5.25)

It patches the BASIC module.

What version of BASIC should I Be using on RO4.02? – ie to keep things the same!

Have tried BASIC v1.75 – from the ro5.25 roms + msg files.
Seems to work ok.

Have come across this in BASIC :-

A$=“1.6”

IF A$ > “1.6” THEN PRINT “TRUE” ELSE PRINT “FALSE”

Try different values of A$ – It seems to work.

It’s a property of ASCII, which makes sorting things like dated filenames possible.

It can be made to fail:

A$="01.7"
IF A$ > "1.6" THEN PRINT "TRUE" ELSE PRINT "FALSE"

which makes sorting things like dated filenames possible.

Also software such as xbase/dBase/ForPro that store dates as eight ASCII characters in the form CCYYMMDD (and then stuff a two digit year in the header as the last modified date!).

It’s a pity BASIC can’t be made handle ‘VAL"&10’ – It seems ABC_Compiler can.

It handles it perfectly: its value is zero. It also handles EVAL("&10"), whose value is 16, and is probably what you really wanted.