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

Reply to thread

Even if both strands of OS development were to merge tomorrow, there are still plenty of machines in the field which run older versions. As long as you're trying to target somewhere between 4 and 6, you have a problem, whether you like it or not.

If you charged for upgrades to a merged version (which the business model of ROL would require and, in turn, mandate closing down public access to the source code) then lots of people would not upgrade (it's a hobby / can't justify the cost, etc.).

Even if you managed to make upgrades free, lots of people would fail to upgrade if it was only a softload option. Softloading a ROM knocks out a chunk of at least 4MB of RAM, which on some machines will be too big a price to pay for an OS update. Softloading also makes life very difficult if wanting to use ADFS F+ features from the softloaded OS on a hardware ROM which only supports ADFS F.

Producing a hardware ROM is expensive and again, some people would not upgrade because swapping out ROM chips is a relatively arduous process. Besides, would you offer 32-bit or 26-bit ROMs to people? What about incompatible 26-bit code in podules?

Only if you provided a service which upgraded the hardware ROM of any Risc PC, A7000 or later class machine to merged "RISC OS 7" ROMs completely free of charge including shipping (!), might you have any chance of making a substantial dent into the installed incumbent userbase of versions 4, 5 and 6. You still wouldn't have settled on all-26 or all-32-bit code, since some people on older machines wouldn't want the incompatibility of 32-bit while others would (due to hardware) require it. We then have issues like making RISC OS 6 work on the A9 at all, then merging it with RISC OS 5 and making sure the result is still viable; and so-on, and so-on.

When you step back and look at this mess, you realise that you have no choice but to deal with making your code run across all the different versions and variants around if you want significant market share; but that's a significant share of not very much. On this basis alone, it's little surprise that the number of viable commercial RISC OS applications on sale today is so small.

The split exists, it will always exist historically whatever happens in the future and, given that the milk is long since spilt, it strikes me that the best approach is to make it as easy for application authors to deal with the differences as possible. One facet of this is ease of feature detection and a solution to that is what ROOL, ROL and the community are now discussing.

 is a RISC OS Useradh1003 on 8/5/09 4:44PM
[ 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

  • Java and RISC OS
    Nick Brown explores the state of play and future options
     47 comments, latest by em2ac on 28/09/07 12:34AM. Published: 19 Sep 2007

  • Random article

  • ArcSite begins RSS syndication
    All the news you need on one page
     4 comments, latest by DeveloperDude on 11/1/04 6:41AM. Published: 10 Jan 2004

  • 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
    "Such behaviour on a portal such as Drobe brings down the reputation of the whole platform"
    Page generated in 0.0709 seconds.