XCG112@DBNUAMA1.BITNET.UUCP (04/28/87)
I'm extensively using ARC, and I think it's a very good program. Could someone
please send me anything of the following:
1. ARC for the IBM/PC (UUencoded and, yes, ARCed will do nicely)
2. The ARC sources for the ST (some little things I'd like to modify)
3. A utility (or a mod within ARC) to be able to MERGE two archives
4. A utility (or a mod within ARC) to be able to preserve directory or sub-
directory structures within an archive (I currently save a text file
obtained by "tree >STRUCT.INF", and use that later to "md" and "copy"
the files back. This works, but is very clumsy)
Any help will be most appreciated. But please remember: I am on BITNET and
have no access to comp.atari.whatever ...
Bitnet: XCG112@DBNUAMA1 Volker A. Brandt
ARPAnet: XCG112%DBNUAMA1@WISCVM.WISC.EDU (Bonn, West Germany)brachman@ubc-cs.UUCP (04/29/87)
In article <8704272301.AA02457@ucbvax.Berkeley.EDU> XCG112@DBNUAMA1.BITNET writes: > >I'm extensively using ARC, and I think it's a very good program. Could someone >please send me anything of the following: > > 2. The ARC sources for the ST (some little things I'd like to modify) > >Bitnet: XCG112@DBNUAMA1 Volker A. Brandt >ARPAnet: XCG112%DBNUAMA1@WISCVM.WISC.EDU (Bonn, West Germany) In January, Robert Wilhite <wilhite@usceast.uucp> posted arc to net.sources. While this version seems to work fine on the VAX, it does not work on the Sun (try to create or add to an archive). I recently spent a few hours looking at the code and found several bugs and quite a bit of questionable coding. Lint yells alot too. In short, it is badly in need of a rewrite. It's a miracle it runs on the VAX. (To be fair, Robert is not the sole author.) I'm not sure how the version of arc I use on my ST corresponds to the version I have source for, but from time to time I've experienced strange problems with my ST arc (usually two bombs). ----- Barry Brachman | {ihnp4!alberta,uw-beaver,seismo}! Dept. of Computer Science| ubc-vision!ubc-cs!brachman Univ. of British Columbia| brachman@cs.ubc.cdn Vancouver, B.C. V6T 1W5 | brachman%ubc.csnet@csnet-relay.arpa (604) 228-4327 | brachman@ubc.csnet
baron@transys.UUCP (04/30/87)
In article <1296@ubc-cs.UUCP> brachman@ubc-cs.UUCP (Barry Brachman) writes: >In January, Robert Wilhite <wilhite@usceast.uucp> posted arc to net.sources. >While this version seems to work fine on the VAX, it >does not work on the Sun (try to create or add to an archive). I recently >spent a few hours looking at the code and found several bugs and quite a >bit of questionable coding. Lint yells alot too. In short, it is badly in >need of a rewrite. It's a miracle it runs on the VAX. >(To be fair, Robert is not the sole author.) I agree. I have been working on the sources to arc for a little while to get it to run under SCO Xenix on an IBM AT. It would seem to work fine as long as the archived members were all less than some magic size (around 64k), but gave all kinds of core dumps and funny messages if the size were larger. Turns out there is some code in the header reading and writing routines that tries to shift a long by 8, 16 and 24 bits respectively then ands the result with 255 to get a byte order independent representation of the size into the output file. The shift values of 16 and 24 return zero! I have changed this and now I can un- arc anything that comes through (so far). I can add items to an archive, but I can not crunch them (memory fault). I am working on this. There were also references to null pointers, and passing longs when you needed to pass an int. On a 286 under xenix passing the wrong parameter type is guaranteed to land you in bananaville. I only found this by examining the assembler output file, which showed the stack being misadjusted. This piece of software really puzzles me because the original ARC was for IBM PC's. If anyone wants the diffs to make it work (as well as it does now) e-mail & I will be happy to send them to you. Enough response will warrant a posting. The changes should be portable, as I used no shift instructions but used constant division and multiplication instead.