When 32bitting isn't all plain sailing

By Chris Williams. Published: 2nd Aug 2003, 19:29:28 | Permalink | Printable

We hate politics

RISC OS oldies APDL have come under fire this week from Iyonix users asking for 32bit updates for various titles in APDL's extensive software back catalogue. It stems from APDL stating that they don't wish to make their software 32bit compatible due to financial reasons.

Before the 32bit RISC OS 5 was launched with the Iyonix, there was the fear that a 32bit RISC OS wouldn't have enough compatible software to make it viable. In the eight months since the Iyonix launch, we've seen major software titles from OvationPro to Photodesk enjoying 32bit compatible releases and this is on top of Aemulor's sucess in supporting legacy applications. With some developers appropriately charging for 32bit updates and others providing them for free, playing the financial card is a new one for us.

It's been suggested by a few people that the RISC OS 5 userbase is actually quite small compared to the number of RISC OS 3 and 4 users out there and therefore the development cost to support them isn't worth it. Yet, it's this kind of ridiculous attitude that's keeping developers supporting age old RISC OS 3 rather than attracting users into buying the latest hardware, software and operating system versions.

Having said that, financial reasons are understandable in APDL's case. Having acquired a lot of software from Clares last year, that's a lot of source code to wade through and therefore a lot of programmer time to make it all 32bit compatible. However, the case of Composition is a little disturbing and rocks APDL's explainations a little.

The popular graphics package Composition was originally published by Clares and is now in the hands of APDL. Having recently heard from a few people including Composition author Rob Davison, we've learnt that APDL were very much against the release of a 32bit upgrade of Compo even though the original author had developed much of update himself. Having promised Compo users that a 32bit upgrade would be made available, Rob finished off the 32bit update and released a patch freely from his website - Compo users can freely download Compo patches from here.

You know, it's probably just a coincidence that APDL's Dave Holden is a shareholder of RISCOS Ltd., (the developers of 26bit RISC OS 4 although RISCOS Ltd. are now warming to idea of a 32bit Select), and also that APDL are particularly close to MicroDigital, (developers of the 26bit RISC OS 4 powered Omega). The MicroDigital Omega's selling point of being able to run all your favourite 26bit software on newer hardware is eroded every time an application is made 32bit - of course, until MicroDigital launches the Omega's XScale co-processor upgrade, dubbed the Armtwister by MicroDigital's David Prosser.

APDL logo

APDL have denied that they are not interested in producing 32bit versions of their software. APDL's Dave Holden explained that 32 bitting an application is often a lot more involved than just re-compiling the source code as support libraries also need to be found and built 32bit compatible, resulting in the whole process as being rather time consuming. This is contrary to Castle's notes on how to approach the 32bit'ing of software.

Dave also pointed out that it was a struggle building 26 bit versions of the older software. If that's the case, we can only prescribe some digital euthanasia. Another problem is the prioritising of which titles to convert first - many users have selected a large range of applications that needed 32bitting which only increases APDL's workload. APDL also reminded us that they are a "comparatively small company" and would prefer to stay in business and not overspend on development.

"We have an extensive program of development work. To spend a considerable amount of money on converting a single application just to work on the Iyonix does not, in most cases, make financial sense as we would simply not sell enough upgrades to recover our costs. Where we have a new development of a program then any new version will (when feasible) be 32 bit neutral", Dave Holden told us today, illustrating that 32bit'ing software isn't all plain sailing in APDL's case.

"In short, it only makes economic sense to do this work if we can produce an enhanced program that would be attractive to the many thousands of mainstream users as well as the much smaller numbers of Iyonix users. Where it's more than a simple re-compile then just the Iyonix users alone may not make a sufficiently large market to justify the considerable costs that could be entailed with some programs.

"Every pound spent just on a 32 bit neutral conversion for the convenience of Iyonix users is a pound that's not available for us to spend on other things, like enhancements and bug fixes for the many thousands of existing users. Plus it's money not available to rescue still more programs from the skip, and every day that passes the source code to another RISC OS program is lost forever."

Tut tut tut. Iyonix users ought to be ashamed of themselves.

Update (3/08/2003)
APDL have stressed that they weren't against a 32 bit upgrade of Compo however the author Rob did need to get APDL's permission to release a 32bit upgrade, according to APDL. APDL are also in the process of 32bitting some of their titles, so we'll pass around the patience pills.

Links

APDL

Previous: July patches and releases
Next: Acorn Publisher explores newsagent options

Discussion

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

In Dave's defence, you can't just recompile ARM code to make it 32-bit compatible! In fact even just recompiling C source code can be a pain (been there, done that).

It's no surprise that WSS are also in the same boat. Their current reason for no 32-bit updates is that they are doing other programming work to pay the mortgage - but I know (certain!) Iyonix users are crying out for long files under SMB/CIFS and NFS.

With APDL taking on a range of software, people expected that they would produce 32-bit versions of them. Dave has effectively quashed that hope.

I wonder what public expectation there will be for other people/organisations who take on existing software? -- [link]

philipnet on 2/8/03 11:05PM
[ Reply | Permalink | Report ]

You have to ask; what is the point of buying up the rights to old titles if there is no intention to develop them further. It surely can't make economic sense just to make the occasional sale of mature products.

Sitting on those titles for whatever reason is one thing, actively discouraging the conversion of programs where the developers are willing to do the work is another entirely.

The future of the platform is in the use 32 bit processors regardless of which manufacturer's machine you are backing. Ensuring that as much software as possible is able to run on new machines is essential for the long term survival of RISC OS, and should out weigh any short term attempts to favour any one company.

---druck

druck on 2/8/03 11:25PM
[ Reply | Permalink | Report ]

might it not be easier to improve the exising product as a 26 bit product then to convert it to 32bit neutral.

-- Bletchley, Milton Keynes

sa110 on 2/8/03 11:56PM
[ Reply | Permalink | Report ]

Might be easier, but as you're doing it analyse it for 32bitconversionness and think how long it would take, and how many sales it would generate.

There's been a lot of software released as 32bit which also has had updated features/bug fixes because those updates have been done but weren't worth a new release. It's a great way to advertise your product too.

eg [link]

The Composition news is indeed odd.

There's the question of support of course, do APDL have access to an Iyonix to test out problems their customers have?

How many of their products don't work with Aemulor?

mavhc on 3/8/03 12:21AM
[ Reply | Permalink | Report ]

It is certainly a more expensive task developing 32bit updates than many people think. I estimate a high four, or low five figure sum. Clearly it is difficult to get a return on such an investment if you are are updating lower volume sales products, or cheap ones.

Obviously if you are updating a more expensive program, then it is easier to justify.

Actually, one of the more annoying things is not 32bit app development, but niggles with 32bit CLib. I spent last week updating a few things because 32bit CLib behaves differently to the 26bit version in a couple of areas!

arawnsley on 3/8/03 10:44AM
[ Reply | Permalink | Report ]

Agreed Andrew. I think for 26/32 bit conversion work especially, StubsG is pretty invaluable here. 32-bit SCL /can/ cause issues with 26-bit software; personally I won't run it unless I need to following a couple too many hours chasing 'unknown' bugs with software which vanish when the 32-bit SCL has been removed.

I'm not totally surprised the cost of developing the updates is as high as that, but it's so scary to see it written like that!!!! -- Andrew Hill,

md0u80c9 on 3/8/03 11:47AM
[ Reply | Permalink | Report ]

"It is certainly a more expensive task developing 32bit updates than many people think. I estimate a high four, or low five figure sum."

This radically depends on the size of the product itself, of course. I'd estimate that it'd take nomore than a day to fix all the bits of assembler in Slayer, for example. (Fortunately, it's mostly BBC Basic, like the other two major RISC OS AVs)

One of the other advantages of moving to 32 bit RISC OS is there are many less viruses that will actually work on it.

Still, if people want a 32bit Slayer, I'll look into it, but it'd likely need rewriting from scratch (and it'd be much simplier because of it.)

nunfetishist on 3/8/03 12:30PM
[ Reply | Permalink | Report ]

Fixing the assembler in Compo was done in an evening - easily. It was running on an Iyonix (with some remaining bugs) at least a month before I had even seen a machine.

Most of the work I put into RISC OS 5 compatibility was related to making it use the application slot rather than dynamic areas. That might have taken a week or so of evenings to write and debug.

(As an aside: It'd be nice if more Iyonix compatible software did the same...)

To the Andrews: YMMV - mine did. IMO 32 bitting anything other than something huge that was written in pure (devious) assembler is not going to be a big deal. Even then, how long did it take Martin Wuerthner to do ArtWorks? A month?

He's a lot brighter than me but still, that'd have to be almost a worst case program.

Rob.

southerner on 3/8/03 1:43PM
[ Reply | Permalink | Report ]

Quite. For the vast majority of stuff - especially when you've done it a few times, 32-bit conversion is very easy, and can generally be done in a time frame of days or less. There are always exceptions of course - ArtWorks, PhotoDesk, and sometimses compiler/library problems, but in general I don't buy the idea that vast amounts of resources and time is required.

-- Peter, drobe.co.uk

mrchocky on 3/8/03 2:05PM
[ Reply | Permalink | Report ]

If ADPL were willing they could always provide the source of selected 26bit only apps (under NDA if required) and I am sure people would be willing to do the conversion (either for a nominal fee or even for free).

Just *look* at the miracles Druck did when converting code *without source*, if ADPL want the stuff converted there are (again IMHO) enough willing people here to give it a go... that being the case if ADPL refuse the option it could be interpreted that ADPL were trying to snuff out RISC OS 5

I'd also point out much *fewer* people have Omega than Iyonix - so if there is no financial case for converting code for Iyonix then there'll even be less for Omega surely ? (Ok, I know Omega can run 26 bit code - but code that exploits its unique (alleged) features will still need to be upgraded to do so - with so few Omega's surely (using ADPL's logic) there's no point in doing so).

The final point I'd make is that with the bulk of developers on Iyonix (or heading that way) may well argue that it is not economic for them to produce code for Omega - given it's single digit userbase.

-- Annraoi McShane,

AMS on 3/8/03 2:05PM
[ Reply | Permalink | Report ]

I was pleasantly surprised to find that Personal Accounts, which I bought from APDL, runs on my Iyonix. It's my most-used software after DialUp and Pluto. I do not yet have Aemulor.

I'm wondering if this is a fluke, as I haven't heard of a 32-bit upgrade. The cursor won't TAB between some of the fields but the rest of it seems to work.

My assembly language calendar program Millennia [1] also seems to run perfectly, although it was written before I knew anything about 32-bit coding, and ARMalyser indicates that there are some bits that shouldn't work.

Martyn

[1] [link]

Martyn Fox on 3/8/03 2:08PM
[ Reply | Permalink | Report ]

For clarity, I would add that the figures I quoted were for a range of relatively medium-large apps, including ones which required some level of re-coding to cope with Iyonix architecture. (ie. look at the 32bit page on www.rcomp.co.uk to get some idea). My point was that APDL have a similar size software catalogue as we do (compounded by fewer in-house apps). It is therefore not overly surprising that they are cautious wrt 32bit. I will say, however, that overall I'm glad that we went the extra mile to support 32bit RISC OS hardware, as well as continuing support of 26bit.

arawnsley on 3/8/03 4:32PM
[ Reply | Permalink | Report ]

Rob: I wish it had taken only 1 month to convert ArtWorks - it was roughly about 3-4 months work. But as you pointed out, this was by far a worst case program due to many reasons (we are talking > 10 MB of source code spread over a hundred source files - all guessed, I have never counted it) and I was doing part of the work without having the source code, which did not make it easier.

On the other hand, my C programs were a matter of hours, so the cost was close to zero. The same could be true for many other programs. For example, I have taken over Formulix from CC and all that was required was a recompile, so the cost is negligible, which is why I offer a free upgrade.

So, Andrew, we are certainly not into four figures for an average C program but you can run well into five figures for something as bad as ArtWorks (and there is only one thing left that comes close... :-)

)

wuerthne on 3/8/03 6:52PM
[ Reply | Permalink | Report ]

I just re-read this article, in what way are APDL close to MD? Just curious,like.

thegman on 3/8/03 7:45PM
[ Reply | Permalink | Report ]

Erm... APDL sell those cheapo machines built using Mico motherboards, for starters. -- Michael Stubbs, Leeds

arenaman on 3/8/03 9:05PM
[ Reply | Permalink | Report ]

Yes, but loads of dealers sell the Iyonix, but I doubt many of them are 'close' to Castle.

Anyway, the only product that APDL has of any note, is Compo, and that is 32-bitted already. How many of us are just itching for a new version of ProArt 24? ;-)

thegman on 3/8/03 9:13PM
[ Reply | Permalink | Report ]

martin>

& what are you alluding to?

your re-doing of !impression?

please

:-)

epistaxsis_RISC OS on 3/8/03 10:59PM
[ Reply | Permalink | Report ]

APDL's website (under "computers") says they can offer any new model of RISC OS computer from MicroDigital, Castle and others.

Has anyone bought an Iyonix from APDL? (Dave Holden was emphatically negative about the Iyonix when I talked to him - why?)

Equally, are APDL still selling the Omega? Has anyone bought one from them?

If not, why not? Is this related to the comments about the "status of the RISC OS desktop market" that Dave Holden supposedly made at WROCC when he visited?

Is there any corroboration for Annraoi's assertion that Omega users are in "single figures" ?!? I personally have seen two given away as prizes, one delivered to an end user, two given to dealers for onward shipment, and two in use by dealers, plus one end user I know who says he has one, so surely they've shipped at *least* ten Omegas by now?

dgs

dgs on 3/8/03 11:06PM
[ Reply | Permalink | Report ]

dgs> I really share your curiousity about Omega figures.

Has anyone out there actually got an Omega? If it's available to buy now, why does MD not reply to emails asking about it's spec? Have the people who *have* bought one had any assurances when the Xscale,FPU,MPEG,Mesa,Ethernet etc. will be delivered?

I have not heard anything from David Holden about these things, but would be interested to hear them.

thegman on 3/8/03 11:21PM
[ Reply | Permalink | Report ]

Keith: What's wrong with Ovation Pro? That's allready been 32bitted.

-- Michael Drake (tlsa) www.smoothartist.com

tlsa on 3/8/03 11:22PM
[ Reply | Permalink | Report ]

wuerthne: Sorry to have underestimated the magnitude of your task while trying to prove my point. :-)

Can I ask how much of that time was spent learning the structure of the program?

I think it could be argued that this time would be necessary for someone taking on a project if they're going to make any sort of meaningful changes.

I've had a quick look but can't find the progress log on your website anymore. I do recall being *very* impressed at how quickly you seemed to get the job done.

Impression next perhaps? ;-)

Rob.

southerner on 4/8/03 1:08AM
[ Reply | Permalink | Report ]

thegman: I believe ProArt24 was entirely written in C and Jon and Frank didn't strike me as the kind of guys to hack around with OS workspace or do anything even faintly dodgy. I think it'd just recompile and run (with the same potential DA niggles as Photodesk perhaps).

Schema might be in a similar situation too. I really would like to see something positive come out of this news story...

ie. The programs that can be converted easily done, and released for RO 5.

Rob.

southerner on 4/8/03 1:20AM
[ Reply | Permalink | Report ]

I'd like to see them converted too, but it's also a good time to cut off te dead wood, we'll see what's getting developed an what is not, then we can spend our pennies on programs which support the RISC OS market, and not ones which have not been developed for years.

thegman on 4/8/03 9:51AM
[ Reply | Permalink | Report ]

I recommend the suggestion above that APDL and WSS give out the source code of the apps with some NDA so that others can look into 32 bit conversion. I guess that there are quite a few users around by now are pretty efficient in this business.

With WSS it is a pity since I'd love things like CDROMFS, LanMan98 and Win95FS on my IYONIX pc.

With APDL I think the behaviour is pretty bad: They keep on aquiring other software and refuse to bring them to 32 bit thus basically stop serious future-proof further development.

Well, I guess that I'm not the only user who doesn't plan to put money with companies not supporting 32 bit - and this has nothing to do with IYONIX pc but basically with me wanting to get RISC OS further into the future and that does mean 32 bit has to be part of the offer!

HzN

hzn on 4/8/03 1:02PM
[ Reply | Permalink | Report ]

26bit has no future, adapt or die. The only question is the rate of adaptation.

mavhc on 4/8/03 1:24PM
[ Reply | Permalink | Report ]

dgs> Sorry I was just going on stuff I read on the net about the Omega in terms of numbers (so it's only an *estimate* from 2nd hand reports), appologies if it came across as a figure written in stone.

Only the purchasers (recipients) of Omega and MD know for certain and neither camp seem to be saying much (which doesn't help).

I think the key point I was making is that *if* ADPL are making the assertion that it is *not* worth their while converting code for Iyonix given its numbers then the case *must* be even worse for Omega where by all accounts fewer machines are out there with customers.

If they're using the numbers sold as an excuse for not supporting Iyonix/32bit then they're (IMHO) being silly as it would also suggest they shouldn't bother with Omega either - if so what's left the RiscPC ?

The final point would be that if Tematic/Castle or other parties *do* choose to make hardware available to large corporations for integration into consumer devices - not having 32bit code ready might be a *very big* mistake.

-- Annraoi McShane,

AMS on 4/8/03 1:42PM
[ Reply | Permalink | Report ]

I think APDL meant that because the Omega can apparently run 26-bit software, no changes at all to old software would be required, hence development time and money could be spent on features which are beneficial to the majority of the userbase, and not just Iyonix owners. I don't agree with their stance, but it's understandable.

thegman on 4/8/03 2:22PM
[ Reply | Permalink | Report ]

Rob: no need to apologise. It was easy to get this impression from the progress log (which is still there, by the way, just go to the ArtWorks 2 page, then click on Progress). Yes, I did the base ArtWorks 1.7 app in just over a month, but do not forget that (1) this was probably more than a man-month of effort because I was working overtime, (2) I had already spent a considerable amount of time before that converting the drawing engine (GDraw et al.), which was very tricky without the sources and (3) I had to spend some more time after that fixing bugs I had introduced. And, (4) I also added the effort of converting my own modules, so that is the overall estimated figure of 3 months.

As for learning the structure of the program: I already knew that inside out when I received the sources due to all the plug-in module programming, but knowing the structure is hardly necessary to do the conversion. You could almost do without even knowing what the application is supposed to do.

I am sure Impression would be less work than ArtWorks due to its simpler structure and due to the fact that I already converted some of its components while converting ArtWorks.

wuerthne on 4/8/03 2:45PM
[ Reply | Permalink | Report ]

thegman> Ok, point taken.

But if APDL do *nothing* to the existing software to enhance it for use on Omega what do the end user gain ? Surely it'll be like running the existing App on a RISC PC but with a faster harddisk.

For all the difference it makes they might as well encourage people to stay with the RPC (and with that sort of stasis surely the market will ultimately die - won't it ?).

If APDL (as you put it eloquently) "development time and money could be spent on features which are beneficial to the majority of the userbase" what then ? In that scenario no software will *ever* use any features that Iyonix (or Omega) have that make them more capable than the RPC.

In fact I'd wager most people have RO3.7 or below, so should we limit filenames (when saved) to 10 characters, refuse to handle more than 77 objects per directory ?????

Surely the aim should be to provide software that existing users *can* use but where a new feature is available that the software can employ it when used on more modern platforms (like Iyonix/Omega). Otherwise there will be little or no reason for *anyone* to upgrade - and the platform will die.

-- Annraoi McShane,

AMS on 4/8/03 2:49PM
[ Reply | Permalink | Report ]

AMS> I agree with everything you say. Personally, I think APDL's view is wrong, and actually quite counter-productive to securing a future for RISC OS. You last point is especially true, I think it's a great way to get people buying newer hardware to give them a taster, and let them know the experience will be better if they upgrade. A good example of this is games, which run *OK* on SA RPC, but run great on Iyonix.

Your second point about encouraging people to stick with the RPC is true again, when the Iyonix first appeared I did not really consider buying one, I thought the price was a bit steep. But now that it can do things that the RPC can't, like good TV cards, lots of USB stuff, and the hard disk is going really fast, I'm considering it again.

I hope you are right about most users being on 3.7 or under, because this means that the userbase is bigger than I thought, 5900 RO4 users + some Iyonix users + some NCs at schools and eveyone else on 3.5/6/7 RiscPCs makes for not a bad number at all, and lots of people on old machines just waiting to be sold something better!

thegman on 4/8/03 3:03PM
[ 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

Adventures with a Lego-cased A7K web server
Having previously built desktop and laptop cases of out Lego bricks, model building Peter Howkins has turned his attentions towards crafting a slim box to slid his A7000 into a rack, alongside other rackmount servers. Having pieced together the housing, Peter puts a legacy RISC OS machine through its paces as an internet-facing server.

11 comments, latest by jess on 3/12/08 2:07PM. Published: 21 Nov 2008

Random article

Taking 32bit for Vantage
See what we did there? We swapped 'granted' for Cerilica's 'Vantage'. See that?

2 comments, latest by moss on 25/10/02 9:22AM. Published: 23 Oct 2002

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
"Contrary to some RISC OS news sites who don't bother to check the facts before they run a story..."
Page generated in 0.0882 seconds.