Developers divided over RISC OS 4 code checking

Published: 4th Jun 2006, 20:13:55 | Permalink | Printable

ABC users get surprised [Updated]

Opinion is divided amongst developers over the decision to enforce the strict checking of applications in the latest version of 32bit RISC OS 4. The checks will prevent any programs that are not properly constructed from running. While this decreases the chance of poorly written software from crashing the entire desktop, the move has come as a surprise, some say, especially to users of ABC, Castle's BASIC compiler tools.

Software generated by ABC is handled by a module called LegacyExec, provided by AdvantageSix, to allow the code to be executed. Third party developers can also produce their own components to hook into the system to provide support for additional executable formats. However parts of the ABC compiler itself are not correctly flagged as being 32bit compatible, causing them to fail on the A9home.

One Iyonix and A9home user, Chris Hall, said: "The !compile part of the Archimedes Basic Compiler (ABC) package is reported as not 32 bit compatible although it runs OK on the Iyonix so I am having difficulty on the A9.

"The ABC compiler was the main reason I bought the C/C++ development CD, in order to allow an application written in BASIC to run on the new 32 bit computers - the A9 and Iyonix."

Discknight and Armalyser author David Ruck said software authors should talk to Ad6 and ROL.

He said: "It was their decision to prevent hundreds of 32 bit applications from working on the A9 just before it was released, with absolutely no warning to developers."

MW Software's Martin Wuerthner said, for now, the software should be compiled with ABC on the Iyonix.

He added: "With hindsight, it would have been a good idea if [Castle's] RISC OS 5 had introduced such a check - back then, it would have been an ideal moment to do so because all executables had to be changed anyway to make them 32-bit compatible. It would have saved users from seeing a lot of crashes typically experienced when inadvertently running a 26-bit executable.

"When buying software you never get the guarantee that it will run on future OS platforms although sticking to the programming guidelines should maximize the likelihood of running on a new platform."

RISC OS 4.42, shipped with A9homes, will reject any software that doesn't carry a valid signature, known as an AIF header. This declares, amongst other details, whether or not the application is 32bit safe and how much memory it is likely to use. AdvantageSix and RISCOS Ltd took the decision to knock back software without correct AIF headers in an attempt to tighten up stability on their side of the RISC OS platform. Ad6 admitted at the recent Wakefield show that their clients regarded RISC OS as a 'toy operating system' for previously allowing any code to execute on it unchecked. Acorn mandated the AIF header standard 10 years ago, in 1996.

Chris Evans of CJE Micros, who sell and support the A9home on AdvantageSix's behalf, said the AIF headers "offered a number of other advantages which would increase reliability."

• To disable the checking on RISC OS 4.42, users should investigate the AIF module. *help AIF will reveal the settings required to disable the checking, although this isn't recommended unless you know what you're doing.

Update at 12:26 10/06/2006
Alan Glover, who maintains the ABC package, has told Iyonix users: "I believe that the insistence by the A9's OS on AIF headers is a misguided move.

"My position is that there's no incentive to make the changes to ABC. It doesn't make money, and hasn't for many years now. Nor is the fact that it doesn't run on an A9 affecting me in any way."

He added that he would be willing to make the necessary changes if they didn't prove to be too difficult - we understand that this will not be the case. Alan also revealed that his software company, Pineapple, was close to winding up at the time of the Iyonix launch.

Links

Back to the front page

Previous: 3D space shooter game planned
Next: Don't rely on Drobe, says R-Comp

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

I like the sentence "To disable the checking on RISC OS 4.42, users should investigate the AIF module. *help AIF will reveal the settings required to disable the checking, although this isn't recommended unless you know what you're doing."

Considering the hassle this check does - though it is indeed very disappointing that even the pretty current Acorn C/C++ package doesn't have the correct AIF headers - I would have expected some easily accessible config option to turn off that check.

As for "unless you know what you're doing": Well I don't know what's wrong with all other RISC OS versions since they seem to work without that check and yes, I'd turn that check off knowing that with that I make sure that I can run much more software.

I agree with Martin that it would have been the best moment to add this feature when RISC OS 5 was put to market. I understand that Ad6 needs that feature in place to make their other customers happy but that Ad6 and ROL make life for the RISC OS desktop users such a pain in the a... is something I fail to understand. As for the often claimed "increased reliability" there must be something wrong in RISC OS 5 since I don't have any hassles along these lines, that is RISC OS 5 is reliable and stable without such features.

So Ad6/ROL I dare suggest that you add an easy AIF-check-disable-option, or even turn it off by default... and offer this ASAP since I do think that quite a few potential clients for the A9home are now holding back and wait how this issue is resolved before parting with cash to buy a new system which has increased reliabilty by making sure that software known to work does not run due to weird checks.

I don't say that AIF checking is wrong but the moment to start checking is perhaps ill chosen...

hzn on 5/6/06 7:15AM
[ Reply | Permalink | Report ]

As Martin Wuerthner says, the opportune moment to enforce checks for 32 bit compatiblity is when the operating system is going to start executing code in 32 bit mode. I don't see why Castle's oversight in this matter should influence what ROL do with their own 32 bit RISC OS.

There are still many executable files out there that are not 32 bit compatible, and in my experience the AIF check is useful in identifying this. It has always been the case that most RISC OS applications use AIF anyway.

I am certain that David's figure of "hundreds of 32 bit applications" is an exaggeration, and "absolutely no warning to developers" is laughable given that they had ten years warning. What is the point in deprecating things at all if - even ten years down the line - there are screams of anguish when they are finally removed?

For the record, Star Fighter 3000 has had a valid AIF header since late 2003 and it works fine on the A9Home. No flies on me! :-)

thesnark on 5/6/06 8:59AM
[ Reply | Permalink | Report ]

It certainly is hundreds of applications, all those BASIC programs which have been turned in to AIFs with MakeAIF and squeezed a start. Its laughable to say we've had 10 years notice by quoting an old Acorn application note that only recommended the move, Acorn would have given noticed which OS version this was due to come in on, not just suddenly release a machine with it enabled at the end of a years beta testing.

I'm all for checking AIF headers if they exist, I've been sent or downloaded dozens of programs by authors without new machines, that have thought they've sucessfully converted to 32bit, but made some mistake with options or libraries, and the compiler has indicated this by downgrading it putting 26bit in the AIF header. These often then crash on the Iyonix rather than being rejected straight away.

However enforcing AIF headers on all binaries is entirely another kettle of fish. If STD and ROL wanted to ensure the A9 is the success it deserves to be, why not have made a public announcement to developers 6 months ago warning of the change, so all the software could be updated, checked and made ready for its launch? Rather than leaving dissapointed A9 purchasers desperately searching for authors email addresses to notify them of problems.

druck on 5/6/06 9:38AM
[ Reply | Permalink | Report ]

ABC compiled code runs on the A9 whatever the setting of the !Compatibility options - at least it runs with them all 'unticked'.

CKH2 on 5/6/06 9:54AM
[ Reply | Permalink | Report ]

Personally, anything that makes RISC OS more robust can only be a good thing. Short-term pain for long term gain.

I'd rather not comment on the amount of notice given to developers tho....

nx

nx on 5/6/06 12:12PM
[ Reply | Permalink | Report ]

The article misses out the fact that compatibility can be set in the Boot - Configuration; the bit entitled "Compatibility"!

nx (and Martin Wuerthner) are right. Short term pain for long term gain - and a pity that Castle didn't take the step when it would have been easier. Druck seems to be suggesting that Ad6 and ROL should take short-term commercial decisions over the long-term viability of a robust system. I'm very pleased that they're not taking that advice - and reckon that RISC OS users will see the decision as a vote for the future and make the A9 (and Select 4) a success anyway.

jc on 5/6/06 12:47PM
[ Reply | Permalink | Report ]

this probably means none of my dodgy games will run

)

nex on 5/6/06 1:44PM
[ Reply | Permalink | Report ]

nex: Well, they're easily fixed, and there's a rapidly growing army of dodgy games testers for you now ;-)

md0u80c9 on 5/6/06 2:40PM
[ Reply | Permalink | Report ]

Perhaps that AIF checking should allow four instead of just two modes: 1. Strict, i.e. only run things which do have an AIF header 2. Nice, i.e. look for the AIF header and if it is there make use of it to see, if the code is 26 or 32 bit to act accordingly, if it is not, then run the app 3. Talking, i.e. like nice but if no AIF header is there tell the user 4. Ignore, i.e. don't even look

AFAIK currently only options 1 (default) and 4 (configure off) are there.

The least would have been that ROL and perhaps Ad6 should have told the users and especially the developers well in advance and passed out a tool to check AIF headers so that everybody had a chance to fix his or her app. And furthermore a more friendly first step offering the four settings for the AIF check would have been more sensible.

Thus I expect that close to every A9home user (and probably all Select 4 users since I expect this feature to be in the next Select release should the next Select release appear) will turn off this check to make the computer usable and avoid all that hassle - I would surely do so. This leaves the question if all this trouble is worth the trouble...

In reply to nx: Making RISC OS more robust is a good idea but the way ROL and Ad6 started off with this is not a seinsible manner to do so (not to say I consider it a pretty blunt approach).

hzn on 5/6/06 3:30PM
[ Reply | Permalink | Report ]

The only problem I have with it is that it wasn't stated some time ago that the A9 and RISC OS Ltd. would be doing this. Cutting loose old baggage is almost certainly necessary for survival.

SimonC on 5/6/06 4:02PM
[ Reply | Permalink | Report ]

SimonC: I'd agree with you if they hadn't produced a means of running broken programs in the short term. They have - and, despite hzn's comments, there are 8 compatibility options available. hzn is right though in saying that to make it all worthwhile software writers do have to take the hint and make their programs adhere to the standards - and make the system more robust for everyone.

jc on 5/6/06 4:16PM
[ Reply | Permalink | Report ]

The thing which has irritated me is the addition of a header for transient utilities. These are by definition small, user mode processes which, if they do blow-up because they aren't 32-bit, they won't cause any real damage.

That's why we at Pace decided not to touch transients in the RISC OS 32-bitting work and that's what you get with the Iyonix. I was quite surprised and dismayed to find that MoreDesk didn't work on the A9home because it "wasn't fully 32-bit" even though I knew it was.

This is just one more example of no matter how hard you try as a developer to produce software which should continue to operate correctly into the foreseeable future, someone pulls the rug out from under you for no good reason. Whatever happened to backwards compatability?

7thsoftware on 5/6/06 5:05PM
[ Reply | Permalink | Report ]

A number of points:

SimonC>"Cutting loose old baggage is almost certainly necessary for survival"

This will no doubt cheer up the (roughly) 50% of RISC OS users who rely on code that is from legacy source and/or unsupported that lack AIF headers.

jc wrote >"to make it [AIF Checking] worthwhile software writers do have to take the hint and make their programs adhere to the standards"

And when the software writers left in 1998 and their code is still in use what then? Are wheels to be reinvented? are the current (small) number of developers left expected to make up for the failures of the past 10 years - is this even *fair*?

I am pleased to note ROL allow the option to disable the AIF checking (a wise move) and I am sure it's fairly trivial for RO users to disable this feature if they find it adversely affects the software they need to use.

While I can see some merit in what ROL propose - simply (by default) disallowing the execution of legacy code that lacks the relevant AIF header is likely to create problems for A9 users (initially) and then other Select 4 subscribers in due course. As I suggested elsewhere the *default* action should be NOT to check - if people want to (or if a hardware manufacturer needs it for OEM clients - as is the case in Ad6) then it can be defaulted on.

Besides code that lack's an AIF is *not* broken. Anyone with a A7000, RPC (RO4.OX or earlier) or Iyonix (assuming the code is 32bit clean) can run it. Only A9 and Select 4 users *can't (by Default)*.

Please allow me to put it bluntly *Why would anyone spend a wodge of cash to ensure many of the programs they use can't work any more*. ROL please leave the default checking to OFF - have people opt IN if they want to check AIF headers..... Ad6 for your OEM clients have the default ON then you're needs are met WITHOUT impacting the ordinary RISC OS user in the street.

AMS on 5/6/06 5:22PM
[ Reply | Permalink | Report ]

What you mean is only the latest Machine and OS will follow a 10 year old guideline.

tweety on 5/6/06 5:50PM
[ Reply | Permalink | Report ]

AMS: Software writers who produced 32-bitted software won't have disappeared in 1998. That's why it would have been a good idea for Castle to insist on the implemetation of 10 year old Acorn requirements and why now is probably the last chance for ROL to do so. No one is suggesting that the decision won't improve software - for everyone even Iyonix users. What you are arguing for is a continuation of the situation where software appears to run OK but may cause problems with other software.

jc on 5/6/06 5:57PM
[ Reply | Permalink | Report ]

jc>But the suggestion was that the document suggesting AIF checking was 10 years old...... therefore in that time frame.

And 26bit code can be run under Aemulor (even on the A9) but can it run if it doesn't have an AIF header ?

Jc wrote >"What you are arguing for is a continuation of the situation where software appears to run OK but may cause problems with other software"

No, but then I wasn't arguing people butcher their !Run files to remove checks for the appropriate 32bit SCL then was I ;-)

AMS on 5/6/06 6:02PM
[ Reply | Permalink | Report ]

AMS:

Which would you prefer - safe operation, or potentially dangerous?

If you bought a car with traction control, by default it would be on, because it's safer; you can turn it off if you want, but you'd have to know what you're doing.

While I'm not saying it's perfect, I think it's better this way than the other - Ad6 would be getting calls "Software XYZ isn't working and it crashes" if a 26-bit mode application was executed; in the safe mode, it'll be "Software XYZ is saying it's not suitable to run" "Is it 32-bit?" "Yes" "In which case, disable this option".

What would be better would be some form of application knowledge, so it knows which applications are 32-bit, and which aren't - the user's given the choice when they try to run to attempt the execution.

tribbles2 on 5/6/06 6:03PM
[ Reply | Permalink | Report ]

7thsoftware: Surely you wouldn't class 'just blowing up in user mode' as acceptable behaviour, minimal damage or not? Certainly wouldn't like to be at the meeting where you explain to your clients that 'ooh - that's just a normal feature. But the OS is *real* stable, honest'. Even if it was rock-solid, I'd be surprised if anyone believed you.

md0u80c9 on 5/6/06 8:13PM
[ Reply | Permalink | Report ]

tribbles2>"Which would you prefer - safe operation, or potentially dangerous?"

Personally I'd prefer *safe* - but guess what when people find that a fair proportion of their legacy code *won't* work because of an AIF check (where such software worked for many years before) - and that that software is no longer updated (and therefore will *NEVER* run with such checking) then people may wish to disable such checking.

Short answer ROL own Select but *PEOPLE* own their computers. And a computer that can't run the software you need is *useless*. It would (IMHO) be prudent for ROL to make the check one that is an *opt in* for users (that is users must *explicitly enable it*). Bearing in mind that the USER is then responsible if things DO explode. It could even be stated as such.

AMS on 6/6/06 1:30PM
[ Reply | Permalink | Report ]

In reply to AMS

Your last two sentences almost made me fall off my chair laughing.

Really, you should be a comedian!

sa110 on 6/6/06 8:08PM
[ Reply | Permalink | Report ]

sa110>I aim to please.

And I'd appreciate you keeping quiet about my moonlighting as a comedian, ta

AMS on 6/6/06 8:18PM
[ Reply | Permalink | Report ]

In reply to druck: The Acorn application note didn't merely recommend the move, it states baldly that "all Absolute files must have valid AIF headers".

From that statement I wouldn't have been surprised if RISC OS 3.7 had included the AIF header checking similar to that which has finally been implemented. That would have saved a lot of non-StrongARM compatible software crashing.

thesnark on 6/6/06 9:13PM
[ Reply | Permalink | Report ]

I have two problems with what has apparently been done:

1. As druck has already hinted, this is the third step of the process but the first two have been missed; firstly we do not have the tools to produce "valid" AIF headers - the Linker does not put in the 32-bit value (or the 26-bit) as far as I can see. So we have no tools to produce valid headers (of course they can be produced manually but that is error-prone). Then we have not had a period of notice to allow us to, for instance, protest that the tool kit hasn't caught up.

2. The Acorn recommendation does not actually entirely foresee the current situation: It does not have a setting for 26/32-bit neutral. Hence, setting the header for 32-bit could be construed as denying usage to 26-bit machines. Now this point is a little academic (because the 26-bit versions of the OS don't check) but important if we are to change across the board. What will future 26-bit builds from ROL's converged (single) source-tree do? Will they insist on 26-bit compatibility?

So what to do? Firstly, surely it would be sensible for A9home builds merely to ask 'Are you sure?' when an attempt is made to run an application that is not specifically marked as 32-bit compatible. If the Iyonix/RO5 example is anything to go by, in a year's time there will still be enhancement OS versions being issued and *they* can be the vehicle to introduce this checking, thus buying the time I've already referred to. Then we need a user-friendly tool to allow applications proven as compatible to be marked as such; this isn't difficult but it does need to be *right*!

Finally, how about Castle and ROL agree a standard header that permits 26/32-bit neutral marking too? Then all versions of the OS can gradually introduce compatibility checking should it be useful.

TonyStill on 6/6/06 10:47PM
[ Reply | Permalink | Report ]

TonyStill:

1) The linker with the 32bit C tools has always produced a valid 32bit AIF header. The same goes for the linker supplied with 32bit capable GCC releases. If the byte at offset &30 of the resulting binary is not 32, then you're linking against something that isn't 32bit. I believe GCC's linker will warn about this; I'm not sure about Acorn's linker.

Similarly, module headers have a mechanism for specifying if the module is 32bit clean - the word at offset &34 is an offset to a flags word - if bit 0 of this word is set, then the module is 32bit clean.

2) All machines that ROL produce OS versions for are capable of running 32bit neutral code. Therefore I think it highly unlikely that they will enforce 26bit binaries on machines that are not running in 32bit mode.

The only way in which a 32bit neutral application would fail to run on a machine running in 26bit mode is if the application was using instructions not available on ARMv3 or earlier. By default, neither Norcroft nor GCC produce binaries which contain such instructions, therefore the developer has to explicitly turn such code generation on. The assumption is that, if they do this, they are also competant enough to realise the implications of doing so. Therefore, to all intents and purposes, a binary which claims to be 32bit can also be assumed to run on machines with ARMv3 processors (i.e RiscPCs with ARM610 or 710).

3) (and this is general, not in response to your post) I'm not entirely sure what all the fuss is about. Binary file headers are hardly a new phenomenon. Yes, it is true that there exist binaries which do not possess such headers and these will need to be fixed up on a best-effort basis. I believe the true issue here is not the introduction of the enforcement of header presence but the utter lack of notice from the OS developers to third parties that this was going to happen. The A9 (and corresponding 32bit OS) was in beta for over a year and this header checking was introduced very late in the day. Had this intended change been publicised 6 months ago, say, I doubt this furore would have occurred. Additionally, Application Note 295 only considers Absolute files with no header deprecated; therefore the changes to transient utilities come wholly unannounced.

The take-home point from this situation is this:

Timely communication is everything: if ROL (or anyone else, for that matter) decide not to publically communicate before the fact with third party developers about major (backwards incompatible) changes in their products, then they must expect fallout each and every time they fail to do so.

jmb on 7/6/06 1:58AM
[ Reply | Permalink | Report ]

In reply to jmb: Firstly, I agree with your take-home point and did not mean to imply otherwise (in fact, I think I said the same thing).

I also did not mean to imply that the linker (and I should have said that I was talking about the Acorn/Castle linker) produces anything but legal AIF headers. It actually produces headers that are "old-style 26-bit AIF" headers (I quote from the AIF format as defined in the [Acorn, paper] Desktop Tools manual).

The point I'm trying to make is that if we're going to do this (and it does provide a cleaner mechanism than RO5 of dealing with incompatible applications), we need to define the *actual* compatibility of apps. Using a flag defined as "32-bit...may not execute correctly in a 26-bit mode" (same source as above) for 26/32-bit neutral applications is misleading and potentially a problem in the future. To emphasise, we will need a 32-bit only flag and this appears to be what the current standard provides, *not* a 26/32-bit neutral flag.

TonyStill on 7/6/06 9:25AM
[ Reply | Permalink | Report ]

Some of the Drobe article reproduces comments made on the Iyonix mailing list. Here was my take, with some edits - like Steve (7th Software), I was present at Acorn/Pace when these decisions were being made.

Many executables did not crash on 32-bit systems, particularly a lot of transient utilities. In fact there was a long discussion and ultimately a quite explicit decision to *not* require a header in user mode code. There was already more than enough incompatibility without introducing another source of problems.

If the RISC OS market had been alive, vibrant and bouncy ;-)

then the decision might have been different, but there were a fair few 26/32-bit neutral bits of code already out in the field that worked but were no longer maintained. With the market apparently in no state to be likely to either restart maintenance or author alternatives, the decision was made to have as small an impact as possible.

Crashes due to running 26-bit code accidentally are surely rare; but it is right to point them out. RISC OS 5 does at least take steps to ensure that modules, which could cause serious crashes, must be 32-bit capable. User mode code often just crashes itself, not the machine - when that's not the case, it would surely be better to spend effort on reducing the opportunities for crashing the whole machine by changing the parts of the OS responsible, not just by stopping the code running in the first place. That would increase machine stability across the board, including for when buggy 32-bit code falls over.

32-bit RISC OS was originally conceived for use in closed systems, with Phoebe long dead, though the engineers involved did try to bear in mind desktop users - good thing too, as it turned out, or the Iyonix couldn't have happened.

adh1003 on 7/6/06 9:32AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

RiscPC breaks 1.5GHz barrier
Calm down dear, this is a case mod

23 comments, latest by flypig on 13/5/04 1:56PM. Published: 12 May 2004

Random article

ROL faces rebellion over Select delays
Top tip of the day: Don't ask for more money when you're 12 months late

41 comments, latest by markee174 on 08/10/05 9:48PM. Published: 2 Oct 2005

Create a new account
Forgot your password?

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"The Drobe 'Best of 2005 awards' seems to have been infiltrated by a form of favouritism or censorship"
Page generated in 0.0704 seconds.