Hey guys, I've been working on a new version of digc, and one of the slated additions is, naturally, to exploit the new GC change as much as I can.  But I'm having trouble getting Windows to play along.

When DLLs are statically-linked in I can do this to them:

    void register_modules ()
    {
        HANDLE lib = LoadLibraryA ("psapi.dll");

        assert (lib);
        *cast (void **) &EnumProcessModules = GetProcAddress (lib, "EnumProcessModules");
        assert (EnumProcessModules);

        HMODULE [] list;
        DWORD needed;

        while (1)
        {
            if (!EnumProcessModules (GetCurrentProcess, list, list.length * HMODULE.sizeof, &needed))
                assert (0);
            if (list.length * HMODULE.sizeof == needed)
                break;
            list.length = needed / HMODULE.sizeof;
        }

        foreach (HMODULE item; list)
        {
            void function (void *) set_gc;

            *cast (void **) &set_gc = GetProcAddress (item, "D8test_dll8__set_gcFPvZv");
            if (set_gc)
                set_gc (getGCHandle);
        }
    }

This searches for a "__set_gc" function in all the attached modules and gives smacks as needed.  For digc, I could generate a "static this" in the executable that does this, and then put in other stuff while generating DLLMain.  However, there are problems here:

- "static this" is unordered; this might be called after a "static this" in an attached DLL is executed, or when a symbol in the program calls a DLL allocation, going through its stub.  This would be fixable if I can alter what symbol is called for "main" in the linker.

- It depends upon (boo hiss) PSAPI.DLL.  Windows /sucks/ for process information discovery.  I can't figure out exactly what contexts PSAPI.DLL should be in, but if history is any indication it will be "always on a testing computer, never on a user computer".

- I need a separate process for loading DLLs, and that requires active participation.  I have always tried avoiding proprietary programming (such as using an approved Library class and only that class) in digc; I believe that would cause problems.

So I would like instead to work from the other direction, to allow the DLLs to find out information about the running process and align their GC.  This must be done before anything resembling an entry point is called in the process, so I can't use Get/SetEnvironment.

So the challenge: make a pointer to the main process's getGCHandle accessible from the DLL with nothing but regular system API calls, before main is called in the process.

Can anyone do it?

I DLL-ised GC; I was just doing it out of boredom and expected it to start my processor on fire, but it accidentally worked!  Simple to use; just stuff "phobos_gc.dll" somewhere and link in "phobos_gc.lib" to your DLLs and executables; they'll then use the same GC, just like that!  You can download them at:

http://members.shaw.ca/burton-radons/phobos_gc.zip

It's not useable for me for digc unless if it becomes part of the standard distribution.

Burton Radons wrote:
> I DLL-ised GC; I was just doing it out of boredom and expected it to start my processor on fire, but it accidentally worked!  Simple to use; just stuff "phobos_gc.dll" somewhere and link in "phobos_gc.lib" to your DLLs and executables; they'll then use the same GC, just like that!  You can download them at:
> 
> http://members.shaw.ca/burton-radons/phobos_gc.zip
> 
> It's not useable for me for digc unless if it becomes part of the standard distribution.


Oh, what fun!  Nice work, Burton! :-)

Also... looking forward to seeing what new magic digc can do after all this time.  digc has certainly been an inspiration.

-JJR