Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Resisting change is short-sighted

By Chris Williams. Published: 2nd Jul 2006, 15:21:34 | Permalink | Printable

AIF checking work around and official tool released

Drobe logoEditorial The opposition from some corners to the new standards checking in 32bit RISC OS 4 is, quite frankly, short-sighted. As reported last month, new versions of RISCOS Ltd.'s stream of the operating system are clamping down on dodgy software to stop applications from trashing the rest of desktop.

RISC OS needs more of this if it's ever to be taken seriously or progress from its 1980s MOS heritage. It's hard to demonstrate RISC OS to any newcomer when one faulty program decides to scribble over the rest, causing the desktop to disintegrate in seconds.

But the outlook is grim if some of the platform's programmers are unwilling to accept these necessary changes. If it's too much hassle to keep a package up to date, then the source code could be handed over to another developer - or better yet, open sourced.

The highest profile checking in RISC OS 4.42 is the so-called 'AIF header' detection, and the OS will refuse to run a program if this data is missing. Every application executable should have an AIF header - the equivalent of a signed declaration that the software is 32 bit compatible, how much memory it will need, and the sections of the program code that can be safely protected from being overwritten.

Acorn mandated this in 1996. Yet the excuse from one developer 10 years on was, "Acorn recommended a lot of things, and these days some people pick and choose which ones to pay attention to".

In that case, we'll just pick and choose to stick with our cooperatively multitasking operating system with limited memory protection, and not bother with features other platforms have enjoyed for over a decade. There's no hope in adding any of these to RISC OS if some of today's coders and users can't accept the upheaval these developments will introduce.

32bit motifThe ABC compiler itself does not have an AIF header, when it would be a simple job to add one. ABC developer Alan Glover said: "I don't put any store by the old Acorn advice argument. I believe that the insistence by the A9home's OS on AIF headers is a misguided move."

Discknight author David Ruck also panned the new checks, but he did echo other programmers' views by suggesting that if RISCOS Ltd had told everyone of the new checking, any ill feeling could have been averted.

He said: "I'd have been fine with it if they had given developers some warning, and not just snuck it out at the end of the A9home's beta programme.

"If you do things like that, developers' response will be 'screw you too'. We are just going to sit back now and wait until everyone has turned the AIF checking off. Then the problem goes away, and it's just another waste of time and effort by ROL."

Dave and Alan may just have chips on their shoulders with RISCOS Ltd. Dave is furious at the delays in the deadline sleep-walking Select 4, while Alan, who manages the official list of operating system allocations, is said to be fed up with dealing with the split between ROL and Castle.

It is possible to disable the checking by reading the instructions from *Help AIF, or by using AdvantageSix's new compatibility tool. This is an official Configure plugin that can be downloaded from the A9home website.

Click on the thumbnails for the full screenshot

James Lampard has also created WrapAIF, which can add AIF headers to defective executable files so they can run on 32bit RISC OS 4. The tool has been described as "subversive" and "working directly against RISCOS Ltd" because it adds a 'dummy' header to work around the checking.

However James hopes people will use his software for fixing applications that have been long abandoned by their authors, such as Impression Junior and Lander. Disturbingly, ZapTaskwindow, Elite, Confix and ABC are examples of packages that also need an AIF header.

Agree, disagree? Tell us what's on your mind.


WrapAIF website - version 0.30 now available

Previous: First A9home benchmarks surface
Next: Intel flogs Xscale business to telecoms firm


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

To me the AIF checking is a good thing that can help the stability of software and ensure that RISCOS has more stability. However , I tend to agree that it's introduction could have been handled better. ROL should be congratulated on making the step to further increase the stabity with 4.42 but they should have consulted more before doing so. As the article points out there are countless applications that will fail the test and some are not actively supported so that a cohesive plan should have been discussed with the few developers left in the market place.

I do disagree with some of the tone of the article as well but this seems a progressively and sad feature of recent RISCOS debates.

I hope that further work can be done in a sense of co-operation as we do need to move RISCOS forward in a number of areas and if we can't then I fear the market will be in terminal decline sooner rather than latter and that saddens me.

 is a RISC OS Userbluenose on 2/7/06 4:20PM
[ Reply | Permalink | Report ]

Chris: Elite has a header. However, it has been the subject of a lot of patching, and as a result the header is now inconsistent with the actual file, so the version on the AcornArcade site won't load. This is an oversight from when it was patched - the solution of course is to correct the header (since Elite without the patches definitely won't work!) In a way, this is a prime example of one of many benefits of the AIF checks - it spotted a 'tampered' file and wouldn't let it run. The fact that the 'tampering' in this case is deliberate and beneficial is a side issue. I got Elite running once under Aemulor, but since have had troubles with its sound modules not loading - solutions welcome!

The case for AIF headers really doesn't revolve around this (it's more a useful side-effect) however: if a rogue application (eg a virus,) appends data but doesn't modify the header, the application won't run - effectively preventing spread. RISC OS viruses that aren't 32-bit (can't imagine any 32-bit ones!) running under Aemulor or on RISC PCs that try to infect absolute files will no longer be able to spread (because they won't modify the header - you wouldn't be able to load any infected apps!). When filtering viruses, any new 'Select 4 compliant' viruses would also have distinctive behaviour patterns (they have to modify the data AND the AIF header,) which should also make them easier to spot and scrutinise.

As the number of 'known' new RISC OS viruses is precisely none, this is in many ways a moot point (although obsoleting a few old viruses is no bad thing!) However, hopefully a point of interest!

 is a RISC OS Usermd0u80c9 on 2/7/06 4:25PM
[ Reply | Permalink | Report ]

Doesn't the Icon virus work? It's written in BASIC

 is a RISC OS Userbobloblaw on 2/7/06 5:26PM
[ Reply | Permalink | Report ]

Yes. But my point was that a reasonable number now won't. Not that it's by any means the main reason for implementing the change, just a rather cool sideline ;-).

 is a RISC OS Usermd0u80c9 on 2/7/06 5:45PM
[ Reply | Permalink | Report ]

With respect Chris it's a *bit much* you critising David Ruck suggesting that "Dave is furious at the delays in the deadline sleep-walking Select 4" and inferring that this is his *major* reason for objecting to AIF checking. I (and many others here) can spot an ad hominem attack when they see it. Also the suggestion that Alan Glover is likewise against AIF for anything other than practical reasons is IMHO poor form on your part.

You could just try to justify the need for AIF checking *in its own right* without kicking the teeth in of people who put in their time supporting the platform - after all how likely would it be that anyone would take RISC OS seriously when there are no developers left using it? If you want to get to that sorry state of play - keep up with editorials like this one.

As it happens I don't have a particular problem with AIF checking - but believe that it should be an "opt in" rather than "opt out" - although certain hardware suppliers (e.g., Ad 6) might choose to opt for the "always on by default" for their OEM customers - why should that be something that has to be imposed on the ordinary user is the question.

 is a RISC OS UserAMS on 2/7/06 6:45PM
[ Reply | Permalink | Report ]

AMS: Having a opt-in/out system for OEM customers/desktop systems wouldn't make the developers address the current deficiencies. I personally think AIF checking is a great step forwards (and considerable blame for any problems should be attributed to CTL for /not/ implementing it when it really should have been.) I don't, however, think the manner in which it was introduced without forewarning was remotely professional, and even the details of the utility header format seems not to be openly available unless I've missed something. Developers need documentation! The standard ROL response that you'd need Select to code for it is utter drivel. Documentation is about understanding how everything works and interacts so you can plan things accordingly as much as it is about using the actual API.

 is a RISC OS Usernot_ginger_matt on 2/7/06 9:35PM
[ Reply | Permalink | Report ]

No-one is saying that adding AIF checking is a bad idea (although I think some of the RO5 developers have stated that Castle looked at it and decided that breaking an even larger amount of legacy software was a bad idea).

The problem is that there was no warning of this to developers. Claiming that it was in an old (and largely ignored) Acorn apps note from 1996 isn't enough: ROL should have told developers about this 6 months to a year ago, in the sense of "This will happen, in mid 2006", and then it could have been prepared for. As far as I know, not even Select subscribers were given the heads up: there certainly wasn't a mention of it on the Select mailing list.

 is a RISC OS Userstevef on 2/7/06 10:39PM
[ Reply | Permalink | Report ]

Hmm. Netsurf and I made a bit of a pig's ear of that last post between us. What I had meant to add was...

Suggesting that those complaining about the change are doing so because of "chips on their shoulders" isn't particularly clever, either. It would be more useful to try and identify the real reasons why so many developers appear to be fed up. In a market this size, the constant back-biting and one-up-man's-ship isn't helping anyone.

 is a RISC OS Userstevef on 2/7/06 10:47PM
[ Reply | Permalink | Report ]

The ideal time for AIF checking to have been added was when Acorn itself was working on RISC OS 4, so that it was in place when RISC OS 4 was actually released. This would have been the best *theoretical* time to introduce it.

Given that that didn't happen, the other good time to introduce it would have been with RISC OS 5 on the Iyonix, and it is indeed a pity that it didn't happen then. It was the ideal *practical* time for its introduction, given the 32-bit nature of the new machine and the fact that lots of developers were updating their software for 32-bit compatibility anyway.

Its arrival now is effectively 'third time lucky' for the feature. Unfortunately, the timing is particularly bad; so bad, in fact, that it probably creates more problems than it solves. In theory, having it present is still a good idea. In reality, given that we're faced with the current situation (RISCOS Ltd and Castle apparently at perpetual loggerheads, and many users and developers similarly taking sides with their favoured company), the arrival of AIF checking now merely serves to perpetuate the rift between camps. Some developers will doubtless take an entrenched position and refuse to update their code, for political reasons if nothing else. Many will feel aggrieved and disenchanted with the whole platform because of all the political infighting we've seen. That wasn't the case in 2002, when the Iyonix represented a fresh and exciting opportunity for the platform. All the ill-feeling has been created by foolish short-sightedness, and could so easily have been avoided by a bit of simple cooperation and deflation of egos.

As for the idea of an opt-in or opt-out, it seems that there is one already, in the form of the compatibility plug-in. On the positive side, this could at least be a useful debugging aid for end-users: they could turn its features on before trying out applications, to see whether they load or fail or exhibit specific problems (as detailed in the screenshot above), so users could choose to have 'clean systems' and only use software that loads without problems with the checking turned on. But on the negative side, though, the ability to turn the checks off means that (a) having them there in the first place serves little purpose, and (b) developers have even less incentive to update their software. But of course, given that the vast majority of RISC OS software is rarely if ever updated these days, /not/ having the checks is likely to be the only way of running many applications.

Overall, this sort of compatibility feature is the kind of thing that demands an active developer community, if its introduction is to be successful. And that's precisely why there couldn't really have been a worse time to introduce this new checking. It merely puts a new burden on the few developers we have left (effectively, it demands that they must update their *entire* portfolio again), and theoretically rules out the use of older software; at least, without use of Aemulor or the 'subersive' WrapAIF tool. Incidentally, I can't see that WrapAIF is any more subversive than A6's own compatibility tool. If the AIF checking itself can be turned off by the user, why is it 'subersive' to provide a tool that creates compatibility for software that will never gain it otherwise?

(NB Please excuse any technical errors in the above. I write without the benefit of an A9; I neither own one nor have ever used one, so I'm going merely by what I've read.)

 is a RISC OS UserRichardHallas on 3/7/06 11:26AM
[ Reply | Permalink | Report ]

I fully agree with all of the above about the timing.

I also feel RISC OS 5 should definately have had AIF header *checking* from the beginning in the same way as it already has module header checking, so if an program declares itself as 26bit it doesn't get to run - as it will either be an application which hasn't been ported, or one which has been recompiled/ported incorrectly and still likely to have problems. Currently an absolute is only faulted if it attempts to call a 26bit variant of the Shared C Library initialisation call, which wont stop programs which dont use the SCL.

However mandating that all absolute files should have AIF headers is another matter, and isn't something that should be introduced without warning by any party (I would have been equally unhappy if Castle had done it). Entire portfilos of software can't be updated overnight even if there are still people willing to do it. AIF headers on non absolutes such as FFC utilities is plain wrong, there is already an informal lightweight mechanism for these, which is to put "32OK" in the last word.

 is a RISC OS Userdruck on 3/7/06 3:06PM
[ Reply | Permalink | Report ]

In reply to druck:

AIF headers on transient utilities would indeed be wrong, because the design of these headers does not allow return to the calling environment (only termination via OS_Exit).

Fortunately the header required for transient utilities has a more appropriate format (the first word is a branch instruction rather than branch-with-link).

I was not aware of the 'informal lightweight mechanism' that you mention. Was it ever documented anywhere? What was the point of it if it was not enforced?

 is a RISC OS Userthesnark on 3/7/06 5:12PM
[ Reply | Permalink | Report ]

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.

 is a RISC OS UserAMS on 3/7/06 6:56PM
[ Reply | Permalink | Report ]

AMS: You are assuming that OEM customers want to run 100% of their own code all the time. If I write a module and don't specify it as 32-bit then it won't run on Select-32 or RISC OS 5. And yet if I package it as an application you think it should? To me that doesn't make Select-32 look deficient, it makes RISC OS 5 look plain stupid. As to options being off by default, that's wouldn't help most users in the long run. This is a change that needs to happen, and as I said previously, it's CTLs lack of doing it when it should have been done that has caused much of the problem.

 is a RISC OS Usernot_ginger_matt on 3/7/06 9:54PM
[ Reply | Permalink | Report ]

not_ginger_matt: Your idea would make sense if RISC OS was still a thriving market with all of the key pieces of software actively developed. Sadly, it isn't.

As has already been pointed out, Castle appear to have considered including this kind of check in RO5 and ruled it out because it would have broken everything; if they felt that four years ago, the situation is even worse now.

Having such a check makes a lot of sense, and in some situations it is nearly essential. I can fully understand why it has been included, as OEM customers are likely to consider the lack of it a show-stopper. But, for desktop systems, it has come too late. By all means include it, and allow savvy users to turn it on if they understand the consequences -- but don't ship it on by default.

And *in* *particular*, don't ship it on by default having failed to tell what remains of the developer community about it (the app note doesn't count: it had been ignored for ten years, so there should at least have been an announcement to the effect of "we're now going to implement this in a few months' time"). That is what is really getting up people's noses from what I can see. That and people claiming that trying to get dead software, for which a proper update isn't likely to happen, around the tests is "subversive" and "working against ROL".

It's another PR own goal by ROL, and coming on the heels of similar problems in the past, it doesn't give a good impression -- whatever good intentions may have been behind the changes. And given the entrenched views of so many people in this market now, it's the *impressions* that matter.

Principles are great, but they're also going to deny A9 users access to a lot of old software (and potentially support for new software, if developer goodwill is lost) unless we're very careful.

 is a RISC OS Userstevef on 3/7/06 11:12PM
[ Reply | Permalink | Report ]

stevef: The Castle thinking it would break everything argument is utter nonsense -- the applications needed updating to 32-bit anyway! Additionally, all C programs have an AIF header and BASIC programs aren't affected -- is there really that much software that you've found problems with? I totally agree that the manner in which it appeared was poor, but most people shouting about it don't seem to actually understand how simple the header is to add, or how it allows the OS to finally introduce some sane memory protection.

 is a RISC OS Usernot_ginger_matt on 3/7/06 11:25PM
[ Reply | Permalink | Report ]

not_ginger_matt: I agree - this change needs to happen, and they shouldn't be disabled by default.

Users by and large aren't stupid, but some are (most of us know the technical reasons for this; I'm not sure all users know).

These users will try to run a 26-bit application, and wonder why it crashes. They'd then either contact the developer, or (possibly and) A9 support. A9 aren't a large company (I work for a smallish company that develops very technical software - we have a 2.5-man support team of about 60 staff in total), and any support call like this would be a drain on the resources (especially if the user does not know the difference between a 26-bit and 32-bit application). In fact, given A9's size, I wouldn't be surprised if the developers would be doing support (we used to).

In our company, we have a fairly extensive support site (over 300 articles), but despite this, between 5 and 10% of all our queries are things that have already been answered on the support site (we classify these as "Tier 1" support). It's not enough to have documentation somewhere as to how to fix the problem - users don't read it.

We've added things into our software to reduce the level of support by identifying problems, and either fixing them on-the-fly, or reporting them in a way that tells the user what is going on.

Adding the erroring of non-32-bit-marked AIF headers into Select-32 is analogous to this - if a user understands what they're doing, and the application really is 32-bit, then users can disable this feature. My concern is that it's too easy for users to do this - and some users will just set this option without understanding why they need to do it. Therefore it'll get one or two applications working, but they'll find an application which isn't really 32-bit, and this'll crash - and support will be called...

 is a RISC OS Usertribbles2 on 3/7/06 11:38PM
[ Reply | Permalink | Report ]

not_ginger_matt: It is actually BASIC programs that are most caught out by the AIF checking. Pure BASIC isn't affected of course, but many authors have used tools which squashed the BASIC program, added on a bit of code so it could be typed as an absolute, and then run through the squeeze tool. This is to both reduce the size of the executable and to protect it from casual observation. Programs in such form wont work on the A9 as the absolute does not contain an AIF header, but just a branch to a relocation routine, and a command to invoke BASIC with an in memory program.

 is a RISC OS Userdruck on 4/7/06 9:17AM
[ Reply | Permalink | Report ]

Weren't most compressed BASIC programs fixed with the 32-bit upgrades though? Given that the compression is merely a header itself, stripping it out (or creating a patch akin to the StrongARM squeeze one) software such as this can be easily fixed with absolutely minimal developer effort. I'm curious about your squeeze comments though as I thought it put an AIF header on programs anyway, but I'm probably mistaken.

 is a RISC OS Usernot_ginger_matt on 4/7/06 10:19AM
[ Reply | Permalink | Report ]

Yes, most of the programs now faulted by the A9 had already been updated for 32bit, as the previous code added to make them absolutes wasn't always 32bit compatible. The tool used by many to do this is ironically called !MakeAIF, which doesn't actually put AIF headers on so really should just be called MakeAbsolute. The squeeze tool will take any absolute and compress it, suitably modifying an AIF header if present, but will just put a branch to the relocation and decompression routine in if its a plain binary.

Such programs can be fixed, a tool called !BASICGrab can be used to extract the BASIC program from the Absolute, unfortuantely it is also 26bit only, so if you only have a 32bit machine you have to hand extract using unsqueeze/xpand and then either plucking out the BASIC code with an editor, or executing with a breakpoint set at the OSCLI SWI that does the BASIC invokation string. The program then has to have the first line added by the wrapper removed in order to run.

If an author wishes to repackage their program in the same way, and updated version of !MakeAIF will have to be produced which does actually add an AIF header. I beleive some one was trying to contact the author about this, but I haven't heard anything since.

 is a RISC OS Userdruck on 4/7/06 10:41AM
[ Reply | Permalink | Report ]

not_ginger_matt wrote>" You [AMS] are assuming that OEM customers want to run 100% of their own code all the time."

How so? It was Ad6 that pointed out that some of their OEM customers required that additional checking be performed - and Ad6 had ROL implement this. I can't say if that means the OEM customers will *always* use only their own code or not.

not_ginger_matt wrote>"If I write a module and don't specify it as 32-bit then it won't run on Select-32 or RISC OS 5. And yet if I package it as an application you think it should? To me that doesn't make Select-32 look deficient, it makes RISC OS 5 look plain stupid. "

Modules are in effect operating system extensions, they have access to a lot of low level stuff - module checking therefore *does* make sense. An application doesn't have that access - but that is not to say that checking it's 32bit status is not a good thing - and if AIF checking is a way of acchieving this *fine* (not having an AIF however *does not* mean an application is *not* 32bit ready). I would caution that the reality is a lot of code out their *doesn't* have AIF headers and never will. Given Paul Stewarts consiliatory article elsewhere it is rather saddening to hear you describe "RISC OS 5 looking plain stupid". I don't recall making such a remark about RO Select and I'd also point out that I have already (twice on this thread) said I had no problem in principle with AIF checking.

 is a RISC OS UserAMS on 4/7/06 7:27PM
[ Reply | Permalink | Report ]

AMS: Modules and applications both have access to SVC mode, so either can utterly destroy a machine in a heartbeat. All being a module really gets you is the ability to service comands, SWIs, vectors and service calls. You also seem to think that I called RISC OS 5 stupid in anger at you. Aside from the fact that you misrepresented that quote, the facts are quite clear -- Select32 behaves far more intelligently than OS 5 does. I don't even know why you're upset about this. From previous comments you've made you're never going to use anything other than something Castle have made. All you're doing is whining at people who actually understand the problems/issues involved and proving how much you don't know.

 is a RISC OS Usernot_ginger_matt on 4/7/06 10:38PM
[ Reply | Permalink | Report ]

drobe: If you can provide me with a copy of MakeAIF and a few broken binaries I'll happily take some time off NetSurf and patch it :-)

 is a RISC OS Usernot_ginger_matt on 4/7/06 10:39PM
[ Reply | Permalink | Report ]

not_ginger_matt>What makes you think I am upset at *any* of this? In fact I already said (and I'll say it for the *fourth time*) I see nothing wrong in principle with AIF checking.

You wrote "All you're doing is whining at people who actually understand the problems" I don't recall whining (unless you consider my *agreeing* that AIF checking may be useful) to amount to that.

Yes I'll concede I am not particularly pushed about getting Select (but would never have ruled it out) - if it makes you any happier though I'll quite gladly admit with your attitude and insulting behaviour I find little reason in continuing with *any* variant of RISC OS.

Subtract one from the list of RISC OS users then guys.

 is a RISC OS UserAMS on 5/7/06 1:44PM
[ Reply | Permalink | Report ]

I'd rather see one user leave than have the platform not being moved forwards. So, please, if you believe a few comments on some forums are enough to make you switch platforms then go do it -- I certainly won't be mourning any loss.

 is a RISC OS Usernot_ginger_matt on 5/7/06 3:05PM
[ Reply | Permalink | Report ]

In reply to Druck; I've never heard of MakeAIF or can find it. If it's MakeApp2 you're referring to, then it's output can already be put through WrapAIF, which will add the required header.

I'm also producing a re-write called MakeApp3 which will add the header directly & will have a few improvements such as supporting longer command lines and BASIC64

 is a RISC OS UserIvanDobski on 5/7/06 4:11PM
[ Reply | Permalink | Report ]

From [link] You can now download MakeApp3 filename map3005.zip and to replace !BASICGrab, a new 'Basic from Absolute ripper' App2Bas filename a2bas000.zip

 is a RISC OS UserIvanDobski on 6/7/06 1:38PM
[ Reply | Permalink | Report ]

In reply to AMS:

"with your attitude and insulting behaviour I find little reason in continuing with any variant of RISC OS."


 is a RISC OS UserVirtualAcorn on 6/7/06 10:09PM
[ Reply | Permalink | Report ]

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

Search the archives

Today's featured article

  • Archive booklets review part one
    MessengerPro, VirtualRPC, simple networking and programming guides
     20 comments, latest by jlavallin on 19/12/05 3:28PM. Published: 12 Dec 2005

  • Random article

  • The Beginner's Guide to RISC OS: A Valentines story for the RISC OS Explorer 2 release

     Discuss this. Published: 10 Feb 2001

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "No comment. No comment. I said, no comment!"
    Page generated in 0.3811 seconds.