Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!yale.edu!yale!mintaka!bloom-picayune.mit.edu!athena.mit.edu!pshuang From: pshuang@athena.mit.edu (Ping-Shun Huang) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: PKLITE, what's the catch??? Message-ID: Date: 1 Jul 91 00:22:33 GMT References: <1991Jun26.012138.13729@mlb.semi.harris.com> <11230005@hplsla.HP.COM> <1991Jun29.052850.2121@netcom.COM> <1991Jun29.150110.19766@midway.uchicago.edu> Sender: news@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology Lines: 18 In-Reply-To: valley@gsbsun.uchicago.edu's message of 29 Jun 91 15:01:10 GMT In article <1991Jun29.150110.19766@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes: > Question: If not to the original, what does LZEXE recontruct to? > Something functionally similar or what? I think UNLZEXE decompresses the previously-compressed .EXE file to the same thing that the little header on it would have decompressed into memory. So if the .EXE file doesn't work for whatever reasons, the UNLZEXE'd version wouldn't load correctly, either. I do not know, however, how PKLITE does a better job of restoring the original .EXE than UNLZEXE does -- not that I'm not curious, just not curious enough to try to follow what PKLITE is doing, machine instruction at a time. Anyone know? -- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]