not_ginger_matt wrote >" Having a opt-in/out system for OEM customers/desktop systems wouldn't make the developers address the current deficiencies. "
What that their programs don't always have AIF headers?
I would point out that I did *not* object to the AIF checking in principle, I did suggest it should be *off* by default for desktop users. My reasons for this are multiple:
(1). When a new machine is introduced simply introducing a check that actively *prevents* code from running (code that may well be 32bit compliant and run on the Iyonix (e.g., ABC compiler)) simply creates the impression that the machine running the check (in this case *only* the A9) look deficient ... when in actual fact it would not be.
(2). Much of the code (as stated in the article) is no longer actively being developed - in effect this means it will *never* be made AIF compliant - short of simply bunging any old AIF on at the start (and that simply means programs that are just as likely to "stiff" the machine can pass the "AIF Test" with flying colours - and bring everything crashing down as if there'd been no AIF checking present).
not_ginger_matt wrote>"I personally think AIF checking is a great step forwards"
In what way ? It can be circumvented by just prepending any old AIF header to any old random bit of flakey code. An improvement - yes - but a "great leap forward" only if one is not particularly demanding
I'd, however, fully agree with you that its introduction was somewhat unprofessional (especially so shortly after being surprised that A9 needed a 32bit SCL.....).
I'd also agree (and have said it myself before) that Select's API needs to be documented even so that developers that *don't/can't* switch to Select can at least have at least a *chance* to support their customers who do. If Castle can do it with their version of RISC OS there's no reason why ROL can't.