Who likes manga?

That’s some strange looking code, reading a byte from R4, shifting <<24, then setting R4 to R1 and loading three more bytes ORR’d into the remaining bytes of R0. Is that trying to read a 24bit image?

My next build will probably be ZPP if there’s a “shut up and fake it” option…

That’s been the default for a while…the “Compatibility Page”

I have written an article for Archive that (tries to) explain where we are with Aemulor and Zero Page and strongly advocates moving to a high vector rom now that (i) Aemulor will work with a high vector rom and (ii) Zero Pain does now allow reads from page zero to be tolerated (and even supplies plausible values if I understand things correctly). This means apps no longer being developed and fixed can continue to run.

Yep, it seems that this was my own fault for updating to a high-vector ROM without installing the ZeroPain module. Sorry for any confusion!

Edit: Confirmed working once installed.

I grabbed the SecureSockets source linked earlier in the thread and did a quick and dirty rebuild that seems to behave itself without dropping stuff into the ZeroPain log. Note that this is version 1.03 (as that’s the version provided in the other thread) so you’ll need to update !Run to stop it from loading its own 1.04.

This module has not been tested with anything other than Manga, and even then it was only a cursory “download the index and the first page of a random manga” so I claim no responsibility if it kills a kitten.

[Edit: Link removed; there’s an official 1.05 coming soon]

Lot of duplicated effort here isn’t there if I understand the news correctly something secure and supported is in progress

something secure and supported is in progress

The problem is, people will be wanting Manga to work today.

I’ll probably transition to the new SSL when it is available, but for now we are making do with what we have…

Lot of duplicated effort here isn’t there

Not really; all I did was take the existing thing and build it (although admittedly not without a question or two). It’s not like I ported something from scratch though!

The newly built SecureSockets module doesn’t appear to work with AntiSpam. The SSL/TLS handshake times out.

That doesn’t surprise me. I was actually amazed that it worked at all with Manga (first time, no less!) especially considering that there was 26-bit assembly in there (crypto.ripemd.s.rmd_block) which I just commented out completely as a quick hack.

I’ve zipped up my modified source tree and have written up some notes on how to build it all with a modern DDE. See the “BuildNotes” file in this zip. [Edit: Link removed; there’s an official 1.05 coming soon]

Edit: The supplied “rmdtest” works successfully without rmd_block in there, so that might be a red herring. I also found that there’s a C version of rmd_block supplied in the source too, but it conflicts with rmd_dgst and won’t link.

I have no idea whether AntiSpam is even touching this part of the code as I’ve made no attempts to actually understand what it’s doing; I only got it to compile/link :)

I found some more 26-bit stuff in there, alongside a test utility that was crashing. I replaced the 26-bit assembly with the original C version supplied with OpenSSL and the tests now pass. I’ve packaged up a new release; hopefully this one works with AntiSpam!

As before, it’s only been tested with Manga. I’ve updated the source zip too and it’s in the same place as before.

[Edit: Link removed; there’s an official 1.05 coming soon]

Firstly, big thanks and congratulations to Chris on this :) That’s the kind of success I’d been hoping for since making the source available. :)

On the flip side, not wanting to sound “ogre-ous”, but SecureSockets remains © R-Comp despite us offering the source and API for free. I’d prefer that there weren’t separate source repositories/distributions out there. I don’t intend to restrict availability (quite the opposite – I’m thrilled that Chris has done this), but I think any releases should be through us, otherwise it fragments horribly (also, for version number, I suggest 1.05).

Quick thought – since Chris seems to be the only one who has succeeded in getting it to build properly and work, could someone do the ARMv7 work on the small (?) amount of assembler to make a definitive build?

As a side note, for the SSL bounty, ROOL seem dead set on using the old AcornSSL module API as a base (which I think only !Browse uses), rather than our open SSL API (SecureSockets) that is in general use. This means you won’t be able to drop it in for use with Manga or AntiSpam or whatever unfortunately, although we’re looking at the possibility of a “Shim” (more expense, unfortunately).

Given all our source and API is freely available, my preference would be for the ROOL module to offer both APIs, but focus on SecureSockets API to minimise the amount of work programmers have to do (having to re-write every SSL-based program to use the new module would be a major issue, since some aren’t easily modifiable). Thoughts welcomed.

Extra question – is this compiled against StubsG for compatibility with older systems too? Generally speaking, all R-Comp software uses StubsG to ensure that it runs on both 26bit and 32bit systems (since there are plenty of RiscPC users who refuse to update for a variety of reasons). My goal would be a new, definitive release of SecureSockets, but ideally with 26/32bit neutrality (ie. like SecureSockets 1.04 aka SecureG).

is this compiled against StubsG for compatibility with older systems too?

Why? There are 26/32 neutral builds of CLib, and while I accept that there are issues regarding upgrading a running copy of CLib, this doesn’t prevent the user from a (mostly one off) task of dropping in a sufficiently new CLib and rebooting. I do understand that it was a mess in the early days of Castle/Iyonix with numerous versions of CLib around (not that Acorn didn’t do it too!) however things are more stable these days, and much modern code doesn’t need the latest greatest. That’s an advantage, but not absolute necessity.

Oh my god, you gotta be kidding me… http://www.riscos.com/support/developers/stubsg/index.html
It offers its own versions of RISC_OSLib and TCPIPLibs, it is closed source, AND IT HASN’T BEEN TOUCHED IN FIFTEEN YEARS! It utterly utterly fails to make any sense at all to risk compromising the stability of new modern machines by pandering to those hold-outs who don’t want to either upgrade their machine or their Club or deal with this evil 32 bit nonsense especially when you consider that they have a version of SecureSockets that runs just fine on their machines.
If they wish to run outdated software, let them. Please do not suggest their our software needs to be broken by design. 26/32 will run on older machines and it doesn’t need StubsG in order to do so.

do the ARMv7 work on the small

And ARMv8 ;-)

but focus on SecureSockets API to minimise the amount of work programmers have to do

It would make the most sense for the API provided to match that which is used by the majority of software.

Actually, scratch that. It’s 2018. It would have sense for there to be a module/library to which an application can say “open this sort of connection to this server on this port, send this data, and give me back the response”…
I mean, why are we all reinventing the wheel every time we want to fetch something via HTTP(S)?

Given all our source and API is freely available, my preference would be for the ROOL module to offer both APIs

I think the bounty states that optionally the SecureSockets API can be emulated.

If the majority of programs are against the securesockets API then that “Optional” statement should be be a “must”.

The update of the Internet stack is one off opportunity to get back up to date and it should also , if the target for porting is mature enough, support TLS 1.3 as well now it has been ratified.

Just tried this version (1.03) with Hermes 4.12 VRPC-DL RO5.23 (12 May 2017).
When I try and Fetch from ‘gmail’ it stalls.

Stopping the operation and reloading (1.04 StubG version) it works ok.

(note the old version of (1.03) didn’t work either)

It (StubsG) offers its own versions of RISC_OSLib and TCPIPLibs, it is closed source, AND IT HASN’T BEEN TOUCHED IN FIFTEEN YEARS!

I suspect it was a totally JF contribution and no one else understood the innards. As you indicated StubsG was a “I’m not going to pollute my machine with a Castle C library” bit of work.
Since that is

1. a bit silly
2. not conducive to integrating anything while bundling in legacy code

I would suggest that having people use a compatible ROOL¹ SharedC is the way to go

especially when you consider that they have a version of SecureSockets that runs just fine on their machines.

I suspect the changes in the secure socket requirements out in the big bad world mean that although it will run it won’t really do that much useful in the not too distant future so it will need updating. I’d bet SSL 3.0 and TLS 1.0 are still in there and they’ve been deprecated for some while – articles about how to turn off SSL 3.0 were doing the rounds in 2015 beause they’d identified as insecure legacy items.

¹ Yes folks, it’s ROOL not Castle, just like RO4 was ROL not Pace.

It’s 2018. It would have sense for there to be a module/library to which an application can say “open this sort of connection to this server on this port, send this data, and give me back the response”…

A sort of super EasySockets?

it won’t really do that much useful in the not too distant future so it will need updating.

Exactly what I was hoping you’d pick up on. :-)

So if it’s possible to update the SecureSockets module, it is possible to update CLib. We have no requirements for an ancient third party solution to a problem that didn’t exist…

Just want to correct something – you may see StubsG as an anti-Castle-C-Library piece of work, but as a commercial software vendor (one of the few), we see it as a “allows the software to work on all the computers without the user having to muck around with a core component of their computer”. Those that don’t use it probably don’t see the value, but it has made my life much simpler for many, many years. Also, it doesn’t need its own libraries except for StubsG itself – I use my own RISC_OSLib with it – you just link against o.StubsG rather than o.Stubs – trivial.

By way, the few programs that don’t use StubsG (eg. Fireworkz) have caused me no end of headaches as updating the Clib on machines that use C-based programs in !Boot is a very non-trivial process. Just sticking it in !System isn’t enough, as any 26bit programs will start in !Boot using the ROM-based Clib (eg. RMEnsure SharedCLibrary 3.00), and IIRC *unplug SharedCLibrary is a bad plan too. You can stick Clib 5 in “PreDesk” as !!Clib or something, but that’s a really ugly hack.

Either way, this ends up being an unpleasant experience for the user, who then blames the software vendor.

Or, you can compile against StubsG and the problem goes away for the end user, and the vendor and everyone is happy.

It is very easy for users of this forum to forget that there are a substantial number of RiscPC users still out there who are either incapable of upgrading or are otherwise uncomfortable in doing so (Sibelius users are a notable example, but there are many others). To give some idea of balance, we sell as much software to that audience as we do Raspberry Pi users, maybe more.

I agree that at some point in the future it may end up being obsolete, but when that time comes, software will need yet another re-compile anyway.

It is very easy for users of this forum to forget that there are a substantial number of RiscPC users still out there

RO3.7 and 4.02 here, but there’s a Pi and a Beagle in the set

I agree that at some point in the future it may end up being obsolete, but when that time comes, software will need yet another re-compile anyway.

As I pointed out earlier elements of it are probably aleady past their sell-by even on 26 bit platforms and StubsG is unmaintainable anyway.
Sibelius and similar are unfortunately unlikely to survive unless a really good hypervisor appears for the RO5 platforms to replace the dying RPC units.

This is one of those points where we need to be avoiding building in an incompatability.

My understanding was that RO6 was softloaded onto a hard install of RO4.02 or RO4.3x so “fiddling” with the available SharedC wouldn’t be totally impossible assuming someone could produce a new RO6 softload.

allows the software to work on all the computers without the user having to muck around with a core component of their computer

“Amen”, and very much “well said”.

APIs are not an end in themselves. Compatibility is good. Unification is good. Telling people to take their innards out is generally regarded as bad.

you may see StubsG as an anti-Castle-C-Library piece of work,

I don’t, I see StubsG as a solution to a non-problem. Though, certainly, there are those who have that impression (looking at Drobe, csa…).

we see it as a “allows the software to work on all the computers without the user having to muck around with a core component of their computer”

? As CLib is a core component, it needs to be updated with that level of respect. Download the Misc→PlingSystem archive, run !SysMerge, AND THEN REBOOT THE MACHINE.
[the instructions don’t tell you to do this, it’s stupid]

Having dealt with Fidonet and such back when Acorn were making numerous fixes to CLib, the biggest problem is users dragging the !System folder on top of their current, running their shiny new software, and then wondering why the machine blows up. This is part Acorn’s fault for never allowing CLib to refuse to be killed, and partly the user’s fault for not rebooting (I’m sure the update instructions mentioned this…).

By way, the few programs that don’t use StubsG (eg. Fireworkz) have caused me no end of headaches as updating the Clib on machines that use C-based programs in !Boot is a very non-trivial process. Just sticking it in !System isn’t enough, as any 26bit programs will start in !Boot using the ROM-based Clib (eg. RMEnsure SharedCLibrary 3.00), and IIRC *unplug SharedCLibrary is a bad plan too. You can stick Clib 5 in “PreDesk” as !!Clib or something, but that’s a really ugly hack.

I’m having great difficulty making sense of this.

1. Close down programs using C (as much as possible, just DO NOT start new ones)
2. Put the new CLib in !System (use the PlingSystem download to make it pointy-clicky)
3. Reboot

It’s really that easy.

Any program that uses CLib in ROM (prior to !System having been ‘seen’) is not a big deal, as its internal links (the Stubs part) will point to ROM and even if that module is “disabled” due to a later softload, it will still be available in ROM. This is how the likes of !Edit and !Paint function.

On any system using the Universal Boot, !System is specifically ‘seen’ in the Run file. This RMEnsures CLib and loads it if necessary. This is, like, the tenth or so line of Obey script executed by the system at start-up.

There is no excuse for any problems here. The most recent CLib is checked/loaded at the very start of the boot process – before any tasks that might use C are even considered. Those C-using modules built in won’t be effected as they link directly to the ROM CLib (and never use the softload) and applications won’t be affected as they haven’t even been run at this point.

It is no surprise that there are all sorts of problems with advice like this:

You can stick Clib 5 in “PreDesk” as !!Clib or something, but that’s a really ugly hack.

No, no, and no again. Don’t do that. Ever. Update the main copy in !System and reboot. It’s really that simple.

We don’t need StubsG to fix this problem…

Or, you can compile against StubsG and the problem goes away for the end user, and the vendor and everyone is happy.

Provided the user is happy to be stuck with an increasingly outdated and potentially buggy CLib. Those updates that cause so much horror? Acorn/Castle/ROOL don’t push out revisions to troll hapless users. They are done in order to fix problems. Add functionality, and so on.

Tell me – what happens if I use a program that uses long long (64 bit integers) on a machine that appears to support them (StubsG looks to set up the same set of redirections as the normal stubs) with a CLib that predates the C99 revisions?
You aren’t solving problems by using StubsG, you are pushing problems off until some indefinable future date.

To give some idea of balance, we sell as much software to that audience as we do Raspberry Pi users, maybe more.

That is understandable. There are, still, many who wish to remain with the older systems. I would hope that making Aemulor free would convince more to update their machines, but there is always the issue of “why replace what works?”. Upgrading isn’t free, though I personally believe the costs can be recouped in a year or two of energy savings, comparing a RiscPC with a Pi, but then again the electricity bill is periodic, the hardware is an outlay, and there’s all sorts of things that will be problematic (like the Pi not reading ADFS floppies). These problems are not terminal, but I do understand the adage that it is easier to do nothing at all. After all, I’m still running XP… ;-)

That said, we really need to destroy all the bull around updating CLib. The worst it will do if you mess it up is freeze the machine (due to a program jumping into non-code). Even today, ROOL builds versions of CLib for the older 26 bit machines, right back to 3.10.

Here, I’ll even give you a link: https://www.riscosopen.org/content/downloads/common

Fourth entry down. System Resources. Download it. Unzip it. Run !SysMerge (the Obey file). REBOOT.
That’s it.
Seriously.
That’s it.

It is no surprise that there are all sorts of problems with advice like this:

You can stick Clib 5 in “PreDesk” as !!Clib or something, but that’s a really ugly hack.

No, no, and no again. Don’t do that. Ever. Update the main copy in !System and reboot. It’s really that simple.

The strange thing is that until Andrew mentioned it the thought of hacking a different copy in like that had never crossed my mind and I’d always taken the Boot route.

As a small aside, the conversation about trampling over a customised Hosts file (amongst others) came to mind when I did a ROM and HardDisc update and I took the “Agenda” option and noted that “Hosts” was indeed one of the files you could ‘untick’ so that it didn’t get over-written so the option (some) people want of not over-writing certain files already exists but they simply aren’t doing things right.

So with as with other System updates the options for Clib seem to be do it the official SysMerge (well the Merge in Configure.!Boot) way and get things right or, don’t get it right.

There are, still, many who wish to remain with the older systems. I would hope that making Aemulor free would convince more to update their machines, but there is always the issue of “why replace what works?”.

Now on that point it may be that those people are using software that doesn’t work beyond RO4.02 or even RO3.6 and hence remain legacy. I would interested to see how long the list is that absolutely has to have a legacy OS and therefore can’t run on modern hadware because I suspect it’s more intransigence than anything else that is stopping an upgrade. I’m sure Andrew¹ has some nice machines just begging to be bought by those legacy system users.

¹ CJE too.

As we’re starting to veer off-topic – Rick’s Manga program.

RISC OS Select has some useful things (bling excluded) that RISC OS 5 doesn’t currently have, so “why replace what works?”, indeed! Trade-in programs on software and hardware may work, but… ;-) Backwards compatibility isn’t such a big issue, unless you have customers with old kit and software that runs just fine.

Aemulor albeit free has one major irritation, it puts a clamp on the wimpslot that can’t be removed without a restart. That kinda defeats its purpose.

RISC OS Select has some useful things (bling excluded) that RISC OS 5 doesn’t currently have

Might be useful to have an up to date list.