import gc6.1alpha5

gc/doc/README.win32

@@ -21,6 +21,13 @@ registrations are ignored, but not terribly quickly.)
 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 arbirtray memory segments obtained from
+VirtualQuery.)
+
 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
@@ -50,7 +57,8 @@ This appears to cause problems under Windows NT and Windows 2000 (but
 not Windows 95/98) if the memory is later passed to CreateDIBitmap.
 To work around this problem, build the collector with -DUSE_GLOBAL_ALLOC.
 This is currently incompatible with -DUSE_MUNMAP.  (Thanks to Jonathan
-Clark for tracking this down.)
+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.)
 
 For Microsoft development tools, rename NT_MAKEFILE as
 MAKEFILE.  (Make sure that the CPU environment variable is defined
@@ -64,7 +72,7 @@ absence of thread support).
 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
+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.