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

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".