In message <199803020853.IAA27777@muppet-perishers.doc.stu.mmu.ac.uk>
          64310205@doc.mmu.ac.uk (Stephen Potts) wrote:

> I've tried on a couple of occasions downloading a new version of Gzip, but
> I have not yet found a StrongArm compliant one.  Does anyone know where to
> find one ?

I presume you mean for Risc OS.  Here are the instructions I followed in
order to persuade mine run on the StrongARM.

>From a posting by Pete Burwood, at around the time that the SA was released.

   For those people who are brave, then most programs will need two
   patches. Any program calling exec() (such as gcc) are more complicated
   to patch (but not impossible), so I won't cover them now.

   Note, I don't convert the swi call to OS_CallASWI, but just insert a
   dummy SWI instruction at the location which will be modified to the
   actual SWI instruction. While ART probably don't condone this, it does
   work.

   Step 1. Unsqueeze the application to a new location, say ram:util. You
   should use adfs::4.$.Utilities.Patches.!Patch.Modules.UnSqueeze rather
   than anyother unsqueezer since I've noticed that some of them don't work
   on SA.

   Step 2. Fix the os_swi function. Load ram:util into Zap in byte mode and
   search for

     \&00\&00\&00\&00\&ff\&03\&8c\&18\&00\&00\&a0\&73\&f0\&83\&fd\&e8

   and change the fourth 0 to &ef. Check the code in code mode and it
   should look like

      SWI     OS_WriteC    ; this was ANDEQ R0,R0,R0
      STMNEIA R12,{R0-R9}
      MOVVC   R0,#0
      LDMIA   R13!,{R4-R9,PC}^

   Step 3. Fix the __fptest function. Search for

     \&ff\&ff\&ff\&ea\&00\&00\&00\&00\&0e\&f0\&b0\&e1\&80\&81\&00\&ee

   and change the sequence of four 0's to \&80\&81\&00\&ee. Check the code
   in code mode and it should look like

      B       l1       ; this will be &EAFFFFFF
   l1
      MVFD    F0,F0    ; this was ANDEQ R0,R0,R0
      MOVS    PC,R14
      MVFD    F0,F0

   Step 4. Save the modified file and resqueeze if you wish. Run it to see
   if it works. It will fail immediately with some error message such as
   'String not recognised' if you haven't patched it correctly.

   It is probably worth making sure that each search string matches only
   once in the file. If it matches more than once, then you need to examine
   the code to see which is the correct sequence to patch. If it doesn't
   match at all, then you've either got a program linked with the newer
   UnixLib (how did you manage that!) or with an older UnixLib which used a
   different instruction sequence.

   Note, there is a function called __fpclr which gets called on a SIGFPE,
   and modified the __fptest function but I haven't patched this. This is
   unlikely to be a problem with 99% of programs. If it is then you are on
   your own :-)



Chris