[Cygwin64] unloading of dlls

[Peter Rosin]

Hi!

I'm wondering if there is some difference in how dlls are unloaded
on Cygwin64 vs Cygwin32?

In libggi, there's a X.dll that handles drawing on an X server.
X.dll has the capacity to dynamically load a dbe.dll (dbe.dll is
linked with -lXext, something which X.dll is not) helper that
calls XdbeQueryExtension. XdbeQueryExtension happens to store
a pointer to a hook that is supposed to be called on XCloseDisplay
in some private area. Now, if I unload dbe.dll before I close
XCloseDisplay, the hook appears to have disappeared from the
address space by the time I call XCloseDisplay, but only on
Cygwin64 (with drastic effects). While a teeny bit fragile, and
probably a practice best avoided, this still appears to work
fine on Cygwin32.

Is there some natural explanation for the 32/64 difference?

Cheers,
Peter

[Corinna Vinschen]

Post by Peter Rosin
Hi!
I'm wondering if there is some difference in how dlls are unloaded
on Cygwin64 vs Cygwin32?
In libggi, there's a X.dll that handles drawing on an X server.
X.dll has the capacity to dynamically load a dbe.dll (dbe.dll is
linked with -lXext, something which X.dll is not) helper that
calls XdbeQueryExtension. XdbeQueryExtension happens to store
a pointer to a hook that is supposed to be called on XCloseDisplay
in some private area. Now, if I unload dbe.dll before I close
XCloseDisplay, the hook appears to have disappeared from the
address space by the time I call XCloseDisplay, but only on
Cygwin64 (with drastic effects). While a teeny bit fragile, and
probably a practice best avoided, this still appears to work
fine on Cygwin32.
Is there some natural explanation for the 32/64 difference?

I don't have any. In theory that shouldn't have worked in 32 bit
either. Maybe the memory handling of the OS is different.


Corinna