HDTenEightyP/NetNews huggingface dataset:
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Date: 11 Jan 93 19:15:16 GMT
Organization: Academic Computer Centre Utrecht

I received more information from PKWARE. It seems the bugs with DPMI,
XMS, EMS, multivolume support and volume labels are all acknowledged
and will be fixed real soon. If I interpreted the information
correctly many bugs have already been fixed by PKWARE.

Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   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.
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: WUARCHIVE CLAIMS PKZIP/UNZIP 2.04c IS A HACK
Keywords: pkzip pkunzip hack
Date: 6 Jan 93 21:21:05 GMT
Organization: University of Vaasa, Finland

In article <815@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>Can someone post a UNIX "sum pkz204c.exe" result so we can 
>tell if we've got the good one or the bad one?  Or better 
>yet let us know where there is an ftp site w/ a guaranteed
>uninfected version??

This is what we have:

garbo> unzip50 -vU pkz204c.exe
 Length  Method   Size  Ratio   Date    Time   CRC-32     Name
 ------  ------   ----  -----   ----    ----   ------     ----
    537  Deflate    306  43%  12-28-92  02:04  a15cfed3   README.DOC
    573  Deflate    332  42%  12-28-92  02:04  d941b3b8   SHAREWAR.DOC
   2430  Deflate   1140  53%  12-28-92  02:04  df651570   WHATSNEW.204
   3707  Deflate   1499  60%  12-28-92  02:04  83f4432b   LICENSE.DOC
   3456  Deflate   1585  54%  12-28-92  02:04  376abf58   ORDER.DOC
  13700  Deflate   4629  66%  12-28-92  02:04  9e8ac0b1   ADDENDUM.DOC
 191376  Deflate  55173  71%  12-28-92  02:04  634b917d   MANUAL.DOC
   2299  Deflate    904  61%  12-28-92  02:04  d6b73e85   AUTHVERI.FRM
  41462  Deflate  41007   1%  12-28-92  02:04  b29643f6   PKZIP.EXE
  28806  Deflate  28453   1%  12-28-92  02:04  9b841eb4   PKUNZIP.EXE
   7672  Deflate   7574   1%  12-28-92  02:04  eae15d4f   PKZIPFIX.EXE
  27069  Deflate  26220   3%  12-28-92  02:04  3d7640ca   ZIP2EXE.EXE
   2750  Deflate   2492   9%  12-28-92  02:04  bc15451f   PKUNZJR.COM
    591  Deflate    359  39%  12-28-92  02:04  d00756d3   OMBUDSMN.ASP
 ------          ------  ---                              -------
 326428          171673  47%                              14

..................................................................
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
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: ARJ 2.30 minor bug
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Distribution: comp
Date:  7 Jan 93 17:38:59 GMT

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

> | There seems to be a minor problem with ARJ 2.30, if you include the same fil
> | twice in the file list (e.g. ARJ a test dummy dummy or ARJ a test d* dummy),
> | ARJ gives an error of not able to find the file after it has compressed it!

>   Have you tried this with 2.39?

Yup, the problem exists there too...

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
From: susanm@an.hp.com (Susan Margulies)
Newsgroups: comp.compression
Subject: Image Correlation Question
Date: 5 Jan 1993 15:11:44 GMT
Organization: Hewlett Packard Santa Clara Site
Reply-To: susanm@hp-and.an.hp.com
NNTP-Posting-Host: hpanvi.an.hp.com
X-Newsreader: Tin 1.1.3 PL5

[ Article crossposted from sci.image.processing ]
[ Author was Susan Margulies ]
[ Posted on 5 Jan 1993 09:09:06 -0600 ]

Thanks for the responses to my image correlation question which convinced 
me that the NMR article defines the correlation coefficient under the 
assumption of an image with zero mean even though they don't specify it.  
However, such an assumption doesn't hold for the ultrasound images I am 
working with.  

My problem is that when I take a 3rd order linear predictive equation:

U'_i,j = A1 * U_i-1,j + A2 * U_i,j-1 + A3 * U_i-1,j-1

and then minimize the expected value of the square prediction error:

E[(U_i,j - U'_i,j)^2]

I get equations for A1, A2, and A3 which have factors in them of the
form used in the NMR article to define rho(x,y), namely:

E(U_i,j U_i-x,j-y)
------------------
     E(U_i,j^2)

My dilemma then reduces to:

Can I safely use these A1, A2, and A3 with an image with a non-zero
mean???  

If the answer is no, then I understand the discrepancy 
between the two definitions of rho(x,y).  However, if the answer is
yes, which I don't see how it *couldn't* be given that all I am
doing is computing some image statistics, a linear predictor, and
coefficients to minimize the MSE of said predictor, then there is 
a definite discrepancy in the two definitions.

So am I missing something inherent in either my 3rd order linear
prediction equation or the process of minimizing the mean square
prediction error which constrains me to using images of zero mean?

Another thing which I have realized - when I compute rho(x,y) using
the NMR definition, I get numbers greater than 1 which implies gain
exists in the prediction.  When I compute rho(x,y) using the
definition which subtracts the square of the first moment from
numerator and denominator, I get numbers close to but never
exceeding 1.  To me, it is logical that a correlation coefficient
would lie between 0 and 1.  Is that an incorrect conclusion for me
to draw?

Thanks for any help you can give me!

Susan
--
Susan E. Margulies       
HP Imaging Systems       
508-681-2153 (work)      
susanm@hp-and.an.hp.com 


--
Susan E. Margulies       |  "Isn't revenge enough?"
HP Imaging Systems       |     -- Erica Kane  
susanm@hp-and.an.hp.com  |  

Xref: sparky comp.compression:4369 news.answers:4978
From: kaukasoi@butler.cc.tut.fi (Kaukasoina Petri)
Newsgroups: comp.compression
Subject: pkzip 2.04c / unzip v5.0 compatibility
Date: 6 Jan 1993 12:42:17 +0200
Organization: Tampere University of Technology, Computing Centre
Distribution: world
NNTP-Posting-Host: butler.cc.tut.fi

Try this:

pkzip -es test pkzip.exe
unzip test

Unzip gives an error message 'BAD CRC 00000000 should be 629643f6'.
The same thing if you try to unzip PKZ204C.EXE. 

And the file ds.bat from dsz1106.zip (zmodem package):

pkzip -ex test2 ds.bat
unzip test2

Similar message: 'BAD CRC 00000000 should be 0a33cf32'.

pkunzip 2.04c gets the CRCs ok.

-Petri
Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: *** WARNING *** PKZIP 2.04c is infected by a virus.
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  7 Jan 93 17:41:08 GMT

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

>   Actually it seems that WUARCHIVE used an old virus checker which gave
> a false positive and then went ballistic. This scares me for several
> reasons, not only did they get a lot of people to trash perfectly good
> versions of PKZIP (if there is such a thing) but they are checking with
> old software which may miss current virus infections.

Seems that you have not followed the events closely. It is not the
moderator of WUARCHIVE to blame. It was somebody who has downloaded
the file from there and has used an old version of NAV. This person
spreaded the rumor, not the moderator of WUARCHIVE. The only problem
with WUARCHIVE is that it provides a directory that is both world
readable and world writable - this is certain to cause problems one
day...

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 / unzip v5.0 compatibility
Keywords: passwords problem.
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  8 Jan 93 16:34:43 GMT

brianb@julian.uwo.ca (Brian Borowski) writes:

> If I zip up a file with pkzip 204c with password encryption,
> I find that unzip 5.0 cannot unzip such a file.  It asks for
> the password, but will not undo the file.

Hm, funny, I tired this and it works OK... What kind of file did you
test it with?

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
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
Date: 9 Jan 1993 00:10:56 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu
Keywords: passwords problem.


Paul Kocher thinks:

>> instead of having two bytes of the crc32 at the end of the encryption
>> header, the final byte of this header is a zero.  (The others are

Actually, there was a bug in Unzip 5.0's decryption that is fixed in
our current beta version.  That beta version appears to have no problem
decrypting stuff from PKZIP 2.04c.  However, we check for the high
byte of the crc as the 12th byte of the encryption header--not a zero.

Can you recheck your assertion that the 12th byte is a zero?  I don't
see how this can agree with our test results.

In any case, a new patched unzip will be released next week which
includes the patches I posted to decompress stuff from pkzip 2.04c,
as well as the decryption fix that's been there a while, and some
other fixes.

Mark Adler
madler@cco.caltech.edu
Xref: sparky comp.compression:4332 comp.ai.philosophy:7208
From: marcelk@blade.stack.urc.tue.nl (Marcel van Kervinck)
Newsgroups: comp.compression,comp.ai.philosophy
Subject: Re: God's Compression (was: Re: Compressing decimal expansion of pi...)
Date: 5 Jan 93 14:32:49 GMT
Followup-To: comp.compression
Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands.
X-Newsreader: TIN [version 1.1 PL6]

Ken Easlon (ken@iat.holonet.net) wrote:
: 
: In article <1hvhqhINNkg8@uwm.edu> ,
: markh@csd4.csd.uwm.edu (Mark) writes:
: 
: >In this way, an algorithm is proven to exist that will compress everything
: >that has or will ever exist to 256 bits. 
: 
: Granted you can probably name each actual sentence, paragraph, usenet
: article, etc with it's own 32 byte word, but naming it doesn't explain the
: meaning.  You simply use the name to call up a mental program, which puts
: the named data into some kind of perspective that makes it useful in
: carrying out the functions of life.

The meaning of the 256 bit word is contained in the compression function.
You only need to know that function, but that is always the case when
uncompressing compressed data. The only sad thing is that the compression
function is very likely to be very complex, probably consisting of a large
database. Not very useful, I'm afraid.

    Marcel
--
Marcel van Kervinck
marcelk@stack.urc.tue.nl                                 
Newsgroups: comp.compression
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: PKZip 2.04c quick impressions
Organization: University of Maryland, College Park
Date: Wed, 6 Jan 1993 04:31:49 GMT

In article <81505@ncratl.AtlantaGA.NCR.COM> pgleason@ncratl.AtlantaGA.NCR.COM (Pat Gleason) writes:
>PKWARE has already confirmed one bug with the new PKZIP 2.04c.
>It will not store a volume label. Just FYI.


	I suppose they'll blame this one on funny disk controller
	bugs that ONLY pkware sees.

-- 
      Blaming "society" for your problems is like blaming clouds for rain.
 ---  boycott == coercion == censorship == closed mindedness == cowardice  ---
	      "Psalms 23:1  The LORD is my shepherd; I shall not want."  
		Shepherds are for sheep.   -----      Pain teaches.
Newsgroups: comp.compression
From: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: What algorithm should I use?
Organization: JHU/Applied Physics Laboratory
Date: Wed, 6 Jan 1993 17:47:45 GMT

I have an application with several thousand short (40-200 byte) messages.
I'd like to keep them all in memory and would like suggestions as to
what compression technique would be best.  The main priority is space
with speed of encode/decode secondary.

I have part 1 of the FAQ and didn't see anything like this in there;
sorry if I missed it.

-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
Newsgroups: comp.compression
From: vporguen@unlinfo.unl.edu (victor porguen)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04c quick impressions
Date: 7 Jan 1993 04:52:38 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: unlinfo.unl.edu

ts@uwasa.fi (Timo Salmi) writes:

>Well, I did some light testing with PKZIP 2.04C and soon run into
>the following problem.  My PKZIP.CFG file (in the current directory
>as the manua says) has the following line

>COMPRESS=maximal

>It had no effect.  Compression is normal despite this.  What gives?


Could it be that you've discovered yet another bug in the new PKZIP 
2.04c? So far, I have seen reports that it cannot recognize Volume 
labels when backing up to a series of floppies and that the 
passwording/encryption is a bummer! Now this.

Newsgroups: comp.compression
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: PKZip 2.04c quick impressions
Date: 11 Jan 93 16:58:27 GMT
Organization: Academic Computer Centre Utrecht

In <834@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:

>In article <3559@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>:Actually PKZIP does the opposite. If a sector is marked BAD in the
>:FAT its quick format removes the mark making it good again. A very
>:bad thing for file integrity.

>AAAAAAAAAAAACCCCCCCCCKCKKKKKKKKK!!!!!!!!!!

>Tell me you are joking!!!  Please!?!????!?!?!???????

Unfortunately I was NOT joking here. This problem is likely to be fixed in
the next release of PKZIP BTW.

Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   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: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: Another PKZIP 2.04C bug...
Organization: Qualcomm, Inc., San Diego, CA
Date: Mon, 11 Jan 1993 04:42:24 GMT

NETOPRWA@ncsuvm.cc.ncsu.edu (Wayne Aiken) writes:
>Here's another bug I found while re-zipping files on my BBS:
>  Some files created and unpackable by version 1.10 cannot be PKUNZIPped..
>  instead, the message "Enter Disk 2 of archive", or some similar message
>  from the multi-volume handler is displayed.

Were you running it from a batch file or other program (sounds like
it...)?  This is something we've noted: random CRC errors and "Enter
Disk #x of archive" messages.  If you then try to unzip the same file
right from the command line, it works.  This might help you track it.
-- 
Government expands to absorb all available revenue and then some.  -- Wiker
Newsgroups: comp.compression
From: hess@swt7.informatik.uni-hamburg.de (Hauke Hess)
Subject: Source for Lempel-Ziv
Summary: where could I find
Keywords: lempel
Organization: University of Hamburg, FRG
Distribution: comp
Date:  7 Jan 93 09:13:25 GMT

Hi,

I would like to save some space by storing long data structures
temporary in a compressed form. Though I don`t want to loose much
time in compressing and decompressing them, I look for a
lempel-ziv coder/decoder source, that will make it as simple as
possible to store and retrive huge arrays. I imagine the
following operations:

storeID = store(char *ptr, size);

will store the array pointed to by ptr of size "size" and return the
ID.

size = retrieve(char *ptr, storeID);

will decode the through storeID referenced array into ptr and
return the size.

Hauke

Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 12 Jan 93 15:46:14 GMT

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

> causes. The main problem, according to PKWARE, is a bug in Quarterdecks
> QDPMI implementation. 

Ah, really? They seem very good in finding bugs in other people's
products; too bad that they are unable to do it for their own. I
didn't know that Quarterdeck has written MS-Windows, BTW...

> I have no information about when a new version will be released and

Let's hope it will happen before Christmas...

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: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: ARJ 2.30 minor bug
Organization: Qualcomm, Inc., San Diego, CA
Distribution: comp
Date: Fri, 8 Jan 1993 18:49:35 GMT

robjung@world.std.com (Robert K Jung) writes:
>After due consideration of this problem, it seems acceptable not to call
>situations such as "ARJ a test dummy.bat dummy.bat" an error.  Since LHA
>does not consider this wrong and since ARJ is styled after LHA, ARJ at the
>next release will NO LONGER consider this an error.

After pontificating like that on the exclusion list, I've gotta
know... was I right? :)

P.S. the new PKZip is making the solidity of ARJ look more and more
impressive. 
-- 
Dear Necrophiliacs:
   We love you.
        -- The Grateful Dead
Newsgroups: comp.compression
From: shephard@fraser.sfu.ca (Gordon Shephard)
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 12 Jan 1993 00:08:15 GMT

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. 

>The new version is currently tested internally by PKWARE employees. 

>I have no information about when a new version will be released and
>if all reported bugs will be fixed. I think it is very likely however
>the major problems currently present will be cured.

I have two words which PKWARE might consider:
  
          Beta Testing
-- 
| Gordon Harry Shephard         | Distributed Computing Support Group  |
| Academic Computing Services   | Phone: (604)291-3930   (604)464-4991 |
| Simon Fraser University       |                                      |
| Burnaby, BC, Canada. V5A 1S6  | shephard@sfu.ca                      | 
|                                                                      |
| Disclaimer: In No Way am I speaking for my Employers or Simon Fraser |
| University.                                                          |
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Re: Do PKLITE'd executables work on *all* machines?
Date: 9 Jan 93 14:02:47 GMT
Organization: Academic Computer Centre Utrecht

In <1ilapgINNnim@life.ai.mit.edu> dmb@case.ai.mit.edu (David Baggett) writes:

>Is it safe to distribute software that's been PKLITE'd?  Basically, I
>worry that my software might not run on some configuration if I PKLITE
>it.  My program has data tacked onto the end of it, which the program
>locates at run time.  It seems to work fine on my 486 machine, but can
>I trust it?

PKLite makes some mistakes in initializing processor registers when
starting a program. This can cause problems for some executables. This
problem is however not machine but program connected. Since the
pklite extractor does not use many fancy stuff (like e.g. PKZIP 2.04c)
I don't expect system related problems. As soon as PKWARE
adds DPMI or whatever to PKLite this might change.

>Dave Baggett

Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   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