jvt@its.bt.co.uk (John Trickey) (11/09/90)
THE ORIGINAL QUESTION: How do you stop Sozobon C and programs compiled
by it crashing under Mupfel (Gemini's Shell).
Thanks to Ant <ant@mks.uucp> and Bob <balkwill@encs.dnd.ca>
for responding to my posting. Their advice was to fix the bit
manipulation code in the assembler and the memcpy()/memmove()/bzero()
fns in dlibs. Basically this worked, but not without problems.
The first thing I discovered was that I had 1.01 of Sozobon so I obtained
1.2 and remade *everything* = MAJOR MISTAKE. This caused every thing in
sight to behave strangely. My application, which runs under Unix, MS/DOS
and TOS1.6+Gulam fell apart at initialisation, Sz Make could not find
cc,jas etc when run under Mupfel (yes it did not bomb) but it was
OK with Gulam. After *much* tracing I found the problem in a fn call
where fn(&structure, int1, int2) produced *strange results*. It seemed
the params got scrambled with int2 taking int1's value, int1 became 0
and the pointer was left alone. Recoding as
fn((long)&structure, int1, int2) got it to behave but at this point I
decided things had become *extremely* *silly* and there must be some
other cause.
I decided the only way was a structured approach taking each change
at a time. The biggest problem was actually knowing which mods to
make. So many fingers being in the pie and an absence of any
controlled release of patches from the authors makes the whole thing
a nightmare. OK thats enough of the moans - here is what I did the
second time through, starting with the original 1.01 binaries & sources.
At each numbered stage the resulting code is installed.
ACTION EFFECT
1: Modified dlibs12 alloca.s bzero.s Application still bombs
memcpy.s as in Tohru Nishimura's
Mailing.
2: Corrected the hcc bug in fun.c from No Test
a reposting from Johann Ruegg (the
only note I have from an Author!!!)
3: Corrected jas opcodes.h - again No Test
Tohru's posting. Two worries here
a) I found another & completely
different version of opcodes.h
purporting to fix the same bug!!!!
Sorry I have no details, they're
on the m/c at home.
b) Tohru's explanation of the faulty
lines does not match his diff output.
4: recompiled dlibs functions of 1: plus Application now runs OK
lmemcpy.s which also had a bit instr.
5: Make *all* binaries including Application & Compiler runs OK
upgrades to hcc 1.2 and top 1.2
also mods to peep2.c peep3.c
reposted by Michal Jaegermann.
I have not installed the mods to initargs.c from lrh or top1.2x from Tohru.
This is because it now works and these unofficial patches, while maybe
being a good thing , will only stack up problems should 1.3 or
whatever be released.
OK thats it. I hope this tale will help others to avoid the pitfalls.
As a parting shot - A MESSAGE TO THE AUTHORS, how about releasing
patches on a regular basis through c.s.a. Then there would be no
confusion and an otherwise excellent package would not be spoilt
by poor followup.
John
--
John Trickey <jvt@its.bt.co.uk> || ..!mcsun!ukc!axion!its
G4REV @ GB7SUT Voice: +44 21 333 3369
#include <std/disclaimer>