home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Users, OpenDoc and memory < prev    next >
Encoding:
Internet Message Format  |  1996-07-01  |  1.8 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Users, OpenDoc and memory
  2. Sent:        6/28/96 9:24 AM
  3. Received:    7/1/96 8:34 AM
  4. From:        Troy Gaul, tgaul@apple.com
  5. Reply-To:    OpenDoc-Interest@CILabs.ORG
  6. To:          OpenDoc Related Technologies Interest List, OpenDoc-Interest@CILabs
  7.  
  8. >The Cyberdog library has many fragments merged together
  9. >(presumably via the MPW tool MergeFragment).  Merging
  10. >code fragments, however, doesn't really combine the data
  11. >and code sections of each library.  Instead, the data forks
  12. >of each of the libraries are concatenated, and the 'cfrg' 
  13. >resource tracks the sizes and offsets of each fragment within
  14. >the new, merged shared library file.  When the fragment is
  15. >loaded (via GetSharedLibrary(), GetDiskFragment(), or implicitly),
  16. >only the relevant section of the file actually gets loaded
  17. >into memory.
  18.  
  19. This description is true of merged fragments. However, Cyberdog doesn't 
  20. have such merged fragments in its data fork. It has one code fragment 
  21. which contains all of the parts and the base Cyberdog code.
  22.  
  23. You can verify this with a tool like DumpPEF.  You will see that there 
  24. are many 'containers' (139, actually), but the offset into the file of 
  25. each one is 0 and the length is 2425651. There are multiple cfrg entries 
  26. (one for each container) to satisfy SOM and CFM, but they all point to 
  27. the same main code fragment.  Merging fragments is not necessary to do 
  28. this.
  29.  
  30. If there had been multiple code fragments, even if they are in the same 
  31. file, there would still have been the need for many imports and exports, 
  32. and the size would have been much larger.
  33.  
  34. _troy
  35.  
  36. ......................................................................
  37.  Troy Gaul                                            tgaul@apple.com
  38.  Apple Computer, Inc.                               OpenDoc Partsmith
  39.  
  40.