www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Auto-discovery of process information to enable self-registering

reply Burton Radons <burton-radons smocky.com> writes:
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?
Apr 30 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
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.
Apr 30 2005
parent John Reimer <brk_6502 yahoo.com> writes:
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
Apr 30 2005