HDTenEightyP/NetNews huggingface dataset:
From: alanf@cs.monash.edu.au (Alan Grant Finlay)
Subject: CCITT specs for G3/4 encoding (FAQ needs update?)
Organization: Computer Science, Monash University, Australia
Date: Wed, 13 Jan 1993 02:04:33 GMT

===================================================================
I am looking at an old compression.FAQ so I apologise if this has  |
been fixed recently.						   |
===================================================================

Compresion.FAQ Subject [12] says:

>CCITT specs are available by anonymous ftp (see above answer on V.42bis).
>The T.4 spec is in ccitt/1988/ascii/7_3_01.txt.Z, the T.6 spec
>is in 7_3_02.txt.Z.

From previous section:
 
>The CCITT standards documents are available by ftp on ftp.uu.net
>in directory /doc/standards/ccitt. Also on src.doc.ic.ac.uk,
>in directory doc/ccitt-standards/ccitt. The v42bis standard is in
>/doc/ccitt-standards/ccitt/1992/v/v42bis.asc.Z.

The directory structure in [src.doc.ic.ac.uk] has been changed and I found
the docs in /computing/ccitt/standards/ccitt/1988/ascii.  On ftp.uu.net
the /doc/standards/ccitt directory is empty (perhaps things are being
moved around at present).

More important still, the documents (both ascii and postscript versions) are
quite incomplete with lots of missing figures and messed up tables.  The
following notice is in /computing/ccitt/standards/ccitt/1988 on
[src.doc.ic.ac.uk]:

>Volume 8 has been added in the TROFF subdirectory.  Be aware that the
>code needs fixing -- tables and equations as currently coded in TROFF
>will not successfully executed.  The half-finished TROFF is being
>posted in light of the decision of the ITU to kill this server at the
>end of 1991.  We figured that some data is better than no data.

At least the troff source should be readable I suppose.
The postcript and ascii subdirectories both seem to have been derived from
the troff sources.  The ascii files contain printer control characters which
only makes things worse.

Does anyone know if there are any better versions of these documents available
by ftp?  Or better still, a good turorial (and detailed) explanation of the
standards?

,-------Alan Finlay, email: alanf@bruce.cs.monash.edu.au, phone: (03)565-5225.
|	Victorian Centre for Image Processing and Graphics,
|	Monash University, CLAYTON 3168, Australia.

Xref: sparky comp.compression:4338 comp.os.msdos.apps:6004
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression,comp.os.msdos.apps
Subject: *** WARNING *** PKZIP 2.04c is infected by a virus.
Date: 5 Jan 93 16:37:20 GMT
Followup-To: comp.compression
Organization: Academic Computer Centre Utrecht

According to warning messages on wuarchive.wustl.edu the PKZIP 2.04c
is a virus infected version. The virus detected is the "Maltese Amoeba"
one.

Unclear is if there is a real PKZIP 2.0x which has been infected 10
seconds after release or that there is just a cracked new 1.93a version.
PKWARE has promised to release a new version 5 jan so there might also be
a real one. 

Clearly some smart cracker have used their chance. It might take ages before
everyone has a reliable PKZIP 2.0x. We can just hope the authenticy
verification in PKZIP 2.0x will be strong enough to remove this
problem in the future.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
garbo.uwasa.fi /pc/programming. Make files for Borland C are included. 
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: Another PKZIP 2.04C bug... WITH bug test file
Organization: University of Vaasa, Finland
Date: Wed, 13 Jan 1993 05:27:14 GMT

In article <3584@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
[about including binaries in a posting in a discussion newsgroup]
>It doesn't happen often, but this time I have to disagree with you. Of
>course posting binaries is not a very smart idea but,
>   - the message is VERY small (size is major problem with most binary files)

Not arguing, but discussing, for once we differ Nico.  From
experience on the UseNet news we should know that even small
binaries in discussion newsgroups induce others.  This has happened
at times way back then, at worst leading to some site managers
deleting a newgroup at their site.  Besides a discussion newsgroup
is a discussion newsgroup. 

>   - this way the problem can be seen by PKWARE before they release
>     a new version (PKWARE is on the internet as well)

I don't buy this.  We know quite well that they can be reached by
email with an address that is readily available for comp.compression
readers.  For example both you and I have given them bug reports,
and have got their attention and feedback.

>>I'll be happy to send you our upload instructions if you email me
>>for them. Or if you wish to FTP the instructions directly, they are
>>available as garbo.uwasa.fi:/pc/UPLOAD.INF.
>
>For some purposes the queue at garbo is too large.

Touche!  

>Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   AA   III  PPP

   All the best, Timo

..................................................................
Prof. Timo Salmi      Co-moderator of comp.archives.msdos.announce
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
From: wscheu@dcc.uchile.cl (Wst)
Subject: Looking for Haruyasu Yoshizaki Yoshi
Originator: wscheu@dcc.uchile.cl
Date: Tue, 05 Jan 1993 22:35:21 GMT
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion

We are interested in reaching Mr. Haruyasu Yoshisaki Yoshi, the 
creator of the LHA compressor.  The reason we want to reach him
is to find out if there is any posibility of obtaining the licence
(i.e., *.obj or *.lib for MS-DOS) for his compressor to use it in
a program we're creating.

If anyone knows how or where we can reach him, please send an
e-mail to us.

Thanks.
                         Walter Scheu
						 wscheu@dcc.uchile.cl
Newsgroups: comp.compression
Subject: Re: Pkzip v2.04c availability
From: skriefal@eeyore.stcloud.msus.edu (Scott Kriefall)
Date: 6 Jan 93 08:43:36 -0600
Distribution: world
Organization: St. Cloud State Univ., MN

PKZip 2.04c is available at wuarchive in the /pub/MSDOS_UPLOADS
directory.

Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZ204C.EXE *NOT* INFECTED, or ...???
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  6 Jan 93 16:02:33 GMT

weegink@ictser.UUCP (Han Weegink) writes:

> Isn't it true, that all one can prove is ***presence*** of viri,
> not ***absence*** ?

It is so when you are using a known-virus scanner. I analyzed the
files manually with a debugger.

> The fact that the virusscanners didn't all identify a virus
> merely proves that the virus they are looking for is not
> present. But what about new viri ???

I am in the field since more than four years and I -am- able to
recognize a virus (even if it is new) when I see one... Sometimes it
might take me some time to decide whether a suspiciously-looking code
is a virus or not. And, as I wrote even in my original message, I did
not limit myself to the usage of scanners, like most of you seem to
have done. I analyzed the executables manually. I GUARANTEE THAT THEY
ARE NOT INFECTED! In the worst case they could be trojan horses made
to drop viruses - and this could be made only by the person who has
written the program - a program that actually works and -is- an
archiver and -is- a better archiver than the currently known version
1.93. Any common sense should tell you that the probability that
somebody spends so much time just to produce a virus dropper that will
be discovered almost at once when it first drops the virus is
effectively zero. Note that I am speaking about the probability of the
files being trojan horses; the probability of them being infected IS
ZERO, BECAUSE THEY ARE NOT.

> BTW, I used to use PKZIP a lot until I found out that it sometimes
> has serious problems unzipping archives (making me loose some
> valuable work in the proces :-(

I am not saying that the program is bug-free; just that it is NOT
INFECTED.

> Now I use ARJ230, which has worked without a flaw, thisfar.

Same with me, BTW, but this is irrelevant to the discussion.

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZIP 2.04c is shipping...
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  6 Jan 93 16:13:40 GMT

nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

> >Seems about the right time for the virus writers to release yet
> >another 1.93 hack and to call it "2.04c"... :-) Just kidding...

> Since the PKZIP 2.04c is infected with the Maltese Amoeba virus someone
> might have actually done this ..... :-(

IT IS NOT INFECTED WITH ANYTHING!

Instead, someone seems to have done something else that is much easier
and has about the same effectiveness - spread a false rumor...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.compression
From: roe2@ellis.uchicago.edu (Cave Newt)
Subject: Re: PKZip 2.04c quick impressions
Reply-To: roe2@midway.uchicago.edu
Organization: University of Chicago
Date: Tue, 5 Jan 1993 17:27:29 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Vladimirov Bontchev) writes:

>You should compare it with PKZIP 1.93 - theoretically it should have
>the same compression ratio, unless they have invented something really
>new, which I strongly doubt...

There was room for tweaking within the current format.  Info-ZIP's
Zip gets slightly better compression than PKZIP 1.93a on some files.

>I doubt that the Info-ZIP product can be made to use a
>more intelligent way to handle multi-volume archives if it wants to
>stay compatible... Unless they decide to implement both ways - the
>silly one in the new PKZIP and a more intelligent and straightforward
>one...

Hmmmm...maybe.  It would certainly be easy enough to add a same-disk
option to Zip which would create ARCHIVE.001, ARCHIVE.002, etc.  We
could even make a program to copy the archives to floppies, rename
them and create the appropriate PKDISK#.xxx file (possibly as a batch/
command file, but I don't recall how to create an empty file without
"touch").

We'll have to discuss this amongst ourselves.  Brilliant ideas/suggestions
may be sent to info-zip@wkuvx1.bitnet... :-)

>> It did handle it nicely when I threw a floppy with a bad sector at it.
>> It just stopped packing at that point and asked for the next disk, and
>> continued from there.

>Hmmm, a better solution would be to just skip to the end of the
>compressed -image- of the file that contains the bad sector and to
>continue with the next file from the same disk...

He was talking about packing, not unpacking.  Getting rid of the bad
disk is the proper response when writing the archive.

Greg Roelofs
Info-ZIP guy
From: tchnd-au@garnet.berkeley.edu (Yuval Oren)
Newsgroups: comp.compression
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Date: 12 Jan 1993 01:46:04 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: garnet.berkeley.edu

In article <3577@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>PKWARE informed me about a new version of PKZIP 2.04c which should
>fix many of the crashes and corruped environments the program currently
>causes. The main problem, according to PKWARE, is a bug in Quarterdecks
>QDPMI implementation. 
>

I have upgraded to to QDPMI 1.01 and have had no problems since.

Yuval
-- 
________________________________________________________________________
|Yuval Oren						               |
|yuval@ocf.berkeley.edu     				               |
| "One spoiled green bird is worth two cooks in the other grass broth."|
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: DID YOU KNOW DIET144.ZIP ?
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  8 Jan 93 22:18:48 GMT

kko@fraser.sfu.ca (Samuel Ko) writes:

> I don't quite like diet ... 1) executables compressed with diet cause
> some false alarms with some anti-virus programs and 2) diet doesn't 

That's a reason to dislike those anti-virus programs, not Diet... :-)

> work well on a hard disk that was doubled with Stacker and other 
> disk-doublers ...

If you are using a compressed volume, you should not put compressed
files on it (because they do not compress well). This holds not only
for Diet, but for any other executable compressor and even for
archives, .GIF files, etc.

> Use pklite (pklte115.zip) instead for executables
> (or pkzip or data) ....

Well, Diet has more features than PKLite and sometimes compresses
better, but the compressed files decompress themselves much slowlier,
especially when run from floppies...

Just my $0.02 worth...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Xref: sparky comp.compression:4391 sci.image.processing:1499
From: estes@ece.ucdavis.edu (Robert Estes)
Newsgroups: comp.compression,sci.image.processing
Subject: Conversion od MPEG 2 standard test suite...
Date: 6 Jan 93 20:59:20 GMT
Followup-To: comp.compression
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Originator: estes@fir.eecs.ucdavis.edu

Hi,

We've just recieved the MPEG 2 suite of test sequences and would like to
convert them to RGB, or something similar, for processing.  Does anyone know
the exact format specifications.  The person we obtained them from couldn't
help us.  

Thanks in advance,
-Robert estes@eecs.ucdavis.edu
-- 
Robert estes@eecs.ucdavis.edu

Center for Image Processing and Integrated Computing (CIPIC)
University of California, Davis
Newsgroups: comp.compression,comp.archives.msdos.d
From: storner@diku.dk (Henrik St|rner)
Newsgroups: comp.compression
Subject: Re: A note on using PKUNZIP 2.04c with 4DOS and Windows 3.1
Date: 7 Jan 93 13:39:11 GMT
Distribution: inet
Organization: Department of Computer Science, U of Copenhagen

momo@masg9.epfl.ch (Yves Mottet) writes:

>Maybe it can help you:

>In article <3546@accucx.cc.ruu.nl> (comp.compression), nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>> 
>> According to warning messages on wuarchive.wustl.edu the PKZIP 2.04c
>> is a virus infected version. The virus detected is the "Maltese Amoeba"
>> one.

This has been proven to be afalse alarm. The uploaded file does *not*
contain a virus; it is OK.

-- 
Henrik Storner (storner@olivetti.dk / storner@diku.dk)
Tech. Support
Olivetti Denmark
Newsgroups: comp.compression
From: schultz@halley.est.3m.com (John C. Schultz)
Subject: Re: compression hardware?
In-reply-to: schultz@halley.est.3m.com's message of Thu, 7 Jan 93 03:25:14 GMT
Organization: 3M Company, 3M Center, Minnesota, USA
Distribution: comp
Date: Fri, 8 Jan 93 13:50:33 GMT

Whoops, found part 3 of FAQ - sorry.
--
   John C. Schultz   +1 (612) 733-4047   schultz@halley.serc.3m.com
   How to include the taste of Glendronach in a multi-media system?
From: drinnen@deakin.edu.au (Philip Shead)
Newsgroups: comp.compression
Subject: Re : PKZIP 2.04c vs. ARJ 2.39B (and LHA/ZOO) Compression Results ** UPDATED
Date: 10 Jan 1993 20:11:39 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

Subject: Re: PKZIP 2.04c vs. ARJ 2.39b (and LHA/ZOO) Compression Results ** UPDATED

In article <726694622rommel.root@jonas.gold.sub.org> rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:
>In article <1993Jan9.200422.13011@ncsu.edu> mrmarcel@eos.ncsu.edu (Mike Marcelais) writes:
>>In article <726586156rommel.root@jonas.gold.sub.org>, rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:
[deleted]
>>sugrfx.acs.syr.edu:/pub/incoming/mine/arj/unarj230.tar.Z
>
>How do you *pack* with an unpacker? :-) :-)
>
>Kai Uwe Rommel
>
You don't instead you get either
pd1:<msdos.Arc-Lbr>lha213.exe 44416

or if you don't have a dos box

96999 Sep 23 20:00 oak.oakland.edu:/pub/misc/unix/lha101u.tar-z

and I know there are Macintosh and Amiga versions because I have some somewhere.
Guess what it does it all in 1 file and the dos version is 34283 bytes compared
with 70268 for combined pkzip.exe and pkunzip.exe. 
 It is only slightly less in compression than arj runs faster (Dos) and has
not given me a single problem either on my dos box or on the sun's I work on.
Admittedly it is slightly slower than the Info-zip on the unix machine
but when you type lha a file *.c & it's very quick.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That was drinnen@sol.cc.deakin.OZ.AU and if you don't agree, well I don't care.
                               ^^^^^ Soon to be Deakin.Edu.AU
Or alternately try ps@martyn.apana.org.au.
From: paraska@oasys.dt.navy.mil (Pete Paraska)
Newsgroups: comp.compression
Subject: PKZIP 2.04C: -v "view" format changed
Date: 6 Jan 93 18:34:43 GMT
Organization: David Taylor Model Basin

I noticed that a DOS shell program I use (Qfiler 3.2a) uses PKZIP to view .
ZIP files.  The program uses the -v option of PKZIP.EXE to get the filename 
information into the window that shows the .ZIP file contents.

PKWARE added a fourth field to the ATTR record of their -v "view".  This 
causes the first character of the file name to be in column 63 instead of 
column 62, as it previously has been.  For this reason, Qfiler thinks all 
files in a zip file have a blank for the first character of the files.  
Subsequently, you can not take any action on these files (list, delete or 
extract them) from within Qfiler.  I guess the writer of Qfiler will come 
out with a fix, but I doubt this is the only shell that uses the "Name" 
field of the -v option of PKZIP.  Oh well, that's the price of progress.
|////////////////////////////////////////////////|
| Pete Paraska       (paraska@oasys.dt.navy.mil) |
| David Taylor Model Basin, CARDEROCKDIV         |
|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|
From: ujacampbe@memstvx1.memst.edu (James Campbell)
Newsgroups: comp.compression
Subject: DOWNRe: *** IMPORTANT *** new version of PKZIP is on its way.
Date: 12 Jan 93 11:37:58 -0600
Organization: MSU Cryptologic Group

In article <7457@sersun1.essex.ac.uk>, mossap@solb1.essex.ac.uk (Moss A D) writes:
> Does anyone have a copy of the proof that any string can be compressed
> down to 256 bits? Sounds like a crock to me, but I'd be interested in 
> seeing it.
> 
> Thanks!
> 
> Regards,
>       Adam Moss
>             <mossap@essex.ac.uk> 

(I'm assuming you're referring to lossless compression, since a lossy
algorithm could compress a string down to any arbitrary length.)

Intuitively, this is not possible.  Consider that there are exactly 2^257
strings of 256 bits or less (including the null string).  Therefore, only
2^257 distinct strings could be thus compressed, at best.  The numbers
from 0 to 2^257, for example, could not all be represented into 256 bits
or less.  One would have to be left out, or its compressed version would 
be undifferentiable from that of at least one of the other numbers.

I suppose one could argue that all the strings ever used by mankind don't
add up to 2^256 strings, so a limited algorithm should be theoretically
possible.  May be, but the only way I could envision such an algorithm
would be in the form of a lookup table containing _every_ string that was
ever used.  For those of us with finite disk space, this isn't a viable
option :-).  Besides, such a solution would be indexing, _not_ compression.

-- 
  ===========================================================================
  James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu
  ---------------------------------------------------------------------------
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: Virus Infection -- pkz204c.zip
Organization: University of Vaasa, Finland
Date: Thu, 7 Jan 1993 07:24:44 GMT

-Subject: Re: your mail
-To: klau@neptune.calstatela.edu (K Lau)
-Date: Thu, 7 Jan 1993 08:39:19 +0200 (EET)
-From: ts

> >In article <ts9301061125.14868@chyde.uwasa.fi> ts@chyde.uwasa.fi (Timo Salmi) writes:
> >> 188818 Dec 28 02:04 garbo.uwasa.fi:/pc/arcers/pkz204c.exe

> I have just got a copy of pkz204c.exe from garbo. When I tried to
> run pkunzip, my Norton Anti-Virus 2.0 tsr virus detection program
> reported pkunzip.exe contains "Maltese Amoeba" virus. I tried to
> run NAV, the program reported both pkunzip.exe & pkzipfix.exe
> both contains "Maltese Amoeba" virus. I don't know if any other
> people have found the same problem. Thanks for you concern.

Yes, such an alarm has been reported as a false alarm. 

Incidentally, pklited executables, which cannot be unlited are a
virus checking pain in the collective neck of the MsDos FTP archive
site moderators.  Under normal circumstances we are very reluctant
to accept such executables at all to the archives!  This is
something that shareware authors might wish to bear in mind. 

   All the best, Timo

..................................................................
Prof. Timo Salmi      Co-moderator of comp.archives.msdos.announce
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
Newsgroups: comp.compression,sci.crypt