home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / compress / 3742 < prev    next >
Encoding:
Text File  |  1992-11-04  |  3.1 KB  |  63 lines
  1. Newsgroups: comp.compression
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!news.edu.tw!news!nchud5.nchu.edu.tw!NCHUD1.NCHU.EDU.TW!303JKJAN%VAX9K.DNET
  3. From: 303JKJAN%VAX9K.DNET@NCHUD1.NCHU.EDU.TW (jinn-ke jan)
  4. Subject: Re: Compression + Standards = Trouble?
  5. Message-ID: <303JKJAN%VAX9K.DNET.3.720975395@NCHUD1.NCHU.EDU.TW>
  6. Lines: 50
  7. Sender: usenet@nchud5.nchu.edu.tw (USENET account)
  8. Nntp-Posting-Host: 140.120.7.38
  9. Organization: Dept. of Applied Math. Nat'l Chung Hsing University
  10. References: <Bwy39p.HxK@news.cso.uiuc.edu>
  11. Date: Thu, 5 Nov 1992 14:56:35 GMT
  12.  
  13. In article <Bwy39p.HxK@news.cso.uiuc.edu> jy10033@ehsn20.cen.uiuc.edu (Joshua M Yelon) writes:
  14. >From: jy10033@ehsn20.cen.uiuc.edu (Joshua M Yelon)
  15. >Subject: Compression + Standards = Trouble?
  16. >Date: Fri, 30 Oct 1992 17:29:45 GMT
  17. >There's been a big discussion under comp.os.linux about which
  18. >compressor to use...  most people think that we should use compress,
  19. >since everybody has "uncompress", but not everybody has unzip
  20. >or melt.
  21. >
  22. >I was a little bothered, though, that we were tied to an obsolete
  23. >compression program simply because "uncompress" is the only one
  24. >available as part of the standard unix distribution.  Of course,
  25. >we could try to convince vendors to start putting unzip or melt
  26. >into their distributions, but by the time we succeeded, those
  27. >would be just as obsolete.
  28. >
  29. >I therefore started trying to design an obsolesence-proof compression
  30. >standard.  It seems to me that the only way to achieve this is by
  31. >using self-extracting archives.  Any compressor can use any newfangled
  32. >compression scheme it wants, without fear that somebody won't be able
  33. >to process the result, as long as the archive is self-extracting.
  34. >
  35. >However, self-extracting archives typically have problems of their own:
  36. >
  37. >    * they include decompression code, which involves overhead,
  38. >    * they are executable binaries, and can transmit viruses,
  39. >    * the included decompression-code is typically machine-dependent. 
  40. >
  41. >All of these can be solved by writing the decompression code in
  42. >some machine-independent p-code, with no dangerous instructions
  43. >(thereby preventing viruses), and a special instruction for doing
  44. >lempel-ziv decompression (which can be used as a one-line decompression
  45. >program for those cases when the overhead isn't worthwhile).
  46. >
  47. >Unfortunately, a pcode interpreter might be slow, compared to
  48. >decompression code written in assembly language.  Potential solution:
  49. >don't write a pcode interpreter, write a pcode compiler.  Have it
  50. >cache the compiled versions of decompression headers that it's seen
  51. >before.
  52. >
  53. >What I'd like to know is, what am I forgetting?
  54. >
  55.   Might be the executable binaries are OK., since the technique of software
  56.  authentication may be used for preventing viruses. For details please refer
  57.  to (1). Okamoto,E and Masumoto, H(1990):ID_Based authentication systems for
  58.  computer virus detection, Electronics Letters, Vol.26, No. 15, July 1990.
  59.  (2). Harn, L. et al(1992): A software authentication systems for the 
  60.    prevention of computer viruses, Proceedings of ACM 1992 computer science
  61.    conference, March 1992.
  62.  J. K. Jan.
  63.