-The collector has at various times been compiled under Windows 95 & NT,
-with the original Microsoft SDK, with Visual C++ 2.0, 4.0, and 6, with
-the GNU win32 environment, with Borland 4.5, with Watcom C, and recently
+The collector has at various times been compiled under Windows 95 & later, NT,
+and XP, with the original Microsoft SDK, with Visual C++ 2.0, 4.0, and 6, with
+the GNU win32 tools, with Borland 4.5, with Watcom C, and recently
with the Digital Mars compiler. It is likely that some of these have been
broken in the meantime. Patches are appreciated.
-It runs under both win32s and win32, but with different semantics.
-Under win32, all writable pages outside of the heaps and stack are
-scanned for roots. Thus the collector sees pointers in DLL data
-segments. Under win32s, only the main data segment is scanned.
-(The main data segment should always be scanned. Under some
-versions of win32s, other regions may also be scanned.)
-Thus all accessible objects should be accessible from local variables
-or variables in the main data segment. Alternatively, other data
-segments (e.g. in DLLs) may be registered with the collector by
-calling GC_init() and then GC_register_root_section(a), where
-a is the address of some variable inside the data segment. (Duplicate
-registrations are ignored, but not terribly quickly.)
-
-(There are two reasons for this. We didn't want to see many 16:16
-pointers. And the VirtualQuery call has different semantics under
-the two systems, and under different versions of win32s.)
-
-Win32 applications compiled with some flavor of gcc currently behave
-like win32s applications, in that dynamic library data segments are
-not scanned. (Gcc does not directly support Microsoft's "structured
-exception handling". It turns out that use of this feature is
-unavoidable if you scan arbitrary memory segments obtained from
-VirtualQuery.)
-
-The collector test program "gctest" is linked as a GUI application,
+For historical reasons,
+the collector test program "gctest" is linked as a GUI application,
but does not open any windows. Its output appears in the file
"gc.log". It may be started from the file manager. The hour glass
cursor may appear as long as it's running. If it is started from the
Clark for tracking this down. There's some chance this may be fixed
in 6.1alpha4, since we now separate heap sections with an unused page.)
+Microsoft Tools
+---------------
For Microsoft development tools, rename NT_MAKEFILE as
MAKEFILE. (Make sure that the CPU environment variable is defined
to be i386.) In order to use the gc_cpp.h C++ interface, all
client code should include gc_cpp.h.
+For historical reasons,
+the collector test program "gctest" is linked as a GUI application,
+but does not open any windows. Its output appears in the file
+"gc.log". It may be started from the file manager. The hour glass
+cursor may appear as long as it's running. If it is started from the
+command line, it will usually run in the background. Wait a few
+minutes (a few seconds on a modern machine) before you check the output.
+You should see either a failure indication or a "Collector appears to
+work" message.
+
If you would prefer a VC++.NET project file, ask boehm@acm.org. One has
been contributed, but it seems to contain some absolute paths etc., so
it can presumably only be a starting point, and is not in the standard
collector was built as a static library (as it normally is in the
absence of thread support).
+GNU Tools
+---------
For GNU-win32, use the regular makefile, possibly after uncommenting
the line "include Makefile.DLLs". The latter should be necessary only
-if you want to package the collector as a DLL. The GNU-win32 port is
+if you want to package the collector as a DLL.
+[Is the following sentence obsolete? -HB] The GNU-win32 port is
believed to work only for b18, not b19, probably due to linker changes
in b19. This is probably fixable with a different definition of
DATASTART and DATAEND in gcconfig.h.
+The collector should also be buildable under Cygwin with either the
+old standard Makefile, or with the "configure;make" machinery.
+
+Borland Tools
+-------------
+[Rarely tested.]
For Borland tools, use BCC_MAKEFILE. Note that
Borland's compiler defaults to 1 byte alignment in structures (-a1),
whereas Visual C++ appears to default to 8 byte alignment (/Zp8).
require the assembler. If you do have the assembler, I recommend
removing the -DUSE_GENERIC.
+Incremental Collection
+----------------------
There is some support for incremental collection. This is
currently pretty simple-minded. Pages are protected. Protection
faults are caught by a handler installed at the bottom of the handler
Note that incremental collection is disabled with -DSMALL_CONFIG.
-James Clark has contributed the necessary code to support win32 threads.
+Threads
+-------
+
+James Clark has contributed the necessary code to support win32 threads
+with the collector in a DLL.
Use NT_THREADS_MAKEFILE (a.k.a gc.mak) instead of NT_MAKEFILE
to build this version. Note that this requires some files whose names
are more than 8 + 3 characters long. Thus you should unpack the tar file
This version currently supports incremental collection only if it is
enabled before any additional threads are created.
-Version 4.13 attempts to fix some of the earlier problems, but there
-may be other issues. If you need solid support for win32 threads, you
-might check with Geodesic Systems. Their collector must be licensed,
-but they have invested far more time in win32-specific issues.
-Hans
+Since 6.3alpha2, threads are also better supported in static library builds
+with Microsoft tools (use NT_STATIC_THREADS_MAKEFILE) and with the GNU
+tools. In all cases,the collector must be built with GC_WIN32_THREADS
+defined, even if the Cygwin pthreads interface is used.
+(NT_STATIC_THREADS_MAKEFILE does this implicitly. Under Cygwin,
+./configure --enable-threads=posix defines GC_WIN32_THREADS.) Threads must be
+created with GC_CreateThread. This can be accomplished by
+including gc.h and then calling CreateThread, which is redefined
+by gc.h.
+
+For the statically linked versions, it is required that GC_init()
+be called before other GC calls, since there seems to be no implicit way
+to initialize the allocation lock. The easiest way to ensure this in
+portable code is to call GC_INIT() from the main executable (not
+a dynamic library) before calling any other GC_ routines.
+
+We strongly advise against using the TerminateThread() win32 API call,
+especially with the garbage collector. Any use is likely to provoke a
+crash in the GC, since it makes it impossible for the collector to
+correctly track threads.
+
+
+Watcom compiler
+---------------
Ivan V. Demakov's README for the Watcom port:
Ivan Demakov (email: ivan@tgrad.nsk.su)
+Win32S
+------
+
+[The following is probably obsolete. The win32s support is still in the
+collector, but I doubt anyone cares, or has tested it recently.]
+
+The collector runs under both win32s and win32, but with different semantics.
+Under win32, all writable pages outside of the heaps and stack are
+scanned for roots. Thus the collector sees pointers in DLL data
+segments. Under win32s, only the main data segment is scanned.
+(The main data segment should always be scanned. Under some
+versions of win32s, other regions may also be scanned.)
+Thus all accessible objects should be accessible from local variables
+or variables in the main data segment. Alternatively, other data
+segments (e.g. in DLLs) may be registered with the collector by
+calling GC_init() and then GC_register_root_section(a), where
+a is the address of some variable inside the data segment. (Duplicate
+registrations are ignored, but not terribly quickly.)
+
+(There are two reasons for this. We didn't want to see many 16:16
+pointers. And the VirtualQuery call has different semantics under
+the two systems, and under different versions of win32s.)
OSDN Git Service
