Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!spool.mu.edu!cs.umn.edu!kksys!edgar!mmug!UUCP
From: Jim.Spencer@p510.f22.n282.z1.edgar.mn.org (Jim Spencer)
Newsgroups: comp.sys.mac.misc
Subject: CODE 0
Message-ID: <669344404.1@mmug.edgar.mn.org>
Date: 17 Mar 91 22:33:59 GMT
Sender: UUCP@mmug.edgar.mn.org
Lines: 16


Jim Chow writes in a message to All

JC> I've been exploring around with ResEdit on some applications. 
JC> I'm particularly interested in the CODE 0 part of applications. 
JC> Can anyone tell me what is in it and whether it can be reconstructed 
JC> if it has been corrupted or damaged? I know this seems like a 
JC> general question but I would like to know what is typically located 
JC> in the first few bytes of it. ie does it have a count of all 
JC> the resources? is it a map for which resources to load first? 
JC> Any info on this is appreciated. 

CODE ID=0 is the applications jump table.  It consists of series of entries for each routine that can be called from code in another segment.  On the disk, the entries contain the code to load the segment in which the routine resides plus the offset of the routine from the beginning of the segment.  When an application is launched, CODE 0 is brought into memory and a jump is done to the first entry which should contain the code necessary to load and jump to the entry point of the application.  When a segme






nt is loaded, the entries in the memory resident version of the jump table are changed to be jump to subroutine instructions.  When the segment is unloaded, the jump table entries are changed back to the load segment instructions.

I go into this detail in order to explain that there really isn't any way to rebuild a damaged CODE 0 resource.  You would have to know exactly what routine each entry pointed to and know that routine's segment and offset.  Even the author of the program doesn't know this: its handled by the Linker during development.