home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / sa104os2.zip / SATHR104.ZIP / SATHER / SYSTEM / GC / README.MAC < prev    next >
Text File  |  1994-06-09  |  2KB  |  55 lines
  1. README.Mac
  2. ----------
  3.  
  4. This is a preliminary version of my port of the collector to the Macintosh.
  5. It passes all tests in the file test.c, but there might be more bugs lurking.
  6.  
  7. Mac Specific Files
  8. ------------------
  9.  
  10. Since I built the collector under Symantec C++ 7, and it doesn't use Makefile's
  11. in the standard sense, I'm including the file mac_proj.sit.hqx, which contains
  12. a binhexed (similar to uuencoding) copy of the compressed project files you'll
  13. need to build this on the Macintosh. This contains projects for building
  14. the test program, gctest.pi, a project containing just the library sources,
  15. gc.lib.pi, for testing the cord library, cord.pi, and finally a hacked up
  16. version of the cord text editor, de, that runs under the console emulation
  17. library, ANSI++, under Symantec. It has a pretty weak emulation of curses
  18. and only really works if you hack console.c a little bit in ANSI++. However
  19. it works well enough to page through a file and move around editing, etc.
  20.  
  21. Changes
  22. -------
  23.  
  24. The biggest changes made to the source was providing a target for MACINTOSH.
  25. Some care had to be taken to fit it in with the rest of the #ifdefs, as usual.
  26. The most most major change was converting the GC_arrays structure from static
  27. data to dynamically allocated, because no file can contain more than 32k of
  28. global data under Symantec C/C++. However; on the non-Macintosh platforms
  29. I still leave it as global data, I just take a pointer to it rather than
  30. dynamically allocating it.
  31.  
  32. One thing this affects is that it is really a good idea to call GC_init
  33. before using the collector. I don't trust the collector to be able to
  34. do this automatically with these new changes.
  35.  
  36. Also, since GC_arrays is no longer at a constant location, the static
  37. initialization of the array GC_obj_kinds won't work. So, I added a new
  38. function to mark.c, called C_init_mark() which does the rest of the
  39. initializations of GC_obj_kinds.
  40.  
  41. Happy garbage collecting!
  42.  
  43. Patrick Beard, June 6, 1994.
  44.  
  45. I undid some of Patrick's changes, to keep things as consistent as
  46. possible across platforms.  GC_arrays is statically allocated.  A few
  47. of its former components are now dynamically allocated separately.
  48. It should not be necessary to call GC_init explicitly.
  49.  
  50. I replaced the macro MACINTOSH with MACOS, both for consistency with
  51. other platforms, and to better distinguish it from AUX (which is
  52. admittedly less interesting, but was already supported).
  53.  
  54. Hans-J. Boehm, June 9, 1994
  55.