home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / go / 2653 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.9 KB  |  83 lines
  1. Newsgroups: rec.games.go
  2. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!olounela
  3. From: olounela@klaava.Helsinki.FI (Olli Lounela)
  4. Subject: Re: Help me "self-extract" PCIGC44Z.EXE
  5. Message-ID: <1992Dec31.002231.11461@klaava.Helsinki.FI>
  6. Organization: University of Helsinki
  7. References: <92365.000051PEF2@psuvm.psu.edu> <1992Dec30.150540.15957@ll.mit.edu>
  8. Date: Thu, 31 Dec 1992 00:22:31 GMT
  9. Lines: 72
  10.  
  11. In article <1992Dec30.150540.15957@ll.mit.edu> nates@ll.mit.edu ( Nate Smith) writes:
  12. >In article <92365.000051PEF2@psuvm.psu.edu> Per Fjelstad <PEF2@psuvm.psu.edu> writes:
  13. >>
  14. >>I introduced one possibly significant irregularity in transferring the file to
  15. >>my home computer.  I needed to reduce the record length to get VM's command
  16. >>"pctrans" to move the file.  I did this by running it through VM's simulations
  17. >>of the Unix "Compress" _and_ "Decompress" commands. On the return "Decompress"
  18. >>operation, I choose an option that reduced the length of the records in the
  19. >>output file.  With this done, I was able to download the file to my PC.
  20. >>
  21. >>1.   Might I have distorted the file by sending it through that sequence?
  22. >
  23. >  yes.  you probably did.  the .exe file is already compressed, so it wont
  24. >do to compress & uncompress it another time.  if there is a way to move it
  25.  
  26. Now this is only mostly true.  The problem with data integrity is real,
  27. but while it is usually of no use to recompress a compressed file, it
  28. usually does not do any real harm either.  It only results in an
  29. unefficient recompress that usually outputs a longer result than the
  30. source. 
  31.  
  32. Lots of other people have pointed out that the most likely source of an
  33. incorrect decompress of a self-extracting archive is a problem with the
  34. reliability of the data transfer.  With a compressed file, a single bit
  35. incorrect usually causes a major problem.  With ftp, however, I myself
  36. have had no problems whatsoever, unless I forget to set it to binary
  37. transfer (and in that case it's my own fault anyway :-)
  38.  
  39. Always remeber to set things to binary transfer unless it is plainly
  40. ASCII you are transferring (and even then it is not a really bad idea
  41. unless the file is lengthy :-)
  42.  
  43. >>2.   Or was my original understanding wrong that I just needed to type the
  44. >>     filename, once the file was on my PC, to get a working program?
  45. >
  46. >as adrian pointed out (new for me too!), the pkunzip program will unzip a
  47. >self-extracting archive and try to inform you of errors.  the problem may
  48. >be that by the time the file made it to your PC (i think) it is corrupted.
  49.  
  50. Your "original understanding" is correct.  Once you get the file into
  51. your PC intact, you should but need to run it.  It should decompress
  52. itself and result in several files. 
  53.  
  54. Adrian's advice is correct, however.  PKunZip works with a
  55. self-extracting file as well as with any PKZip archive, up to and
  56. including PK(un?)Zip's -t option, which tests archive integrity. 
  57.  
  58. Nevertheless, I think that the source of your problem is trying
  59. uncompress the program with VM's (unstandard) decompress.  Please
  60. remember that pcigc44z.exe has already been compressed and so it does
  61. not really benefit from a recompress, and if it does, there is something
  62. seriously wrong with your (un)recompress.  For example: I ran it through
  63. Un*x compress, and it refused to do anything.  It reported a compression
  64. of -32.62% -- yes, that's an increase of 1/3 in length!
  65.  
  66. 'VM' makes me think you're using IBM mainframe. Somehow I cannot believe
  67. they have that much better a compress than Un*x, and it's been dicussed
  68. in News that PKZip actually has a very efficient comression algorithm.
  69.  
  70. I did, BTW, snurf the PCigc from Milton today, and it worked without
  71. problems, self-extraction and all. 
  72.  
  73. >>Per Fjelstad (3k),
  74. >
  75. >this isnt any help - just speculation!
  76.  
  77. But I hope I'm of some help, even if only a little.
  78. -- 
  79.     Olli, 3 dan
  80.  
  81. E-mail: olounela@cc.helsinki.fi           ! .sig still under construction.
  82. Blame me only for any opinions expressed. !  Never you mind, I don't either.
  83.