HDTenEightyP/NetNews huggingface dataset:
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.compression
Subject: Re: arj 2.4
Date: 16 Apr 92 02:37:32 GMT
Organization: University of Vaasa, Finland

In article <usgjej.703346350@gsusgi1.gsu.edu> usgjej@gsusgi2.gsu.edu (Jeffrey Johnson) writes:
>anyone know when arj 2.4 is expected....thanks

Have you tried the author.  His email address can be found on the
list of reachable PD & SW utility authors

6983 Apr 13 23:53 garbo.uwasa.fi:/pc/pd2/author03.zip

"If you do not know how to go about getting this material users are
welcome to email me for the prerecorded garbo.uwasa.fi instructions
(long, circa 29Kb).  North American users are referred to the garbo
mirror on wuarchive.wustl.edu.  Oceanian users are referred to the
archie.au mirror.  The mirrors may lag occasionally, or might not
have all the files."

...................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
Newsgroups: comp.compression
From: alexo+@cs.cmu.edu (Alex Orenshteyn)
Subject: Fractal compression articles.
Date: Thu, 09 Apr 92 12:31:30 GMT
Organization: School of Computer Science, Carnegie Mellon
Followup-To: poster

Are any of the articles mentioned in FAQS available in electronic
form on the internet?
If yes, can someone let me know where I can get them.

Thanks.
From: sean@ms.uky.edu (Sean Casey)
Newsgroups: comp.compression
Subject: Re: DISLITE.EXE uploaded to garbo.
Date: 9 Apr 92 07:46:14 GMT
Organization: The Leaning Tower of Patterson Office @ The Univ. of KY

In article <1992Apr8.195926.20292@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
:I fully agree that the decision of PKWare to have the option to make
:pkliting irreversible was a bad one from the point of virus checking
:and I wish that they would change their policy.  Nevertheless there
:is no way I will accept this file to garbo FTP archives unless
:PKWare officially and explicitly sanctions such dislite programs. 
:Acquiring such a permission is up to the writer of a dislite.  We
:will _not_ be part in any compromizing situation. 

I don't understand. Does Pkware own a patent that the decompressor is
infringing upon? Or did you find Pkware code in DISLITE? Or perhaps
the author is under some sort of non-competition contract with Pkware?

Is there some other reason an author should be required to
obtain permission from Pkware before writing a decompressor?

I'm really curious about this.

Sean

-- 
                  |``Wind, waves, etc. are breakdowns in the face of the
Sean Casey        | commitment to getting from here to there. But they are the
sean@s.ms.uky.edu | conditions for sailing -- not something to be gotten rid
U of KY, Lexington| of, but something to be danced with.''
From: cornet@duteca.et.tudelft.nl (Jan-Pieter Cornet)
Newsgroups: comp.compression
Subject: DISLITE available for anon.ftp soon
Keywords: DISLITE, PKLITE
Date: 10 Apr 92 13:57:11 GMT
Organization: Delft University of Technology, Dept. of Electrical Engineering

In a recent heated debate, the existance of DISLITE, a utility to
uncompress any PKLITEd executable, was mentioned. This resulted
in a quite substantional number of Emails to the posters.

As the author of DISLITE, I can notify you of the fact that I've
found an anonymous ftp-site willing to distribute it.

However, as I recently had a bug report coming in, I will be
doing some minor bugfixing, I'll improve the docs a little,
and then release DISLITE version 1.0 (previous versions were
0.92 and 0.91, actual only test versions). It will be very
similar to DISLITE 0.92

I hope to be able to release on monday, april 13th.

Regards,

-- 
-- Jan-Pieter
cornet@duteca.et.tudelft.nl
From: bartlett@oasys.dt.navy.mil (Scott W. Bartlett)
Newsgroups: comp.compression
Subject: PKLite & CRC Check / Viruses
Summary: Using Pklite CRC to check for stealth viruses
Keywords: PKLITE, CRC, Virus
Date: 14 Apr 92 14:27:02 GMT
Organization: Carderock Division, Naval Surface Warfare Center

This is a question regarding if/how/when PKLITE does a CRC check on a 
compressed program file.

      - does PKlite check the CRC of the .EXE file before decompressing

      - OR does it check the CRC of the decompressed program image before
           running it ?

The thought is that Macfee's SCAN/VSHIELD program would check the CRC of the
compressed .EXE file and not run it if it was infected with a virus. BUT if
the file was infected with a stealth virus then the .EXE CRC will come up ok,
but then PKlite would flag the decompressed program as failing a CRC check. 
This only works if PKlite checks AFTER decompressing.

Anyone know exactly how PKlite does its checking ?
Newsgroups: comp.compression
From: pshuang@athena.mit.edu (Ping-Shun Huang)
Subject: Re: 16:1 data compression
Organization: Massachusetts Institute of Technology
Distribution: comp
Date: Mon, 6 Apr 1992 15:58:04 GMT

Given the proper data files, any compression ratio can be claimed and
substantiated (e.g. a megabyte file of binary zeros compresses pretty
tightly by any of the commonly available compressors out there).

However, a megabyte of *TRULY* random (flames about definition of random
to /dev/null, cogent discussions to sci.crypt) data (not pseudo-random
data streams, because then it would be possible in theory and with lots
of CPU time to come up with the algorithm and any seeds that generated
that data stream, which could be much shorter than one megabyte) cannot
be compressed by any conceivable algorithm.

I remember reading that article, too, and thinking that the company
could probably be sued for false advertising.

--
Above text where applicable is (c) Copyleft 1991, all rights deserved by:
UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: DISLITE.EXE uploaded to garbo.
Date: 7 Apr 92 21:26:21 GMT
Organization: Academic Computer Centre Utrecht

In my PKLite, DIET, LZEXE comparission I noted the existence of an utility
to reverse the "irreversable compression" oprion of PKLite. I never got
so much responses to one single item. Everyone wants to know where to get it.
I am aware of all kinds of misuses of the program but I assume the fact I
could download it from the local BBS means lots of people (especialy crackers)
already have it anyway.
I uploaded it to garbo for general availability. I don't know how garbo
works normally (first upload) but I followed the instructions so it probably 
arives there soon.
The main reason most people wanted to have it was that crackers use PKLite
to hide viruses into executables and nobody knows for sure virus scanners
are capable of handling that. Also recompression by other EXE compressor
was mentioned several times. 

Nico de Vries
---------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl
VOICE : +31-3404-24931
BBS   : +31-30-341401 (Nico De_vries)

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: ross@spam.ua.oz.au (Ross Williams)
Newsgroups: comp.compression
Subject: CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY.
Summary: CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY.
Keywords: comp.compression.theory creation new group
Date: 14 Apr 92 04:57:40 GMT
Followup-To: news.groups
Organization: Statistics, Pure & Applied Mathematics, University of Adelaide


CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY
============================================
It is proposed that a new newsgroup be created:

   Name    : comp.compression.theory
   Charter : Discussions about data compression algorithms.
   Status  : Unmoderated.

Many researchers have stopped reading comp.compression because of the
volume of non-research traffic (e.g. postings with subject fields such
as "Where can I get Unix compress for MSDOS?"). There is now a strong
need for a newsgroup that can provide a forum for more theoretical
discusions about data compression and data compression algorithms.
Such a newsgroup would assist those who are actually involved in
understanding and developing new algorithms as opposed to merely using
them.

The suffix ".theory" is designed to scare off those who want to
discuss specific computer programs. The term "algorithms" in the
charter is designed to lure back those who got so scared that they
decided it must be a newsgroup for information theorists. It is
intended that the scope of the newsgroup range from information theory
to practical algorithm construction, but no further.

Timetable
---------
Tue 14-Apr-1992 Call for discussion (deadline for agreement 14-May-1992).
Tue 28-Apr-1992 Call for votes.
Thu 21-May-1992 Last day on which votes will be received.
Fri 22-May-1992 Posting of vote tally. 5 day waiting period.
Thu 28-May-1992 Creation of comp.compression.theory.

In accordance with the guidelines for newgroup creation, discussion
about the creation of this newsgroup will take place in "news.groups".

I am sending this message to a few key newsgroups and also to all
those who voted in the comp.compression vote about one year ago. I
urge you to support this proposal which has the potential to
significantly assist data compression researchers around the world.

Ross Williams
ross@spam.adelaide.edu.au
(Creator of comp.compression)
Newsgroups: comp.compression
From: madler@cco.caltech.edu (Mark Adler)
Subject: Re: PKZIP encryption contest available from garbo
Organization: California Institute of Technology, Pasadena
Date: Sun, 12 Apr 1992 00:22:37 GMT


Paul Carl Kocher makes a good point:

>>            machine could find one of these that would *not* produce 
>>            the original data.

I calculate that out of all the possible seven byte passwords (there are
2^56 of them), that about 256 of them should both check out on the
encryption header and check out for the overall file crc.  If I include
less than seven character passwords, then about 257.  (The calculation is
simply 2^56*2^-16*2^-32, where the last two terms are the probability of
matching the header and the crc respectively.)

So, you will not know if you found the right password!

Except by sending it to Phil and seeing if you get a check in the mail.

Mark Adler
madler@tybalt.caltech.edu
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: Re: PKZIP encryption contest
Date: 14 Apr 92 08:26:32 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr13.195733.1544@cco.caltech.edu> madler@cco.caltech.edu (Mark Adler) writes:


>I was just told by a PKWare person that the encrypted file in pkcontst.zip
>*does* compress with implode or deflate, but not shrink.  However, they
>did not want to use implode since then the first 100 or so bytes would be
>known, and they did not want to use delfate since PKZIP 2.x isn't out yet.
In other words they didn't want it to be as weak as it really is !!! This
weakness is true and excisting so what is the point of the contest now?

>They felt that deflate would not have several known bytes at the start,
>so using implode would be more vulnerable than the real situation (clearly
>they expect everyone to run out and buy 2.x when it comes out).  I'm not
>sure I agree on that point--there are definitely characteristics of the
>first several bytes of a deflated entry that are know, even if the bytes
>themselves are not known.  This vastly speeds up checking of candidate
>passwords that passed the encryption header test.
Excactly! And don't forget the weakest part, the CRC16 in the crypt header.

>He also said that there is a message in the entry when decrypted, so you
>will know if you got the right password.

>So in short, the entry does compress, but they elected to not do so, and
>if you succeed, you'll know.

>Mark Adler
>madler@tybalt.caltech.edu


Nico E. de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: lusardi@sybil.cs.Buffalo.EDU (Christopher Lusardi)
Newsgroups: comp.compression
Subject: Working on Modified Image Compression Program of Mark Nelson's
Date: 13 Apr 92 03:29:39 GMT
Organization: State University of New York at Buffalo/Comp Sci
Originator: lusardi@sybil.cs.Buffalo.EDU

1)I have a decompressed image which appears very faded to the human eye.

Would anyone care to contribute their thoughts on Discrete Cosine Transforms
on a solution to this problem?

Are there any guidelines in scaling transforms et cetera?

My compression ratio for this raw image is 6%. I created the raw image with 2 
nested for loops. (How/Should I increase this compression ratio.) I defined
the compression ratio as,

           compressed image size / original image size.

Can I improve my decompressed image by adjusting the below formulas or 
using a resonable better formula?

The ideal forward 2-D DCT of a n x n block of pixels is often defined as:
                                             _          _     _          _
F(u,v) = 4C(u)C(v)    n-1    n-1            |            |   |            |
         ---------   Sigma  Sigma f(j,k) cos| (2j+1)u pi |cos| (2k+1)v pi |
              2       j=0    k=0            |------------|   |------------|
            n                               |_    2n    _|   |_    2n    _|
 
where pi is 3.14159265, C(w) =  1 / sqrt(2) for w = 0 
                                1           for w = 1,2,...,n-1, and
 n-1
Sigma is summation from 0 to n-1.
 j=0

The ideal reverse 2-D DCT is defined as:
                                         _          _     _          _
          n-1    n-1                    |            |   |            |
f(j,k) = Sigma  Sigma C(u)C(v)F(u,v) cos| (2j+1)u pi |cos| (2k+1)v pi |
          u=0    v=0                    |------------|   |------------|
                                        |_    2n    _|   |_    2n    _|.

2)Does anybody have the formula on-line from this book?

The source code (ftp.uu.net:/graphics/jpeg/jpegsrc.v2.tar.Z 
[137.39.1.9]) is based on Appendix A.2 of the book "Discrete Cosine 
Transform---Algorithms, Advantages, Applications" by K.R. Rao and P. Yip  
(Academic Press, Inc, London, 1990).  
 
3)Are there any other convenient 2-D DCT formulas which I can implement? 
(That use sine and/or cosine functions on a 8 X 8 matrix etc. and doesn't 
use complex numbers.) 

					Thanks,
					Chris



-- 
Christopher M. Lusardi     University At Buffalo     lusardi@acsu.buffalo.edu
vms.huji.ac.il!gilf
From: gilf@vms.huji.ac.il (GIL FREUND)
Newsgroups: comp.compression
Subject: Strange Zip file.
Date: 7 Apr 92 01:02:09 GMT
Article-I.D.: vms.6APR199216494690
Organization: The Hebrew University of Jerusalem
News-Software: VAX/VMS VNEWS 1.41    Lines: 10

I have reacently recieved a ZIP file which I cannot decompress. When
viewing the file (With pkunzip -v or the XTreeGold Archive manager) I find
that some of the files have UNKNOWEN written at the compression method
column.
What does this mean? The freind who gave me the file isn't around.

Thanks

Gil
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.compression
Subject: PKZIP 2.00 DMA support !?
Date: 7 Apr 92 17:03:45 GMT
Organization: Academic Computer Centre Utrecht

I have heard second hand PKZIP 2.00 will support DMA. This support means that
the PKZIP 2.00 program will me much faster than 1.93a since compression/
decompression take place while the disk runs. Some questions?

- can somebody confirm this
- is this DMA support the reason for all the problems PKWARE has with 486
  cache support
- how does this DMA support cooperate with disk caching software, Windows
  (especially 3.1), DesqView, OS/2 etc
- if something goes wrong with DMA support can that wreck my harddisk
- is the support also available for floppy disks (this would be really
  great, combined with the promissed formatting during compression
  this would make PKWARE a direct copetitor for all existing backup software!)
- can it be disabled (like 386 support etc) in case someone has problems
  with it

Anyone any info?

Nico de Vries
---------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl
VOICE : +31-3404-24931
BBS   : +31-30-341401 (Nico De_vries)

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: thom@f517.n107.z1.ieee.org (Thom Henderson)
Newsgroups: comp.compression
Subject: Re: Where to get ARC from SEA?
Date: 9 Apr 92 22:56:00 GMT
Article-I.D.: zeus.13568.29E7AF41
Organization: FidoNet node 1:107/517 - SEAboard HST, Clifton NJ


 #      By the way, I do not waste harddisk space with their compressor, at 
 # least 
 #      not this latest one.  I have ARC 6.02 there for 
 # completeness, but forget 
 #      version 7.  

Of course.  That way you can claim to include ARC in your reports while giving
it as bad a score as possible.  I have an old copy of version 3 around
somewhere; would you like me to send you a copy?  That way you could report
even worse numbers for ARC.  

At least now I know where you're coming from.  

--- SEAmail 1.10
 * Origin: System Enhancement Associates  (107/517)
--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Thom Henderson - Internet: thom@f517.n107.z1.ieee.org
From: espen@leo.unm.edu
Newsgroups: comp.unix.aux
Subject: Re: cc for A/UX
Keywords: cc
Date: 13 Apr 92 20:41:28 GMT
Article-I.D.: lynx.naxj=_n
Organization: University of New Mexico, Albuquerque

In article <1992Apr13.165528.1487@cactus.org> covert@cactus.org (Richard Covert) writes:
>I just started using A/UX and noticed that it comes with the
>older K&R C 'cc' and not the newer ANSI C compiler.
>
>And several othger questions:
>
>1) Is there an ANSI C 'cc'type compiler available for A/UX?
>
>2) Is there a C++ compiler available for A/UX?
>
>3) Is there a MOTIF development environment available for A/UX?
>
>4) Is there an X Windows based source code debugger? Other X Windows
>   tools?
>
>5) I read awhile ago that there is a CD ROM available with the
>   X11 R5 code. Can this CD ROM be used with A/UX? And if so, how can
>   I get a copy of that CD ROM drive.
>
>6) How do I move files from other UNIX machines to A/UX? A/UX
>   treats ASCII text files differently then standard UNIX.
>   Help!!
>
>I know about the FSF GNU tools, but am not sure if they are
>currently supported on A/UX. That is because of the feud between
>FSF and Apple Corp.
>
>If the GNU Tools are available how can I get a copy of them?
>
>-- 
>Richard E. Covert                 covert@cactus.org
>CACTUS                  ..!cs.utexas.edu!cactus.org!covert 
	
	Your ONE question should be: IS THERE A FAQ LIST FOR AUX!!

	Answer: Yes there is. It's posted here regularly and also
	        available via anon ftp from jagubox.gsfc.nasa.gov

	I have e-mailed the FAQ posting to Mr. Covert.


	Peter Espen
	espen@leo.unm.edu
From: beser@aplcomm.JHUAPL.EDU (Nick Beser)
Newsgroups: comp.unix.aux
Subject: Re: AUX print driver
Keywords: System 7
Date: 14 Apr 92 12:54:03 GMT
Organization: JHU/APL, Laurel, MD

jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:

>Actually, it _is_ in the FAQ :)

>You _can_ use System7 printer drivers under A/UX 2.0.1... just copy the
>correct files over (LaserWriter and LaserPrep)...

>Simple.

Jim,
	I looked at the FAQ again. Number 19 mentioned a laser Prep file. Its
my understanding (supported by looking at the System Folders on both System 7
disks and System 6 disk that have the System 7 capatible print driver) that
Laser Prep is no longer used in System 7 (Its not even on the disk). I will 
try to copy the latest print monitor and LaserWriter file over the the System 
Folder on the A/UX system. If this works, I will let you know, and you should
revise #19.

Nick
Newsgroups: comp.unix.aux
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Subject: Re: AUX print driver
Keywords: System 7
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center
Date: Tue, 14 Apr 1992 14:39:24 GMT

jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:

>beser@aplcomm.JHUAPL.EDU (Nick Beser) writes:

>>jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:

>>>You _can_ use System7 printer drivers under A/UX 2.0.1... just copy the
>>>correct files over (LaserWriter and LaserPrep)...

>>Laser Prep is no longer used in System 7 (Its not even on the disk). I will 
>>try to copy the latest print monitor and LaserWriter file over the the System 
>>Folder on the A/UX system. If this works, I will let you know, and you should
>>revise #19.

>It's true that LaserPrep is no longer needed under System7, however, when
>System7 (7.0) first came out, to use the System7 drivers under System6, you
>needed to install a "revised" LaserPrep file (this was included I think in
>the 7.0 distribution and definately in the Group Upgrade Kit). In fact, I
>think if you look at the System 6.0.8 disks, you'll find LaserPrep.

>It's possible that LaserPrep is no longer needed for LaserWriter 7.1 or 7.1.1
>to run under System6 (LaserPrep is given as version 7.0). It's also
>possible that you don't need it under A/UX. I'm running LW 7.1.1 and I'll
>delete LaserPrep and see what happens...

Well, LaserPrep no longer seems needed for LW 7.1.1 (and 7.1 too).

I _did_ forget that you should also install the System7 version of the
Print Monitor application... This will be fixed in the FAQ.
-- 
==============================================================================
#include <std/disclaimer.h>

                Jim Jagielski                  NASA/GSFC, Code 711.4
          jim@jagubox.gsfc.nasa.gov             Greenbelt, MD 20771

       "If we took the bones out, it wouldn't be crunchy now would it?"
From: rick@crowbar.aux.apple.com (Rick Auricchio)
Newsgroups: comp.unix.aux
Subject: Re: CD150 and A/UX
Date: 15 Apr 92 23:35:44 GMT
Article-I.D.: goofy.23262

Somehow my prior posting didn't make it out correctly.

Anyway, the CD-150 works with A/UX 3.0 (maybe 2.0.1 too).
--
--
Rick Auricchio       rick@apple.com        A/UX Engineering     Mooney N894AR
Apple Computer Inc, 10500 N.DeAnza Blvd MS35VK Cupertino CA 95014 408-974-4227
My opinion is my own. My employer? They use a windsock and a fire extinguisher.
Newsgroups: comp.unix.aux
From: spencer@panix.com (David Spencer)
Subject: a frequently asked non-FAQ (was starting X11...)
Date: Mon, 13 Apr 1992 22:42:40 GMT
Organization: PANIX Public Access Unix, NYC

In <1992Apr12.190749.12392@m.cs.uiuc.edu> coolidge@cs.uiuc.edu (John
Coolidge) kindly responds to my newbie questions on scrolling in X and
on (not) starting X from CommandShell, and suggests:

>Both of these should be made FAQs (if they're not already).

They aren't - it's the first place I checked. Can John's answers be
dropped right in the FAQ?

BTW, thanks to those who sent me email responses. And _many_ thanks to
John for X and gcc.

spence