The collector has only been compiled under Windows NT, with the original Microsoft SDK, with Visual C++ 2.0 and later, with the GNU win32 environment, with Borland 4.5, and recently with Watcom C. 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.) 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 will appear as long as it's running. The cord test program has not been ported (but should port easily). A toy editor (cord/de.exe) based on cords (heavyweight strings represented as trees) has been ported and is included. It runs fine under either win32 or win32S. It serves as an example of a true Windows application, except that it was written by a nonexpert Windows programmer. (There are some peculiarities in the way files are displayed. The is displayed explicitly for standard DOS text files. As in the UNIX version, control characters are displayed explicitly, but in this case as red text. This may be suboptimal for some tastes and/or sets of default window colors.) For Microsoft development tools, rename NT_MAKEFILE as MAKEFILE. (Make sure that the CPU environment variable is defined to be i386.) 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 believed to work only for b18, not b19, probably dues to linker changes in b19. This is probably fixable with a different definition of DATASTART and DATAEND in config.h. 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). The garbage collector in its default configuration EXPECTS AT LEAST 4 BYTE ALIGNMENT. Thus the BORLAND DEFAULT MUST BE OVERRIDDEN. (In my opinion, it should usually be anyway. I expect that -a1 introduces major performance penalties on a 486 or Pentium.) Note that this changes structure layouts. (As a last resort, config.h can be changed to allow 1 byte alignment. But this has significant negative performance implications.) The Makefile is set up to assume Borland 4.5. If you have another version, change the line near the top. By default, it does not require the assembler. If you do have the assembler, I recommend removing the -DUSE_GENERIC. Incremental collection support was recently added. This is currently pretty simpleminded. Pages are protected. Protection faults are caught by a handler installed at the bottom of the handler stack. This is both slow and interacts poorly with a debugger. Whenever possible, I recommend adding a call to GC_enable_incremental at the last possible moment, after most debugging is complete. Unlike the UNIX versions, no system calls are wrapped by the collector itself. It may be necessary to wrap ReadFile calls that use a buffer in the heap, so that the call does not encounter a protection fault while it's running. (As usual, none of this is an issue unless GC_enable_incremental is called.) Note that incremental collection is disabled with -DSMALL_CONFIG, which is the default for win32. If you need incremental collection, undefine SMALL_CONFIG. Incremental collection is not supported under win32s, and it may not be possible to do so. However, win32 applications that attempt to use incremental collection should continue to run, since the collector detects if it's running under win32s and turns calls to GC_enable_incremental() into noops. James Clark has contributed the necessary code to support win32 threads. This code is known to exhibit some problems with incremental collection enabled. 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 so that long file names are preserved. To build the garbage collector test with VC++ from the command line, use nmake /F ".\gc.mak" CFG="gctest - Win32 Release" This requires that the subdirectory gctest\Release exist. This version relies on the collector residing in a dll. This version currently supports incremental collection only if it is enabled before any additional threads are created. It is known to not be completely solid. At a minimum it can deadlock if a thread starts in the middle of an allocation. There may be other problems. If you need solid support for win32 threads, you check with Geodesic Systems. I haven't tried it, but they claim to support it. Hans Ivan V. Demakov's README for the Watcom port: [ He points out in a later message that there may be a problem compiling under Windows-3.11 for Windows NT. ] Watcom C/C++ 10.5, 10.6, 11.0 tested. The collector runs on WIN32 and DOS4GW dos-extender with both stack and register based calling conventions (options -5r and -5s). Incremental collection not supported. OS/2 not tested, but should work (only some #ifdef's added for OS/2 port). cord not ported. Watcom C fails to compile it, from first attempt. Since I don't use it, I don't try to fix it. cpp_test succeeds, but not compiled automaticaly with WCC_MAKEFILE. My changes: * config.h Added definitions for Watcom C/C++. Undefined MPROTECT_VDB for Watcom C/C++ MSWIN32, I don't have idea why it not work. * gc.h Explicitly declared GC_noop. This prevents program crash, compiled with -5r option. * gc_priv.h Changed declaration for GC_push_one to make compiler happy. Added GC_dos4gw_get_mem declaration and GET_MEM uses it in DOS4GW environment. * os_dep.c Added __WATCOMC__ and DOS4GW #ifdef's. Added GC_dos4gw_get_mem. * mach_dep.c For Watcom used setjmp method of marking registers. * WCC_MAKEFILE New file. Makefile for Watcom C/C++. * gc_watcom.asm New file. Some functions for DOS4GW. This functions may (probably) be done in C, but I can't figure out how do this for all possible options of compiler. * README.watcom This file. Ivan Demakov (email: dem@tgrad.nsk.su)