frisk@rhi.hi.is (Fridrik Skulason) (02/13/90)
The binaries that have appeared on c.b.i.p. have generally been UUencoded. What I would like to propose now is a general switch to XXencode. The two methods are very similar, both translate two characters in the range [0..255] into three printable characters in a 64 character set. The difference is in the selection of the characters used. XXencode uses A-Z, a-z, 0-9,"+" and "-", but UUencode uses most of the printable characters, other than a-z. So - why use XXencode ? UUencode is, after all, generally available and there have not been any serious complaints in the past. The reason is that in some cases there are problems with inter-network gateways. Some of the BITNET/Internet gateways (for example one in Denmark) perform a translation which is (to put it mildly) incorrect. In some cases this results in the mapping of two characters into one, which makes transmission of UUencoded binaries to/from BITNET sites in some countries is almost impossible. Of course the best solution would be to fix the problem, but attempts to do so have been unsuccessful. It seems that the problem is that various character sets on IBM mainframes use different positions for characters like "[", "!" and "@". The source for XXencode and XXdecode is available both in C and Basic. I have compiled the C source without problems with Turbo C 2.0 and on a HP/UX system. One a side note - when c.b.i.p starts running again, which of the available file-compression utilities do the readers of the group want to be used ? ZOO and ZIP are obvious candidates, but there may be other possibilities. Any suggestions ? Or maybe we should just leave the decision to the new moderator. -- Fridrik Skulason - University of Iceland, Computing Services. frisk@rhi.hi.is Technical Editor, Virus Bulletin.
austin@bucsf.bu.edu (Austin H. Ziegler, III) (02/14/90)
>>>>> On 13 Feb 90 10:59:08 GMT, frisk@rhi.hi.is (Fridrik Skulason) said: Fridrik> One a side note - when c.b.i.p starts running again, which of the Fridrik> available file-compression utilities do the readers of the group Fridrik> want to be used ? ZOO and ZIP are obvious candidates, but there Fridrik> may be other possibilities. I would not suggest ZOO at all, because that particular program has not properly undone files for me more often than not. It is a good freeware program, to be sure, but I have not been able to get it to work in most cases of c.b.i.p postings after they have been properly downloaded. I think that the two choices should be LHArc or PKZip, with whichever compression utility being used be posted first on c.b.i.p. I am strongly in favor of LHArc 1.13c for several reasons. 1) It takes up about 1/4 the space that PKZip 1.02 does. 2) It is freeware (I just checked the manual). 3) The compression is comparable with PKZip (I did some testing between LHArc 1.00 and PKZip 1.02 and found that PKZip got an average 52% total compression whereas LHArc 1.00 got a 51% compression.) 4) It is easy to use and contained in one program. No longer do you have to use PKZip to pack the files and PKUnzip to unpack the files and Zip2Exe to make them self extracting. LHArc does those with LHArc with a parameter (m or a to pack, x or e to extract, and s to make a file self-extracting). I think that LHArc is the obvious choice for the c.b.i.p postings. Fridrik> Any suggestions ? [or comments?] Fridrik> Or maybe we should just leave the decision to the new moderator. That is a possibility, but I think that we should at least suggest what we think is best to him. just my two bytes, austin -- +--------------------------------------------------------------------------+ | The surgeon general of the United States of America has determined that | | reading USENET turns your brain to jelly, leaving nothing to claim or to | | disclaim. +--------------------------------------------------------------+ +-----------+ Austin Ziegler austin@bucsf.bu.edu or austin@buengf.bu.edu | | 700 Commonwealth Box 2094, Boston, Massachusetts 02215 BUENG '93 | +--------------------------------------------------------------------------+
hoyt@plains.UUCP (Dean Hoyt) (02/14/90)
In article <1513@krafla.rhi.hi.is> frisk@rhi.hi.is (Fridrik Skulason) writes: >The binaries that have appeared on c.b.i.p. have generally been UUencoded. >What I would like to propose now is a general switch to XXencode. I would not object to this switch. First though I would need sources to xxencode and xxdecode > >One a side note - when c.b.i.p starts running again, which of the available >file-compression utilities do the readers of the group want to be used ? >ZOO and ZIP are obvious candidates, but there may be other possibilities. > >Any suggestions ? Yes I would like to submit a vote for Zoo. The reasion for this is it runs on many platforms and I have tools set up to use it for an archive I maintain on our local machine. >Fridrik Skulason - University of Iceland, Computing Services. >frisk@rhi.hi.is Technical Editor, Virus Bulletin. Dean Hoyt <hoyt@plains.nodak.edu> uunet!plains!hoyt (UUCP) hoyt@plains (Bitnet) keeper of the pc archive. FTP plains user anonymos -- Dean Hoyt <hoyt@plains.nodak.edu> uunet!plains!hoyt (UUCP) hoyt@plains (Bitnet) keeper of the pc archive.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/14/90)
In article <AUSTIN.90Feb13152915@bucsf.bu.edu> austin@bucsf.bu.edu (Austin H. Ziegler, III) writes: | Fridrik> Any suggestions ? [or comments?] | | Fridrik> Or maybe we should just leave the decision to the new moderator. | | That is a possibility, but I think that we should at least suggest | what we think is best to him. Many people indicated that they wanted to be able to unpack the archives on UNIX machines and read the docs before taking the time to download to a DOS machine. That leaves arc and zoo. zoo was voted by the readers last year and doesn't ask for money. Now that PKARC is (mostly) gone zoo is a lot faster on the PC end, too. In any case, I sent out the first posting in the new c.b.i.p. and would like to hear if it gets out okay. Some sites have Rahul listed as moderator and some have me, and that may make for poor propigation. Let me know if you get the test posting. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (02/14/90)
In article <1513@krafla.rhi.hi.is> frisk@rhi.hi.is (Fridrik Skulason) writes:
%>So - why use XXencode ? UUencode is, after all, generally available and
%>there have not been any serious complaints in the past.
%>
%> [stuff deleted]
%>
%>The source for XXencode and XXdecode is available both in C and Basic. I
%>have compiled the C source without problems with Turbo C 2.0 and on
%>a HP/UX system.
%>
%>Fridrik Skulason - University of Iceland, Computing Services.
%>frisk@rhi.hi.is Technical Editor, Virus Bulletin.
Where is XX[en|de]code available? I've been looking for it for about 6
months, and I've been unable to find it. I claim that it is not
available, and that is why it is not widely used. I only rarely see
things XXencoded.
Kenneth J. Hendrickson N8DGN kjh@usc.edu ...!uunet!usc!pollux!kjhbk@kullmar.se (Bo Kullmar) (02/14/90)
frisk@rhi.hi.is (Fridrik Skulason) writes: >The binaries that have appeared on c.b.i.p. have generally been UUencoded. >What I would like to propose now is a general switch to XXencode. >The source for XXencode and XXdecode is available both in C and Basic. I >have compiled the C source without problems with Turbo C 2.0 and on >a HP/UX system. I have never seen any source for something called XXdecode on comp.sources. My Danish newsreader nn supports uudecode, but not as far as I know XXdecode. This means that I don't want XXencode for the moment. The obvious solution to the problem in Denmark is to skip the IBM network and use the unix network without any silly EBCDIC-coding! >One a side note - when c.b.i.p starts running again, which of the available >file-compression utilities do the readers of the group want to be used ? >ZOO and ZIP are obvious candidates, but there may be other possibilities. Almost all in the PC enviroment uses ZIP and so do I, but I don't have a goot working version of ZIP on my System V box. I do the packing and unpacking on my PC. I think that ZIP is the obvious choice. ZOO does not pack as good as PKZIP does. But I know why a loft of unix users prefers ZOO... >Or maybe we should just leave the decision to the new moderator. Agree. --- Bo Kullmar, Helsingoersg. 38, S-164 42 KISTA, Sweden, Phone +46 8 7511518 UUCP: {uunet,mcvax,munnari,cernvax,diku,inria,prlb2,tut,ukc,unido} !sunic!kullmar!bk Internet: bk@kullmar.se
bobd@fwi.uva.nl (Bob Diertens) (02/14/90)
In article <1513@krafla.rhi.hi.is> frisk@rhi.hi.is (Fridrik Skulason) writes: >The binaries that have appeared on c.b.i.p. have generally been UUencoded. >What I would like to propose now is a general switch to XXencode. > > .... some text skipped > >One a side note - when c.b.i.p starts running again, which of the available >file-compression utilities do the readers of the group want to be used ? >ZOO and ZIP are obvious candidates, but there may be other possibilities. > >Any suggestions ? > >Or maybe we should just leave the decision to the new moderator. I don't care about which utilities are used, as long as they are posted to the net. Don't make these utilities available at some site, where most people can't reach them (most people do not have ftp access). ------------------------------------------------------------------------------ Bob Diertens University of Amsterdam bobd@fwi.uva.nl the Netherlands bobd%fwi.uva.nl@hp4nl.nluug.nl ------- The Art of Flying: throwing oneself at the ground, and missing.
roy@comcon.UUCP (Roy M. Silvernail) (02/14/90)
In article <AUSTIN.90Feb13152915@bucsf.bu.edu>, austin@bucsf.bu.edu (Austin H. Ziegler, III) writes: > I am > strongly in favor of LHArc 1.13c for several reasons. 1) It takes up about > 1/4 the space that PKZip 1.02 does. 2) It is freeware (I just checked the ^^^^^^^^ Even better, it's really Public Domain. (Thanks, Yoshi!) > manual). 3) The compression is comparable with PKZip (I did some testing > between LHArc 1.00 and PKZip 1.02 and found that PKZip got an average 52% > total compression whereas LHArc 1.00 got a 51% compression.) 4) It is easy > to use and contained in one program. I have to agree, Austin. The only drawback LHarc has is speed. It *is* slow, but very tight, and the overhead for a self-extractor is a mere 1322 bytes. Because the compression is so similar, I usually use ZIP for general archiving on my systems, and LHarc for making SFXs. Another vote, then, for LHarc! -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>
TRL3@psuvm.psu.edu (Tim Larson) (02/14/90)
In article <22867@usc.edu>, kjh@pollux.usc.edu (Kenneth J. Hendrickson) says: > >Where is XX[en|de]code available? I've been looking for it for about 6 >months, and I've been unable to find it. I claim that it is not >available, and that is why it is not widely used. I only rarely see >things XXencoded. > >Kenneth J. Hendrickson N8DGN kjh@usc.edu ...!uunet!usc!pollux!kjh XXde/encode are available at simtel20.arpa in pd1:<msdos.filutl>toadxx11.arc pd1:<msdos.filutl>xxcp.arc, pd1:<msdos.starter>xxd11.bas, and pd1:<msdos.starter>xxdecode.txt. The last two are bootstrap programs in BASIC and DEBUG, respectively. Of the first two, I'm not sure which is the more complete copy (since I have not downloaded them) but the other files on simtel called toad* include source, so try that one (it's also the smaller one by about 4:1). As for my two bits worth, I wouldn't mind using XXdecode since we have problems here with improper translation from EBCDIC to ASCII, but I like using ZOO, since it is freeware and I have never had any trouble with my copy of it. Any tools that the group decides on could easily be posted to c.b.i.p as a starter kit on a regular basis, to provide them to everyone. After all, that's how most of us got ZOO. (gasp) -Tim Larson trl3@psuvm.bitnet
w8sdz@smoke.BRL.MIL (Keith Petersen) (02/15/90)
In article <22867@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >Where is XX[en|de]code available? I've been looking for it for about 6 >months, and I've been unable to find it. I claim that it is not >available, and that is why it is not widely used. I only rarely see >things XXencoded. Sometimes I wonder if it's worth the effort to make SIMIBM.ARC, the complete index of the MSDOS collection at SIMTEL20. People don't seem to be using it. If they were, postings such as this wouldn't occur. XXencode/XXdecode has been available from SIMTEL20 for 3-4 years! In addition, I have posted it to cbibmpc and cbibmpcd in several occasions. Keith -- Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1 Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
brad@looking.on.ca (Brad Templeton) (02/15/90)
May I suggest my ABE encoder? It's free, runs on DOS, Unix and other machines, and was designed with a group like comp.binaries.* in mind. It supports UUENCODE as one if its encoding methods, so you don't need a dabe program to decode such an encoding. Or it comes with tiny (< 4K byte source) decoders for the two ABE formats that can be posted with each encoding or at regular intervals at miniscule cost. In any ABE format ABE has the following features: a) Recover random scrambling easily b) Just run dabe on a series of files, with any added junk, parts in random order, duplicates, reposts, headers etc. and you get your binary if it can. ie. dabe /usr/spool/mail/mybox or dabe /usr/spool/news/comp/binaries/ibm/pc/101* works! Also creates partial files with gaps if instructed. c) CRC-32, checksums and byte counts on each block. d) Support for owners, dates, strange filenames etc. The ABE formats also support: Smaller encoding that uuencode on non-compressed files Text inside binaries is encoded as itself, and is thus readable -- you can look at a binary and figure what it is. Extensible features -- the decoder can be taught to understand more than the encoders use. The ABE2 format avoids all characters that have been known to be munged on USENET, for example by translation to EBCDIC & back. In short it was designed to handle all the typical problems of binary distribution over USENET. It also can encode multiple files, although it is not really an archiver. Here is the header of this message in /tmp/hdr, abe encoded, with comments This is a bit bulky for a very short file, but a small cost on a longer file. The first 3 chars are an optional 'line number'. If this file gets mucked up or split into parts, 'sort' can restore it! ;ABE ASCII-Binary-Encoding (by Brad Templeton) ;Use 'sort' and/or 'dabe' to decode T./z$$filecount=1 /* how many files in this encoding */ T.0N##S1000,1000,1000,ABE1 /* version info */ T.1N$$blocking=false /* not a blocked header */ T.2N$$uname=hdr /* multi-OS filename */ T.3f$$os=unix /* OS that did encoding */ T.4t$$fname=/tmp/hdr /* filename under that OS */ T.57$$owner=brad /* owner of file under that OS */ T.6l$$date=635042028 /* unix timestamp on file */ T.7p$$perm=33204 /* unix style permission mask */ T.8O$$size=226 /* bytes in file */ /* below we get the character set mapping for this file */ T.99""%C=<;M:987M65/4J3210M/.-,M+*)(M'&%qL`_^]% T.A0""&.\[Z%Y%&'%()*+%,-WX%0123%4567%89:;%<=>?% T.BI""'@ABC%DEFG%HIJK%LMNO%PQRS%TUVW&XYZ[M\]^_M T.CU""(`abc@defg%hijk%lmno%pqrs.tuvw%xyz>&?@ABM T.Dk"")DFGHMIJKLMMNOPMQRSTMUVabMcdefMghijMklmnM T.Ez""*oprsMtuvwMxyz%N&'()u*+,-u./01u2345u6789u T.F5""+:;<=u>?@AuBCDEuFGHIuJKLMuNOPQuRSTUuVWXYu T.GH"",Z[\]u^_`aubcdeufghiujklmunopqurstuuvwxEt /* here is the actual encoding, space is '.', NL is '/' */ T.H3Newsgroups:.compWbinariesWibmWpcWd/Subject:.Re:.xx.vsW.uu/Summary T.Ia:./Followup-To:./Distribution:./Organization:.Looking.Glass.Softw T.J8are.LtdW/Keywords:.xxencode.uuencode.zoo/References:.<1513@krafla T.KpWrhiWhiWis>.<3418@plainsWUUCP>/ /* end of file stuff, and CRC */ T.Lt$$end_file=hdr T.M5$$filecrc32=3951218314 T.NB##E20970 ;End of ABE encoding -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
frank@hpuamsa.UUCP (Frank Slootweg CRC) (02/15/90)
I prefer UUencode because it is widespread. However I have been bitten
by the character set ("stty(1)" "kill" character was set to "@").
Since you indicate XXencode/XXdecode runs on HP-UX (and the PC),
I don't really care :-)
On the archiving/compression utility: I vote (are we voting? :-)) for
LHARC. As a previous poster said: It is as efficient as anything else,
free, one program, very simple to use, doesn't fail on you, etc.
Frank Slootweg, Hewlett-Packard, HP-UX Support, Dutch Customer Response Center.ttp@lanl.gov (T T Phillips) (02/15/90)
PKZIP is possibly the best shareware program that I have ever seen. The compression is much, much better than ZOO. Since there is now available a PD unZIPer for Unix machines, I vote for ZIP. The complete ZIP utility will probably be available within a year or two. As for xx vs. uu, uu is less trouble for most people because it is widely available, but xx should work just as well. Terry Phillips Los Alamos National Laboratory ttp@beta.lanl.gov
wcurtiss@x102c.harris-atd.com (Curtiss WC 67625) (02/16/90)
In article <493@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > > Many people indicated that they wanted to be able to unpack the >archives on UNIX machines and read the docs before taking the time to >download to a DOS machine. That leaves arc and zoo. zoo was voted by the >readers last year and doesn't ask for money. Now that PKARC is (mostly) ^^^^^^^^^^^^^^^^^^^^^ I think the above is an important consideration. I don't like the implications of the a newsgroup requiring the use of a program which costs money. Yes, I know that you don't HAVE to register your copy of some-other-archiver, but you should in the interest of shareware. And for all the people who extract the binaries on their UN*X machine (myself, included): Now that ZIP, and LHarc have been ported to UN*X, why don't we port one of the various this-archiver-to-that-archiver programs. Such a program could be added to an automatic extraction script, and you can have whatever kind of archive desired. And we'll all be happy? Maybe? ------------------------------------------------------------------------------- William Curtiss 407/984-6383 | "The only good martyr Harris GISD, Melbourne, FL 32902 | is a dead martyr." Internet: wcurtiss%x102c@ess.harris.com | <-- New address
frotz@drivax.UUCP (Frotz) (02/16/90)
brad@looking.on.ca (Brad Templeton) writes:
] May I suggest my ABE encoder? It's free, runs on DOS, Unix and other
] machines, and was designed with a group like comp.binaries.* in mind.
I know that this will generate a lot of traffic, but let's get
Brad and Bill post the source to ABE w/DOS executable and see what the
success is in getting it running on all prominent sites. I have no
problem in upgrading the toolset IF AND ONLY IF the toolset is in use
everywhere (CBIP, and locally). Locally, I can convince people that
this is the tool of choice. Remotely, requires the decision of the
CBIPD community.
Also, this tool does not have to deal with the stigma of the
Clarinet tools. Thanks Brad!
] It supports UUENCODE as one if its encoding methods, so you don't need
] a dabe program to decode such an encoding. Or it comes with tiny (<
] 4K byte source) decoders for the two ABE formats that can be posted
] with each encoding or at regular intervals at miniscule cost.
] In short it was designed to handle all the typical problems of binary
] distribution over USENET. It also can encode multiple files, although
] it is not really an archiver.
So, lets get the tool distributed in CBIP and see how people like. Then
have a vote one month after it's posting to determine whether the group
should switch.
$0.25 worth. (Inflation;-)
--
Frotzjmerrill@jarthur.Claremont.EDU (Jason Merrill) (02/16/90)
In article <43758@lanl.gov> ttp@lanl.gov (T T Phillips) writes: >...The complete ZIP utility >will probably be available within a year or two. >... Why do you say that? Phil Katz has not released source for the ZIPping algorithm -- just unZIPping. I would be happy with just a fully-featured UNZIP, but what we have now doesn't qualify. (By fully-featured I mean with all the options of PKUNZIP.) -- Jason Merrill jmerrill@jarthur.claremont.edu
wsinrn@lso.win.tue.nl (Rob J. Nauta) (02/16/90)
In article <7620005@hpuamsa.UUCP> frank@hpuamsa.UUCP (Frank Slootweg CRC) writes: > > On the archiving/compression utility: I vote (are we voting? :-)) for >LHARC. As a previous poster said: It is as efficient as anything else, >free, one program, very simple to use, doesn't fail on you, etc. > >Frank Slootweg, Hewlett-Packard, HP-UX Support, Dutch Customer Response Center. Please, we have to use ZIP. It's fast, the most efficient around, supports non-MSDOS filenames and directory trees, the works. I have my gripes against ZOO, it's old, slow, as efficient as the oldest version of ARC (=not very good) and cumbersome to use. Rob -- Rob J. Nauta wsinrn@eutws1.win.tue.nl L. v Lancveltlaan 18 wsinrn@lso.win.tue.nl 5671 CN Nuenen, Holland, Europe Phone: 31-40-833777 My BBS (Fidelitel): 31-40-837549 .
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (02/16/90)
In article <493@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > Many people indicated that they wanted to be able to unpack the >archives on UNIX machines and read the docs before taking the time to >download to a DOS machine. That leaves arc and zoo. zoo was voted by the >readers last year and doesn't ask for money. Now that PKARC is (mostly) >gone zoo is a lot faster on the PC end, too. That's wrong. There was an UnZIP for PKZIP 1.0 posted to comp.sources.unix or comp.sources.misc some time ago and a full LHarc is available for Unix and OS/2 as well. This is a C version not identical to the original MS-DOS LHarc but creates exactly the same archives. They both compress *MUCH* better than arc and zoo. I would prefer PKZIP because it is about two times faster than the original MS-DOS LHarc at compression and about three times faster at unpacking. If you need the UNZIP or LHarc for Unix sources (written in C), I have them available. Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de
w8sdz@smoke.BRL.MIL (Keith Petersen) (02/18/90)
In article <1226@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes: >... a full LHarc is available for Unix and OS/2 as well. Where is the full LHarc for Unix? If you mean the one that was posted to comp.binaries.atari, it's expired on the news reader on my host. Keith -- Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1 Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
perand@nada.kth.se (Per Andersson) (02/19/90)
In article <1226@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes: >That's wrong. There was an UnZIP for PKZIP 1.0 posted to >comp.sources.unix or comp.sources.misc some time ago and a full LHarc is >available for Unix and OS/2 as well. Sorry, but Unix IS NOT ONE operating system. Is is at least a dozen different, and as it is now, ZOO is avaliable for almost every normal variant, whereas lharc is BSD only, and Unzip isn't publicated. Your Unix OS isn't the only in the world you know. I use D-NIX,SUNOS,BSD4.2,4.3 pyros 4.4,Microport 286 and Interactive 386ix. The only ones to compile without effort everywhere is ZOO and ARC. When these others is as portable I will shut up, but saying a program runs on 'UNIX' is kind of misinformation. Per -- --- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @nada.kth.se
heiby@falkor.UUCP (Ron Heiby) (02/19/90)
I have *never* had problems with zoo. Further, I *strongly* favor use of an archive format which can be manipulated on most common UNIX derived systems, including both BSD and System V. Almost all sites on Usenet are running some UNIX variant and it is truly convenient to be able to extract descriptive information or documentation (to be printed on the shared printer) before deciding to download. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Life is indeed an inexplicable sequence of imponderable surprises."
woolleyj@lafcol.UUCP (James Woolley) (02/20/90)
I agree with Brad Templeton--I've used his ABE/DABE program quite successfully with a correspondent whose EBCDIC machine would always trash uuencoded files. Give it a try! James Woolley, Lafayette College (rutgers!lafcol!woolleyj)
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (02/20/90)
In article <2973@draken.nada.kth.se> perand@nada.kth.se (Per Andersson) writes: >Sorry, but Unix IS NOT ONE operating system. Is is at least a dozen >different, and as it is now, ZOO is avaliable for almost every normal >variant, whereas lharc is BSD only, and Unzip isn't publicated. Your >Unix OS isn't the only in the world you know. I use D-NIX,SUNOS,BSD4.2,4.3 >Per Andersson >Royal Institute of Technology, Stockholm, Sweden Sorry, but Unix IS ONE operating system if you follow some portability rules. I compiled the C LHarc sources not only on Ultrix (=BSD) but also on OS/2 and even on MS-DOS ! The MS C compiler supports some kind of System V compatible library --> it should run on System V as well. It will run on any Unix system if you have Posix directory routines available because C-LHarc uses only open/read/write/close ... besides the directory routines. I think one should also be able to do some porting if a program does not run at the first attempt and not give up at the first "unresolved external" message. BTW, zoo is more non-portable than LHarc, because I had problems to compile it for MS-DOS using MS-C 5.1 instead of Turbo C (which I do not have). It seems to depend on such facts as signed/unsigned characters !!! (It still does not run although I DID some porting and I would appreciate any hints, because when it runs with MS-C 5.1 it will run under OS/2 too.) Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/21/90)
In article <2973@draken.nada.kth.se> perand@nada.kth.se (Per Andersson) writes: | Sorry, but Unix IS NOT ONE operating system. Is is at least a dozen | different, and as it is now, ZOO is avaliable for almost every normal | variant, whereas lharc is BSD only, and Unzip isn't publicated. There is a version of lharc which runs on SysV, but it fails if ints are not 16 bits. If you change all the int statements to short it runs on more machines. Unfortunately that doesn't help the user with a full size 64 bit word, some there's still a problem. There is an unzip for SysV, but it doesn't handle all 1.02 compression methods. Several people are sending me later versions of the programs which may have the problems fixed. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc "Getting old is bad, but it beats the hell out of the alternative" -anon
CMH117@psuvm.psu.edu (Charles Hannum) (02/21/90)
I suggest PKZip. While LHarc gets similar compression ratios (because it uses
a similar compression scheme), and, yes, it does fit in one program rather than
three (something I've often found annoying with PKZip), it also takes 2-3 times
as long to run, and doesn't get a fraction of the author support that PKZip
does.
Upon further thinking, I actually should suggest PAK 2.10. It gets similar
compression ratios to the two mentioned above, it's about as fast as PKZip
(sometimes a little slower; sometimes a little faster), it's supported, it's
fully customizable, it's used by the Shareware Distribution Network (something
any serious PC freak should be familiar with), and it even displays a little
bar graph of its progress [B-)].
I say PAK is the way to go! I'll even upload it to c.b.i.p. if anyone wants
it!
Virtually,
- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
(That's Charles to you!) "To life immortal!"
cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."CMH117@psuvm.psu.edu (Charles Hannum) (02/21/90)
In article <195@falkor.UUCP>, heiby@falkor.UUCP (Ron Heiby) says: > >I have *never* had problems with zoo. Further, I *strongly* favor >use of an archive format which can be manipulated on most common UNIX >derived systems, including both BSD and System V. Almost all sites >on Usenet are running some UNIX variant and it is truly convenient to >be able to extract descriptive information or documentation (to be >printed on the shared printer) before deciding to download. Wrong, pal. I'm personally running VM (as are a lot of other people I know) and I have at least 4 VAXen around running VMS that are also on InterNet. I don't have TAR (not the *nix-equivalent, anyway) or compress for VMS or VM; I don't have even an unZIP; I don't have LHarc; in fact, I don't have jack shit in the way of portable archivers for *either* system. Personally, I FTP the little bastards to a PC hard disk and do my dirty work there. (LIST is great for viewing documentation.) My suggestion: Everyone should get a PC on InterNet! [B-) JOKE B-) JOKE B-) JOKE B-) JOKE B-) JOKE] Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
CMH117@psuvm.psu.edu (Charles Hannum) (02/21/90)
In article <507@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) says: > >In article <2973@draken.nada.kth.se> perand@nada.kth.se (Per Andersson) writes: > >| Sorry, but Unix IS NOT ONE operating system. Is is at least a dozen >| different, and as it is now, ZOO is avaliable for almost every normal >| variant, whereas lharc is BSD only, and Unzip isn't publicated. > > There is a version of lharc which runs on SysV, but it fails if ints >are not 16 bits. If you change all the int statements to short it runs >on more machines. Unfortunately that doesn't help the user with a full >size 64 bit word, some there's still a problem. K&R2 [ANSI-standard] C specifies: "int" (neither far nor short) implicitly means "short int" "short int"s are 16 bits Your compiler is broken. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
tom@mims-iris.waterloo.edu (Tom Haapanen) (02/21/90)
> Wm E. Davidsen Jr. <davidsen@sixhub.UUCP> writes: > > There is a version of lharc which runs on SysV, but it fails if ints > >are not 16 bits. If you change all the int statements to short it runs > >on more machines. Charles Hannum <CMH117@psuvm.psu.edu> writes: > K&R2 [ANSI-standard] C specifies: > "int" (neither far nor short) implicitly means "short int" > "short int"s are 16 bits > Your compiler is broken. Charles, read the book before throwing accusations about. K&R, 2nd edition, page 196: "Plain int objects have the natural size suggested by the host machine architecture; the other sizes are provided to meet special needs. Longer integers provide at least as much storage as shorter ones, but the implementation may make plain integers equivalent to either short integers, or long integers." I think that's pretty unambiguous. As to compression in moderated groups, I would personally use zoo. Not because it has the best compression, not because it's a standard, not even because I can read archives portably, but because it would enable me to *create* the archives on Unix. A big plus, in my opinion... \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo "I don't even know what street Canada is on" -- Al Capone
mjh@cs.vu.nl (Maarten J Huisjes) (02/22/90)
In article <90052.022126CMH117@psuvm.psu.edu>, CMH117@psuvm.psu.edu (Charles Hannum) writes: > > In article <507@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) says: > > > >In article <2973@draken.nada.kth.se> perand@nada.kth.se (Per Andersson) writes: [stuff deleted] > > There is a version of lharc which runs on SysV, but it fails if ints > >are not 16 bits. If you change all the int statements to short it runs > >on more machines. Unfortunately that doesn't help the user with a full > >size 64 bit word, some there's still a problem. > > K&R2 [ANSI-standard] C specifies: > > "int" (neither far nor short) implicitly means "short int" > > "short int"s are 16 bits > > Your compiler is broken. Crap, Absolutly FALSE !!!!!!!!!!!!!!!!!! ANSI-standard C specifies: short <= int <= long Which leaves the 'int' compiler (machine) dependent. Int is always the natural size of a word of the machine. e.g Machine Wordsize Intsize 8086 16 16 VAX 32 32 SUN 32 32 -- Maarten Huisjes. mjh@cs.vu.nl (..!uunet!mcsun!botter!mjh)
doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) (02/22/90)
In article <90052.022126CMH117@psuvm.psu.edu> CMH117@psuvm.psu.edu (Charles Hannum) writes:
->K&R2 [ANSI-standard] C specifies:
->
-> "int" (neither far nor short) implicitly means "short int"
->
-> "short int"s are 16 bits
->
->Your compiler is broken.
->
->
->Virtually,
->- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
-> (That's Charles to you!) "To life immortal!"
-> cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
-> c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
Sorry but my copy of K&R2 says something different. I quote from page 36.
" There are only a few basic data types in C:
...
int an integer, typically reflecting the natural size
of integers on the host machine
...
The intent is that short and long should provide different lengths of
integers where practical; int will normally be the natural size for a
particular machine. short is often 16 bits, long 32 bits, and int
either 16 or 32 bits."
Your book is broken.
--
Doug O'Neal Distributed Systems Programmer
Homewood Academic Computing doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu
Johns Hopkins University mimsy!aplcen!jhunix!doug leonard@bucket.UUCP (Leonard Erickson) (02/27/90)
CMH117@psuvm.psu.edu (Charles Hannum) writes:
<In article <195@falkor.UUCP>, heiby@falkor.UUCP (Ron Heiby) says:
<>
<>I have *never* had problems with zoo. Further, I *strongly* favor
<>use of an archive format which can be manipulated on most common UNIX
<>derived systems, including both BSD and System V. Almost all sites
<>on Usenet are running some UNIX variant and it is truly convenient to
<>be able to extract descriptive information or documentation (to be
<>printed on the shared printer) before deciding to download.
<Wrong, pal. I'm personally running VM (as are a lot of other people I know)
<and I have at least 4 VAXen around running VMS that are also on InterNet.
<I don't have TAR (not the *nix-equivalent, anyway) or compress for VMS or VM;
<I don't have even an unZIP; I don't have LHarc; in fact, I don't have jack
<shit in the way of portable archivers for *either* system.
Zoo is available for VMS. And while you might have to mess with it a bit,
since it is distributed in *source* form, you can port it to VM if you've
got a C compiler... I'll cheerfully mail you an MS-DOS flooppy with the
source to Zoo on it. (this is *not* an open offer, lurkers!)
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short