Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!valley From: valley@uchicago (Doug Dougherty) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: VRAM386 in SIMTEL20 corrupted?? Keywords: simtel20 vram386.zip sysutl Message-ID: Date: 16 Mar 91 17:17:11 GMT References: <5412@vela.acs.oakland.edu> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago Lines: 24 wong@cs.UAlberta.CA (Brian Wong) writes: >1. ftp it from 26.2.0.74. yes I DID use tenex mode. > the second time I tried 128.252.135.4 and I used binary mode. >2. uuencode the file, get a file called vram386.uue >3. use 1k-xmodem program to download the text file to my pc >4. uudecode the file then pkunzip First of all, truer words have never been spoken than the statement/position that when people have problems with files d/l'd from cbib or Simtel and assert that the file on the d/l server must therefore be corrupt, those people are wrong (or, shall we say, they are wrong at least 99.999999% of the time...) That said, I should point out that the same claim cannot be made for the unmoderated groups, where there is no control over how people u/l stuff. Second, why did you do the uuencode/uudecode pair? Why not just d/l the .ZIP file to your PC in binary mode, using any of the popular protocols? (Xmodem-1K should certainly work) By doing that, you have broken the integrity of the original file, and are, therefore, on your own... (Sorry for the nasty sound of this, but this is really an area where the doctrine of KISS applies.)