HDTenEightyP/NetNews huggingface dataset:
From: kambiz@thecube.tcs.com (Kambiz Homayounfar)
Subject: Jobs Offered
Keywords: Speech Coding, DSP
Organization: Teknekron Communications Inc.
Date: Thu, 7 Jan 1993 19:26:48 GMT

Positions Available 

Teknekron Communications Systems Inc. (Berkeley, CA) is a technology  
development and licensing company with a staff of 180 most of whom are  
engineers and scientists.  We work on a variety of  R&D projects in areas  
of wireless communications (cellular, cordles, PCS) and telecommunications  
software (network management systems, operational contol).  
 
Senior Scientist, Speech Coding
Requires MS or Ph.D in electrical engineering with minimum of 10 years  
experience in design and implementation of speech compression algorithms  
for telecommunications and consumer electronics products. 
Responsibilities include:
* Formulation of novel speech compression algorithms at bit rates below 16  
kbps
* High-Level (using C-language) and CAD-based (COSSAP, WAVES) simulation  
of speech coding algorithms
* Objective and subjective evaluation of low bit-rate speech coders
* Real-time implementation of speech coding algorithms on general-purpose  
DSP chips (TI TMS family, AT&T DSP1600) 
* Design of processor architectures for custom implementation of speech  
compression algorithms
* Analysis of standard (CCITT, TIA, ETSI) speech coding algorithms for  
low-power implementation on custom DSP architectures

DSP Application Engineer
Requires BS/MS in Electrical Engineering with minimum of 5 years of  
product development experience in wireless or consumer electronics  
industries. Sales engineering experience and knowledge of Japanese  
language highly desirable. 

Responsibilities include:
* Assembly-level DSP software development
* Design and construction of DSP-based hardware prototypes
* Consult with customers' engineers to assure compliance with customers's  
needs and specifications

Contact: 
Kambiz Homayounfar
Senior Manager, Wireless Communications
Teknekron Communications Systems Inc.
2121 Allston Way
Berkeley, CA 94704
Fax # (510) 848 8851
Internet: kambiz@tcsi.com
From: pgleason@ncratl.AtlantaGA.NCR.COM (Pat Gleason)
Newsgroups: comp.compression
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Date: 12 Jan 93 23:25:09 GMT
Organization: NCR Engineering and Manufacturing Atlanta -- Atlanta, GA

In <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. 

PKZIP 2.04c does not work correctly in my OS/2 DOS box, which doesn't
use QDPMI. There may be a bug in QDPMI, but it is not the cause of all
the DPMI problems with PKZIP 2.04c.
Newsgroups: comp.compression
From: mcastle@cs.umr.edu (Michael R Castle)
Subject: Re: A note on using PKUNZIP 2.04c with Windows 3.1
Date: Sat, 9 Jan 1993 17:23:05 GMT
Organization: University of Missouri - Rolla, Rolla, MO

In article <19429@mindlink.bc.ca> Mike_Quigley@mindlink.bc.ca (Mike Quigley) writes:
>in my computer, so this is a real pissoff! Even more so, because already one
>local BBS sysop has converted all of his MSDOS files (which he was
>compressing with LZH) to the "new" ZIP.
>
So, what you do is get a copy of every message posted about pkzip 2.04c, put
them into a fairly big archive, and upload them to his board, preferably to
a public forum. 

mrc
-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle@cs.umr.edu     and be right all the time, or not work at all
S087891@UMRVMA.UMR.EDU   and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
From: spitz@parc.xerox.com (Larry Spitz)
Newsgroups: comp.compression
Subject: Re: getting G4 Fax standards
Date: 4 Jan 93 22:40:56 GMT
Distribution: usa
Organization: Xerox PARC

@FtCollins.NCR.COM writes:



>If you want copies of CCITT standards, you can also try
>ANSI. For some standards I recently ordered, they were
>significantly cheaper than Global Engineering (although
>still not "cheap"). One drawback is that they only
>take checks, no PO's or credit cards. There can be
>reached at
>      American National Standards Institute
>      (212)642-4900
>      (212)302-1286 FAX
>      
Or try Omnicom 703-281-1135. I don't know about credit cards but
my past experiences with them have been positive, so I would guess
that they would take credit cards.

Larry
--
Larry Spitz            Xerox PARC                Spitz@parc.xerox.com 
           415-813-7767          415-813-7081 Fax
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: PKZip 2.04c quick impressions
Organization: University of Vaasa, Finland
Date: Thu, 7 Jan 1993 09:24:14 GMT

Here is one more feature to ponder.  I use a screen scrollback
buffer (buffit30) which captures bios screen writes to a buffer. 
Very handy for some purposes.  The new pkzip confuses it.  The only
things that get sent are the eolns, so that if you look at the
scroll-back buffer you are faced with blank pages.  Perhaps 2.04
uses some kind of a weird mix of bios and direct screen writes.  A
frustrating feature.  I wish there were some method of turning off
the direct writes.

It begins to look that we are looking at a product that is
unfinished in more respects than it should be, despite the extended
waiting period :-(.  I am sure that there is much sophisticated code
within 2.04 to make it an advanced compressor and to make it fast,
and to get the last ounce efficiency out of the PC's individual
configuration.  But for an ordinary end users it is the practial
things that count, just like the many small bugs that already have
been reported.  They are important however progressive the product
otherwise. 

Since we factually seem to find ourselves in the postition of
happily drooling beta testers, let's hope that these reports are
seriously taken into consideration to mutual advantage.

..................................................................
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: dboer@let.rug.nl (Ale de Boer)
Subject: Re: PKzip 2.04c and Norton Anti-Virus
Keywords: PKZIP, NAV, Norton, Virus
Organization: Faculteit der Letteren, Rijksuniversiteit Groningen, NL
Date: Tue, 5 Jan 1993 19:50:01 GMT

Hi Scott,

Thankx for shedding some light on things. If only this idiot which
keeps deleting Ron's and my files would own up and say what's
troubling him. All he or she does is create directories with warnings
which seem due to some bug in Norton Antivirus
In article <bartlett.39.726254874@oasys.dt.navy.mil> bartlett@oasys.dt.navy.mil (Scott W. Bartlett) writes:
>VSHIELD/SCAN v99: report no virus present.
>Norton Anti-Virus (from Norton Desktop for Windows 2.0) dated 3/23/92:
>                  reports variant of the Maltese Amb. virus in the
>                  PKUNZIP, PKZIPFIX, and ZIP2EXE files.
>ThunderByte/VirX/FluProt+: report no virus, but that non-standard exe-
>                           headers are used in the files indicating a
>                           programming bug or possible virus.
>                           (note- I do not usually use these three virus
>                            detectors so the correct answers may vary).
>PKLITE 1.15/CHKLITE: Reports files compressed with PKLITE 1.20 (higher
>                     version than generally available).
>
>** POSSIBLE CAUSE ** PKLite 1.20 generating false-positive alarm in NAV.
Right as far as I'm concerned
>** OTHER POSSIBILITES ** open for suggestions....

Best, Ale.

-- 
________________________________________________________________
Ale de Boer, Department of English, University of Groningen
Oude Kijk in 't Jatstraat 26            E-mail: dboer@let.rug.nl
9712 EK  Groningen                      The Netherlands
From: etl0@ns1.cc.lehigh.edu (ERIC TODD LANDRIEU)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04c  vs.  ARJ/LHA/ZOO   Compression/Speed Results
Date: 9 Jan 93 00:43:45 GMT
Organization: Lehigh University

In article <C0IzF8.EFr@unix.amherst.edu>, djweisbe@unix.amherst.edu (David Weisb
erger) writes:
>
>: Total Size: 720937 bytes
>: Archivers:  PKZIP204c PKZIP110 PKZIP193a ARJ230 LHA213 ZOO210
>: Machine:    386/33, 10M RAM  \w 128k BIOS Shadow RAM
>: Drive:      Seagate ST296N (84M)  SCSI controller   (no s/w cache)
>: Timing:     Norton Utilities'  TM.EXE  v4.50
>: Execution:  MSDOS BATch file
>:
>: Congratulations PKWARE, PKZip's speed and now compression is #1!
>:
>Funny, I get better compression with Zip 1.9 in some cases.
>
True,,, I was running file size comparisons between the new PKZIP, the latest
ZOO, and the newest ZIP.  Both PKZIP and ZIP consistently left ZOO looking
bad.  There was never a significant difference between ZIP and UNZIP, though.
Each program did better in some programs(and I never saw a pattern, such as
executables better on one, etc.), but the difference would only be around 1-2K
for files several hundred K in size when compressed.

                                  Eric Landrieu

                                  
-- 

               ===============================================
               =   Eric Landrieu  =  ETL0@ns1.CC.lehigh.EDU  =
               ===============================================
"I'd be apathetic, but I don't really care about it.
Newsgroups: comp.compression
From: fox@rei.com (Fuzzy Fox)
Subject: Re: An idea for HD compression
Date: Mon, 11 Jan 1993 23:38:18 GMT
Organization: Recognition Equipment, Inc.

rogerj@aix.rpi.edu (Diversion (Jeff Rogers)) writes:

>Why not try to reclaim this lost space? Use a null-suppression algorithm on
>half-empty sectors, keep an index of them, store them somewhere else in a
>packed form, and get them when they're requested by int 13(?). 

I assume you mean to handle this at a BIOS level, where you don't know
what the OS might be trying to do with each sector.  If so, how do you
propose to know which bytes are significant in any sector that's written
to disk?  DOS does not fill unused bytes with zeroes, nor does any other
OS (although maybe VMS does).

>I think this is similar to what stacker does, but I recall hearing that
>stacker operates on ms-dos files only, and doesn't work with other os's

One of the problems that Stacker must deal with, as well as your own
program, is how to deal with the simulation of a disk that has more
clusters than the actual medium.  Say you have a 1 Meg floppy and you
are simulating a 2 Meg floppy.  Suppose a program writes data to every
single sector on the 2 Meg floppy.  Which sectors do you keep, and which
do you throw away?  What happens if the data compression used does not
let you fit all the sectors on the 1 Meg physical medium?  A real floppy
disk cannot return a "disk full" error; that's what the OS does.  You
could return a hard write error, but is that a solution?

-- 
#ifdef TRUE        | Fuzzy Fox (a.k.a. David DeSimone)       fuzzy@netcom.com
#define  TRUE   0  |
#define  FALSE  1  |  "911 Emergency Rescue Service - Can you hold, please?"
#endif             |
From: jkokko@lk-hp-2.hut.fi (Jari Kokko)
Newsgroups: comp.compression
Subject: Re: List of known bugs for pkzip2.04 please..
Date: 10 Jan 1993 12:45:18 GMT
Organization: Helsinki University of Technology
Distribution: inet
NNTP-Posting-Host: lk-hp-2.hut.fi
Keywords: pkzip bugs

ksiew@mullian.ee.mu.OZ.AU (steven kok-hsien siew):
> If I have left out any other bugs could someone please add it in for me.

I just found out that the new pkzip (I got it from garbo) doesn't
work when the PKTMP variable points to a joined drive.

I have my ramdisk (drive e:) joined (mounted) as c:\ramdisk (don't ask why)
and pkzip gives an error like "couldn't open e:\blaa.bla".

pkzip 1.10 works correctly, as do lha, arj, pkpak, pak, zoo or anything else
for that matter. It's a bug.


-- 
Jari Kokko.
Newsgroups: comp.compression
From: NETOPRWA@ncsuvm.cc.ncsu.edu (Wayne Aiken)
Subject: Another PKZIP 2.04C bug...
Organization: North Carolina State University
Date: Mon, 11 Jan 1993 02:26:18 GMT

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.
 
I'll post a sample file that displays this characteristic soon.
 
Wayne Aiken                                            "You can BE what
PO Box 30904            slack@ncsu.edu                  you WON'T!!"
Raleigh, NC  27622                                       --"Bob"
(919) 782-8171          StarFleet BBS: (919) 782-3095
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: 11 Jan 93 20:18:52 GMT

tusk@daimi.aau.dk (Martin M|ller Pedersen) writes:

> 1: pkzip v1.93 and hpack0.78a0 doesn't work if some files are packed
>    with diet. Use arj instead.

What do you mean - that the first two archivers just crash or that
they don't compress well? Because, compressing DIETed files does not
make sense at all - they are already compressed...

> 2: Some games destroyed themself if they are diet-packed because
>    they write direct to their .exe files. E.g. twinpac

That's true for -any- executable compressor, not just for Diet.

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
Subject: Re: WUARCHIVE CLAIMS PKZIP/UNZIP 2.04c IS A HACK
From: skriefal@eeyore.stcloud.msus.edu (Scott Kriefall)
Date: 6 Jan 93 17:31:38 -0600
Organization: St. Cloud State Univ., MN
Keywords: pkzip pkunzip hack

> Has anybody determined whether this was a real infection, or
> a false report from the virus scanner?  The one I downloaded
> had a file along with it that said that only one scanner of 
> about three reported the infection.
 
According to PKWare themselves, it *IS* a false report from Norton 
Antivirus.  Apparently it is attributable to a problem with older 
versions of NAV, since newer releases do not report the virus.  IOW, 
it is highly unlikely that PKZ204C.EXE is infected.  It seems like 
people just have to find virii where there are none...

Newsgroups: comp.compression
From: luosu@dialog.su.OZ.AU (Luo Su Huai)
Subject: wanted: Miss America image sequence
Reply-To: luosu@dialog.su.OZ.AU (Luo Su Huai)
Organization: University of Sydney, Australia
Date: Tue, 12 Jan 1993 06:57:53 GMT

Hi, there,

I need some motion images for my motion detecting method.

So could you please tell me how can I get the Miss America image sequence?

Best way is through some ftp place.

Thanks very much in advance.


Suhuai Luo
Speech Technology Research Group
Department of Electrical Eng.
The University of Sydney
NSW 2006
Australia

luosu@brutus.ee.su.oz.au



Keywords: 


Newsgroups: comp.compression
From: dannyb@panix.com (Daniel Burstein)
Subject: PKWare BBS number, was: Re: Pkzip v2.04c availability
Organization: Panix, NYC
Date: Wed, 6 Jan 1993 00:32:10 GMT

In <1icjroINNsjc@gambier.rick.cs.ubc.ca> i3y092@rick.cs.ubc.ca (Adam Nicolas Cheal) writes:

>Could someone PLEASE repost the new Pkzip to wuarchive or ftp.ulowell or
>ANYWHERE!?! I really want to get my hands on this release (finally). Heck,
>if anyone has a BBS phone # I can call, even that would do. Thanks in advance.

>- Adam
>i3y092@rick.cs.ubc.ca

the phone number for the pkware bbs: 1-414-354-8670
From: rommel@jonas.gold.sub.org (Kai Uwe Rommel)
Newsgroups: comp.compression
Subject: Re: Re : PKZIP 2.04c vs. ARJ 2.39B (and LHA/ZOO) Compression Results ** UPDATED
Date: 11 Jan 93 23:03:28 GMT
Organization: Private

In article <9301110211.AA07789@mensa.cc.deakin.OZ.AU> drinnen@deakin.edu.au (Philip Shead) writes:
>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

First, we are talking about ARJ, not LHA. Second, I have reasons not
to use LHA* format archives. Third, there is a full clone version of
LHA for OS/2 (called LH2) available (including EA support). And
finally, I will not use any DOS archiver in an OS/2 or Unix DOS box
because it will not archive files with long names nor OS/2 extended
attributes, so it's useless.

Kai Uwe Rommel

--
/* Kai Uwe Rommel                                      Muenchen, Germany *
 * rommel@jonas.gold.sub.org                       Phone +49 89 723 4101 *
 * rommel@informatik.tu-muenchen.de                  Fax +49 89 723 7889 */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams
Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: AV backward compatibility (was: List of known bugs...)
Keywords: pkzip bugs
Organization: DSG, Stanford University, CA 94305, USA
Date: Mon, 11 Jan 93 05:06:10 GMT

In article <1993Jan11.025634.28694@csc.ti.com> peterson@choctaw.csc.ti.com (Bob Peterson) writes:
>I find 2.04c's inability to check and display 1.10 AV codes a serious
>defect.  Apparently messages to PKWARE.Inc@mixcom.com could result in a
>fix in the next release.
>
>    Bob

Don't bother -- a totally new (and yes, incompatbile) AV system is
needed.  AV codes for both the old and new versions of PKZIP can be
forged quite easily, and all the feature does is provide a false
sense of security.  Adding backward-compatibility would just allow 
people to continue using their current fake AV codes without even 
having to rewrite the forging programs.

-- Paul

________Paul C. Kocher, Box 13554, Stanford, CA 94309, 415/497-6589_________
kocherp@leland.stanford.edu (preferred), root@kocher.stanford.edu.  Contract
programming work sought (PC assembly, security, etc) -- write/call for info.

Newsgroups: comp.compression
From: ksiew@mullian.ee.mu.OZ.AU (steven kok-hsien siew)
Subject: List of known bugs for pkzip2.04 please..
Keywords: pkzip bugs
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 8 Jan 1993 23:08:24 GMT

Could someone please post a list of all the known bugs or flaws on
the new nversion of pkzip 2.04.

So far I think these are the bugs found.

BUGS

 1) DPMI bug. Won't work properly with my QEMM DPMI 0.9

 2) Multi-Volume bug. All volume have same extension zip

 3) Multi-Volume bug 2. If compressed size is slightly larger than 1 disk
    it does not restore proprely

 If I have left out any other bugs could someone please add it in for me.
Thanks in advance....

-----------------------------------------------------------------------------
The only people who believe that unlimited | Steven Siew  tel 03 803 4662
growth can take place in a finite system   | ksiew@munagin.ee.mu.oz.au
are madmen or economists. Spaceship earth: | Don't call me! Gundam me! 
-----------------------------------------------------------------------------
Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: about posting pkzip 2.04c
Organization: University of Vaasa, Finland
Date: Fri, 8 Jan 1993 23:44:42 GMT

In article <1993Jan8.131759.25899@htsa.aha.nl> eduard@htsa.aha.nl (Eduard Beijnes) writes:
>When I read the comp.compression newsgroup I saw that pkzip >2.00 is out.
>When I look at alt.binaries.pictures they post really BIG files
>Why doesn't anyone post something like pkzip ?
>(or did I miss it ?)

Simply because the discussion newsgroups like comp.comression
*ABSOLUTELY* are *NOT* for binary postings!!!

If the gentle users want pkz204c.exe posted oin the news, the only
correct place where to post it is the moderated comp.binaries.ibm.pc. 
Please do not commint the faux pas of posting it elsewhere!!!!

   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: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.compression
Subject: Re: ARJ 2.30 minor bug
Date: 7 Jan 93 15:52:28 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Distribution: comp
Organization: GE Corporate R&D Center, Schenectady NY

In article <1993Jan6.183815.16705@vax5.cit.cornell.edu>, mmy@vax5.cit.cornell.edu writes:
| There seems to be a minor problem with ARJ 2.30, if you include the same file
| 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?
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: PKZIP 2.04c vs. ARJ 2.39b (and LHA/ZOO) Compression Results ** UPDATED
Date: 10 Jan 1993 21:04:41 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu
Keywords: archive compress ARJ PKZIP LHA ZOO


>> Why not make an InfoARJ??? The methodolgy behind ARJ and ZIP is

AAAAAAAAAAAAGH!

...

Sorry.  I'm ok now.

mark
Xref: sparky comp.compression:4401 comp.os.msdos.4dos:36
From: pss1@kepler.unh.edu (Paul S Secinaro)
Newsgroups: comp.compression,comp.os.msdos.4dos
Subject: A note on using PKUNZIP 2.04c with 4DOS and Windows 3.1
Date: 6 Jan 1993 13:47:15 GMT
Organization: University of New Hampshire  -  Durham, NH
Distribution: inet
NNTP-Posting-Host: kepler.unh.edu


In case anyone else is having problems along these lines, I'd just
like to mention that I've experienced fatal crashes (memory allocation
errors) when trying to use pkunzip 2.04c in a Windows 4DOS session.
In order to prevent this, I'm using the '-)' switch, which disables
DPMI support (this is mentioned in ADDENDUM.DOC).  This seems to
eliminate the problem.

Just thought I'd pass that along.  If anyone *doesn't* have problems
with 4DOS and pkunzip, I'd like to hear about what they did to get
around it (other than the above-mentioned solution).

Paul


-- 
Paul Secinaro
pss1@kepler.unh.edu
Synthetic Vision and Pattern Analysis Laboratory
UNH Dept. of Electrical and Computer Engineering
From: i3y092@rick.cs.ubc.ca (Adam Nicolas Cheal)
Newsgroups: comp.compression
Subject: Re: Pkzip v2.04c availability
Date: 5 Jan 1993 10:26:00 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Distribution: world
NNTP-Posting-Host: gambier.rick.cs.ubc.ca

Could someone PLEASE repost the new Pkzip to wuarchive or ftp.ulowell or
ANYWHERE!?! I really want to get my hands on this release (finally). Heck,
if anyone has a BBS phone # I can call, even that would do. Thanks in advance.

- Adam
i3y092@rick.cs.ubc.ca