paul@devon.UUCP (Paul Sutcliffe Jr.) (04/22/87)
So far I have seen three different versions of ARC 5.12 posted to
net.sources. Each of these was supposedly working under some flavor of
Un*x. Someone even posted diffs to the original saying that the
changes allowed ARC to run under XENIX V/286.
Well, I cannot get any of them to work on my Sperry PC/IT running SCO
Xenix 2.1.3. The closest I've come is to get a version to extract from
an existing archive, but I cannot get arc to create a new archive that
it can read itself (much less by the MS-DOS version).
Can anyone supply me with a working version of ARC for Xenix?
- paul
--
Paul Sutcliffe, Jr. UUCP: paul@devon.UUCP
-or- {seismo,ihnp4,allegra,rutgers}!cbmvax!devon!paul
"I love work. I could sit and watch people do it all day!"mdf@osu-eddie.UUCP (Mark D. Freeman) (04/27/87)
In <259@devon.UUCP> paul@devon.UUCP (Paul Sutcliffe Jr.) writes: >Well, I cannot get any of them to work on my Sperry PC/IT running SCO >Xenix 2.1.3. The closest I've come is to get a version to extract from >an existing archive, but I cannot get arc to create a new archive that >it can read itself (much less by the MS-DOS version). > >Can anyone supply me with a working version of ARC for Xenix? Me too! Thanks! -- < < < < < < < < < < < < < < < < < < < <> > > > > > > > > > > > > > > > > > > > Mark D. Freeman mdf@osu-eddie.uucp InfoSolv Corporation mdf@Ohio-State.arpa 6099 Riverside Drive ...!cbosgd!osu-eddie!mdf Dublin, OH 43017 Guest account at The Ohio State University (614) 761-8444 < < < < < < < < < < < < < < < < < < < <> > > > > > > > > > > > > > > > > > > >
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (04/29/87)
In article <259@devon.UUCP paul@devon.UUCP (Paul Sutcliffe Jr.) writes:
So far I have seen three different versions of ARC 5.12 posted to
net.sources. Each of these was supposedly working under some flavor of
Un*x. Someone even posted diffs to the original saying that the
changes allowed ARC to run under XENIX V/286.
There is a bug in the version of ARC distributed, and I can tell you
what it is (but not where, yet). The version distributed failed on my
Xenix, too. I didn't much want to go after it with adb, but thought I'd
take it home and use sdb on a unix-pc. Lo and behold, the memory fault
went away and the program runs fine. Also ran on a SRV Vax.
Then I decided that it was the 80286 archetecture (again) and tried it
on Microport, where it worked, too. After MUCH digging I have located
the source of the problem. Machines which load all user data space into
one lump do memory management on the lump. On a Vax or 68k machine you
get no problem if an array index is off by one, as long as the array
isn't the last thing in memory.
Microport seems to do about the same thing, starting a new segment only
when really needed. Xenix large model seems to generate a large number
of segments, one for each array larger than (something). This give full
bounds checking on every array. The truth is that one of the array refs
is WRONG, and clobbers something else in user memory. The only way this
will fail is on hardware which does full bounds checking. I haven't
found the actual location of the problem yet, if someone beats me,
please post. I will certainly post it back to SEAware if I locate it
myself.
NOTE: I have cross posted this to several groups where there have been
either discussions of segmented machines or where the users are interested
in solving bizarre and obscure problems.
--
bill davidsen sixhub \ ARPA: wedu@ge-crd.arpa
ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen
chinet /
"Stupidity, like virtue, is its own reward"