aboutsummaryrefslogtreecommitdiffstats
path: root/gc/doc/README.win32
diff options
context:
space:
mode:
Diffstat (limited to 'gc/doc/README.win32')
-rw-r--r--gc/doc/README.win3212
1 files changed, 10 insertions, 2 deletions
diff --git a/gc/doc/README.win32 b/gc/doc/README.win32
index b1a6ec5..dcccec3 100644
--- a/gc/doc/README.win32
+++ b/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.