Message from discussion 32-bit SharedCLibrary on the A9

Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.pipex.net!news.pipex.net.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Sep 2005 14:26:42 -0500
Date: Fri, 30 Sep 2005 20:26:40 +0100
From: John-Mark Bell <jmb...@ecs.soton.ac.uk>
Newsgroups: comp.sys.acorn.programmer
Subject: Re: 32-bit SharedCLibrary on the A9
Message-ID: <d739a6b24d.jmb@moose.pipex.net>
References: <19f529b24d.philip@philipnet.com> <0b9c2db24d.james@iyonix.local> <f4c278b24d%beamendsltd@btconnect.com> 
 <4db280f834john@cartmell.demon.co.uk> <e0f58db24d%beamendsltd@btconnect.com> <4db2a07097steve.pampling@dsl.pipex.com>
User-Agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.10) NewsHound/1.43-32-pre2
Lines: 79
NNTP-Posting-Host: 85.210.50.208
X-Trace: sv3-nxMs//5AsrTpw70EKg8MYoQRb80GHlt1FYV683xvRCZ742lSV4VxOZWu7oIJ0SQWPKGzons/FPC2VFU!R49V+9LvCHB0iPSp9/4x1BFSHmt9JELcN8V8ehflqsLtt7ydj20gver7oN3TTIu5gJ6T4clYKyNb!JJYEerw9dQ==
X-Complaints-To: abuse@dsl.pipex.net
X-DMCA-Complaints-To: ab...@dsl.pipex.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.32

In message <4db2a07097steve.pampl...@dsl.pipex.com>
          Steven Pampling <steve.pampl...@dsl.pipex.com> wrote:

> In article <e0f58db24d%beamends...@btconnect.com>,
>    beamendsltd <beamends...@btconnect.com> wrote:
> 
> > Now I'm not convinced...... and "The Keepers Of The OS" *still*
> > being stupid does not inspire much confidence.
> 
> At the risk of start some kind of major flame war, I think it should be
> pointed out that the development of the OS on the A9 was done by ROL while
> they had full knowledge of the existing 32 bit systems set in use by users
> (Iyonix).
> If there are incompatibilities it would appear they did it deliberately.

Sigh. It's really very, very simple[1]:

1) The SharedCLibrary in Adjust32 is a 32bit version of the one present in
   the 26bit Adjust (it may well have had other improvements besides being 
   32bitted but, as I've not seen it, I can't comment, nor is that relevant 
   to this discussion).

2) The SharedCLibrary available for download from iyonix.com is _not_ 32bit
   compatible. Therefore, it won't work on an A9 because the A9 is running 
   in 32bit mode (nor, incidentally, would it softload on an Iyonix, for the
   exact same reason).

3) Existing applications which use the SCL and which are able to run on 
   32bit machines come in two possible forms:
   
   a) Linked against StubsG.
   b) Linked against the Castle stubs.

4) Applications which fall into category "a", above, should work perfectly
   well on the A9 (as they're already mode neutral and don't care about the
   SCL that they're using)

5) Applications which fall into category "b", above, are more complex:

   i) They may only use the functionality of the SCL which is provided by
      the 26bit variants and that on the A9.
   ii) They may use the enhanced functionality present in the Castle SCL.

   Both categories of application currently perform something akin to:
   
    RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib
    RMEnsure SharedCLibrary 5.34 Error Foo needs SharedCLibrary 5.34 or later
   
   in their !Run file and therefore will not immediately run on the A9 (as 
   the SCL version check will fail).

So, it is only applications that are covered by point 5 that will have
difficulty running on the A9:

  a) Applications in category 5i may work perfectly well already, if the SCL
     version checking is removed from their Run file. I don't advise doing 
     this as it could well have unforeseen side effects.
     
  b) Applications in category 5ii will not work, even with the SCL version
     check removed (as I documented in another post in this thread, the 
     application will abort with the message "Unknown library chunk")

So, what are the solutions to the above mess?

a) Application developers could rebuild their code against StubsG. For 
   applications in category 5i, this is likely to be highly trivial. For 
   applications in category 5ii, the amount of work and/or wheel reinvention
   required depends upon the application.

b) Castle could release a 32bit compliant build of their SCL which can be
   softloaded on the A9.

I'll leave you to decide which of the solutions is likely to result in A9 
support for the most applications in the shortest possible period of time.


John.

1. For some value of "simple".