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

Reply to thread


"a developer has a choice either 71% or 20%, a no brainer"

Which developer would that be, then? I've yet to see a major app written by anyone outside of ROL that makes full use of features present in Select and /requires/ Select for full functionality. Given that many RISC OS users are still using RO 4.0x and below, it makes a lot of your argument pointless speculation. The RISC OS market is such that it's a brave move to support /one/ variant of the OS alone. As a case in point, NetSurf uses its own internal functionality to render images. It doesn't use the IFR system present in some Select versions as doing so would result in either extra code complexity (increasing the likelihood of bugs) or lack of image rendering on non-Select OS versions.

It's all very well having new APIs and functionality in the OS (as Select does) but it's all a bit pointless until developers no longer have to (or need to) support RISC OS 4.0x and below.

Equally, noone appears to have considered the possibility that enhancements made to RO5 by CTL would be API-compatible with those made by ROL to Select. There's no denying that the duplication of effort in implementation seems futile from the outside, but if APIs between the two branches are identical or sufficiently similar, a lot of the "71% or 20%" choice you say a developer would have is largely removed. You're then limited to deciding whether to embrace the future (Select and RO5) or continue to wallow in the past (4.0x and 3).

"The Select side also has the added advantage that the current emulation users can upgrade to an Xscale with no software issues"

What evidence do you have that those using emulation would return to native hardware given the opportunity? The presence of VirtualAmp alone worries me a great deal. Not because it isn't an excellent piece of software (which undoubtedly it is) but because of the dangerous precedent it sets. Next we'll have a thin wrapper around mshtml.dll (IE's HTML rendering engine) and so on. Why is this a dangerous precedent? It effectively means the end of RO as we know it. Why would software developers bother to put time and effort into products for native RO when they can make a quick buck throwing a wrapper around some Windows API? (This argument holds for a hypothetical VA running under Linux too before someone accuses me of anti-MS bias). One thing I certainly don't want to see is RISC OS as a glorified skin for another OS, which is the way I see things going. If anything, VA has become too good, which can only be a credit to the VA team though it poses serious questions for native hardware manufacturers and software developers.


 is a RISC OS Userjmb on 19/05/04 4:39PM
[ 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

  • Qercus reviewed but renewed?
    Forty months after taking out an annual subscription, Martin Hansen ponders whether or not to continue his Qercus sub
     28 comments, latest by hzn on 3/8/07 4:15PM. Published: 27 Jul 2007

  • Random article

  • Simple new font management utility released
    C'est fontastic
     Discuss this. Published: 10 Sep 2007

  • 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
    "I've been attributed with things I didn't say on drobe in an attempt to stir the pot with this situation"
    Page generated in 0.0676 seconds.