Important software compatibility notice

Sorry I don’t understand. Can you expand on that?

The expectation of a user, knowing that the zeropain mechanism was present and therefore magically fixes such errors, would be that any errors that do come up must be the OS.
Since the same application probably runs just fine on other machines not running RO5.24(+) then it must be another OS problem will be their conclusion. ROOL then need to check and feed back the correct answer.
Even the effort of proving a problem is elsewhere is a time burden¹. With limited resources in ROOL I for one would like to see those resources advancing the OS rather than diagnosing third party application errors and fixing them.

With a user configurable panel you don’t even have a definitive “this app is covered” state. Then we get the “application xyz isn’t covered by the zeropain system, could you just alter it to cover xyz, oh and also…” situation.

¹ Believe me I’ve had many lost hours, days, weeks…
Sometimes it’s manufacturer/supplier problems where they blame our systems and we have to diagnose their problem in order to prove it is not in our network/server/PC build.
Other times it’s partner organisations who attempt to minimise their manpower use by throwing the problem our way and waiting for the diagnosis.

The expectation of a user,

….is that enhances in the operating system don’t mysteriously cause software to stop working.

I still don’t see why there should be a big support burden for a module that fixes up page zero accesses in the stable release. Softwarethat is broken should continue as it does now.
I believe that not doing this would risk the support burden – all of the “why doesn’t xyzzy work on this version or RISC OS, it works fine on everything else!”.

Well, we’ll see how this plays out. It is something that needs to be done, but it needs to be done with care to minimise the impact…

Then we get the “application xyz isn’t covered by the zeropain system

Is the current ZeroPain app-aware? Common locations in page zero should be trapped and correct results returned (MetroGnome, for example), and probably otherwise trap the first kilobyte (the address range of an offset LDR) and return zero so a read from an uninitialised pointer fails. An exception can be thrown for writing as that is the current situation.

Does it even need to be app aware?

The expectation of a user, knowing that the zeropain mechanism was present and therefore magically fixes such errors, would be that any errors that do come up must be the OS.

I think I must be misunderstanding something.

I thought:
Without ZPP if a program currently reads from zero page whilst being bad programming practice it will continue to work as reliably as it has done for the last twenty? years.
With ZPP and emulation of ZP reads it still will work, surely? No extra support for anyone.

So to the user their system remains at least as stable as it was.

Have I missed something?

Have I missed something?

Yes, fraid so. The plan outlined in the first post in this thread included…

Phase 2 of the testing process is due to begin on 1st Jan, 2016. ZeroPain will refuse to run on any ROM built on or after that date. This will help to ensure that any previously unnoticed bugs are found and fixed prior to the release of RISC OS 5.24.

Note also that currently ZeroPain does not emulate unaligned loads. This has the effect that Basic any reads from page zero on an Iyonix which are unaligned are not emulated, but fail with Data Aborts. Jeffrey is hoping to improve this. On later processors (eg RPi) Basic uses aligned reads, even for A%=!9, so ZeroPain does log and emulate the read.

[Edited to clarify Basic reads]

(With ZPP and emulation of ZP reads it still will work, surely? No extra support for anyone.)

Something that I haven’t seen mentioned, but which is definitely worth noting, is that code that reads and uses the data in ‘ZeroPage’ (/processor vectors) could well behave differently even with the ZeroPain module loaded, because almost all those locations now return 0-valued data.

So, erroneous code could actually become either more or less stable than previously; without knowing the details of the broken code, the address(es) accessed, and their previous usage (changing/constant..) it’s hard to say, but it should either (i) ‘work’ (stumble on?) predictably, or (ii) fail predictably

Does any software past RO3.11 read the hardware vectors directly? I thought that was an early RO issue as RO3.5+ has a legal means to read them and the address of the values has IIRC changed between successive RO versions, so I find it hard to believe there would be any modern software that reads them directly.

Any pre RO3.5 software that reads the vectors directly would fail anyhow, as the vectors changed from B addr to LDR PC, [PC, #offset]

Should there be any poorly written RO3.5+ software that reads the vectors directly, a 0-minus value shouldn’t affect it as it would need to be using an LDR / LDM or MOV PC to forward the vector on. Pre RO3.5 that uses an encoded B to forward would obviously fail and would have broken with the introduction of RO3.5 anyhow.

This issue is the reason most games broke when RO3.5 was introduced. ADFFS gets around it by intercepting the read and returning a corrected B to an intermediary LDR PC within the first 32mb, any writes are blocked and legalised. I’d say that going this far is way beyond the scope of ZeroPain though.

If anyone is testing the development ROMS which include ZeroPain, and also has the latest Organizer v2.23, please can you contact me at the support address in the Help file?

Have I missed something?

Yes, fraid so. The plan outlined in the first post in this thread included…

Sorry I thought it was implied I was presuming zeropain would be emulating reads.
If zeropain isn’t active then presumable it will error and stop working

So I still can’t see where the extra support arises either this year or next.

If zeropain isn’t active then presumable it will error and stop working

And applications that have not been fixed which try to access zero page (which is protected by the ROM), I think will also fail. But that aim may have to be modified when the overall results of testing with ZeroPain are available. That is my interpretation of the announcement, anyway!

The extra support is required for any code that appears to have ZeroPage problems, either proving the problem lies elsewhere, or fixing it!

If there’s anyone using CashBook and a test ROM, the current test build of CashBook no longer reads from Zero Page when trying to close a file (and it doesn’t try to dereference a bunch of stale pointers into its data heap, either).

We have just uploaded new versions of RiscOSM and House of Cards to our web site which should avoid reading from Zero Page in various circumstances. Please let us know of any further problems with any of our software.

Frederick:

The latest ROM for the BB -xM seems to have broken alt-click on filer icon text. The writable text box opens & immediately closes. A new ZeroPain generated immediately after shows;

Time: Tue Jul 7 17:33:47 2015
Location: Application space
Current Wimp task: NetSurf
Last app to start: Filer_Action

Are you still seeing this problem? I’ve tried on a couple of different machines and haven’t been able to reproduce it. The log suggests it might be NetSurf related, but I’ve tried with it loaded and haven’t seen any problems. Do you have anything else loaded which might be causing trouble?

No, the problem disappeared with the 25th July ROM. If it was Netsurf related then perhaps the timing was coincidental.

18th July ROM. Shouldn’t rely on memory.

What I would like to see is a list somewhere of which software has been reported to the developer which will avoid repetition. Any developer who has a large user base is going to be inundated with messages. Perhaps at a later date, the list can be adjusted as developers/users have fixed the problem and a new/updated program/module etc. is available.

What I would like to see is a list somewhere of which software has been reported to the developer which will avoid repetition. Any developer who has a large user base is going to be inundated with messages.

I shouldn’t worry about that: RiscOSM has a pretty large user base now, and we received only two reports. Remember that most people do not upgrade to the latest development OS straight away. If a developer gets too many messages he/she can always put up information about current status on their own web site.

As I have been testing various ‘problem’ apps, there is one thing that, when eliminated, allows most of (my) the apps to run quite happily. The offending part is the VProtect module. When this is eliminated out of the !Boot structure (ie not loaded) most of the apps don’t add to the log file and run without error when the ZeroPain module is killed.

I thought VProtect was removed from RO5 downloads some time ago as being old, unsupported, and probably no use whatsoever?

I thought VProtect was removed from RO5 downloads some time ago as being old, unsupported, and probably no use whatsoever?

And buggy!

https://www.riscosopen.org/forum/forums/5/topics/1135#posts-13263
https://www.riscosopen.org/forum/forums/4/topics/1192

Unless the source to VProtect is available, having it around is worse than useless. It will protect against a variety of viruses written in the ‘90s which probably wouldn’t run on modern hardware anyway; and without the sources it couldn’t be updated to handle new issues, should anybody bother to create such a thing…

which probably wouldn’t run on modern hardware anyway;

I suspect many were very simple and would work:-(
The Extend virus cropped up recently I can’t recall the hardware or OS version.

Maybe the sources could be made available? (Not publicly of course!)
Does anyone have contact details for the author Alan Glover?

I suspect many were very simple and would work:-(

I have an archive of viri, unless it is “lost on some SCSI tape”. I used to ask for people to netmail me them if they came across any, and somebody sent me an archive.
I recall two things: a fair few were written in assembler, so wouldn’t work on newer machines; and the source to the Icon virus I had (in BASIC) had so many bugs I’m surprised it ever worked at all.

The Extend virus cropped up recently I can’t recall the hardware or OS version.

Old machine – wasn’t written in BASIC. If it is the one I remember, it hid was a module that could take a variety of different names; it would initialise itself as a hidden task and wait for something to infect. Every so often (running a program, I think) it would claim 1K of RMA. After a while, you’d run out of memory as it would all be tied up the RMA. Given that it happens upon running a program, there is usually no way to walk the heap block and release this memory as the slowness of its behaviour meant that other legitimate claims would be interspersed and… yeah…
Anyway, unless somebody has ported it to RISC OS 5, it was probably an older system. But strange, Extend is as old as houses (and didn’t one of the magazine cover discs pretty much give it to everybody, back in the day?) so I’m surprised none of the old-era VProtect/VKiller didn’t pick it up right away.

The one that impressed me was the Link virus. Didn’t do much, but hid well, spread like bacteria, and even temporarily modified one of the anti-virus tools (not VProtect) so it could do its stuff undetected. Clever code. Shame the programmer couldn’t use that cleverness to do something useful…

I have now removed VProtect out of my !Boot sequence, so no worries. I obviously didn’t see the discussion about VProtect.

As an offshoot of the ARMX6 project, the source to Vprotect, and also ABC compiler etc has been recovered from Alan Glover quite recently. I believe the plan is to update them and release into the ROOL tree. Work has already begun on ABC (required for commercial work), and it is now “modern machine safe” although apparently there are still some ZPP issues to resolve. I’d imagine there will be an updated ROOL Dev Tools CD release at some point.

ABC: I say YEEEEEESSSSS. Yep, I only care of Basic :)

I think that with a modern version available, a package with ABC, tools and documentation could be sold alone, and will please many people. We could now also hope to for some new things, for example something closer to BBC Basic, or direct VFP support (would be a fantastic add-on).

As an offshoot of the ARMX6 project, the source to Vprotect, and also ABC compiler etc has been recovered from Alan Glover quite recently.

Whilst adding 26bit Module support to ADFFS recently, I spotted a big issue with the way VProtect checks Modules. Instead of scanning them via the appropriate service call, it aliases rmload and rmrun. The majority of game Modules aren’t scanned as a consequence, as any Module inserted/loaded via SWI aren’t scanned.

If the source is available, I wouldn’t mind taking a look as I’m very dependent on it for my project.