john.russell@canremote.uucp (JOHN RUSSELL) (07/08/90)
Does the shareware program PowerPacker violate the rules governing self-modifying code? I would expect that its unpacking routine only modifies that data cache. However I don't know if it overwrites the unpacking routine with any other code. The reason I'm curious (other than a desire to avoid un-PowerPacking multi megs of executables if I upgrade my processor) is that PowerPacker is perfectly content to crunch devices, libraries, handlers and fonts. Now I would have thought that either LoadSegging such a file would not result in the entry point getting called, or maybe the unpacking routine would have displaced some magic cookies that exec looks for inside libraries, fonts, etc. However I've got my arp.library crunched and the requester still pops up, likewise I can setfont to a crunched font or send stuff to SPEAK: and PRT: after crunching them. So, is this program "processor-friendly"? John --- * Via ProDoor 3.1R
jesup@cbmvax.commodore.com (Randell Jesup) (07/12/90)
In article <b27040e1474d26965764@canremote.uucp> john.russell@canremote.uucp (JOHN RUSSELL) writes: >Does the shareware program PowerPacker violate the rules governing >self-modifying code? I would expect that its unpacking routine only >modifies that data cache. However I don't know if it overwrites the >unpacking routine with any other code. ... >However I've got my arp.library crunched and the requester still pops >up, likewise I can setfont to a crunched font or send stuff to SPEAK: >and PRT: after crunching them. > >So, is this program "processor-friendly"? Probably not, though it's likely to work fine on an '030 in most cases. However, if you get unlucky, or on a machine with a larger cache (an A3000 with cache board, or an '040, etc) it may well fail. The stock '030 cache is small enough that it rarely causes problems with things that are being loaded (and therefore the only conflict would be if code had been executed out of code that was then freed, and then allocated for <whatever> to put code into, and then the code was executed, all before the cache entry was overwritten. A larger cache (or very bad luck) will hit this pretty easily. Also note that classic self-modifying code is FAR more likely to have problems with the '030 cache, since you don't have the free/ allocate/startup (which is usually enough to cause it to be forced out) to get through. You can see this problem with a lot of games that don't work on '020/'030's. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
d87-khd@sm.luth.se (Karl-Gunnar Hultland) (07/12/90)
In article <b27040e1474d26965764@canremote.uucp> john.russell@canremote.uucp (JOHN RUSSELL) writes: >Does the shareware program PowerPacker violate the rules governing >self-modifying code? I would expect that its unpacking routine only >modifies that data cache. However I don't know if it overwrites the >unpacking routine with any other code. < lotsa stuff deleted > > >So, is this program "processor-friendly"? > >John Well I've tried PowerPacker on the 3000 and it breaks.... At least the PACKER breaks but the crunched programs works as good as before... Don't know why though. Karl --- Karl Hultland,(d87-khd@sm.luth.se) University of Lulea,Sweden Egoist: a person of low taste, more interested in himself than in me. - A. Bierce