Getting handle to calling dll/exe

[Daniel =?iso-8859-1?Q?Lidstr=F6m?=]

I'm using a library called fyba. This library reads and writes files in a
format called sosi. fyba uses the following code to determine if the
calling process has own methods to handle errors, messages, etc:

// If this parameter is NULL,
// GetModuleHandle returns a handle of the file used
// to create the calling process.
hInstExe = GetModuleHandle( NULL );

if( hInstExe!=NULL )
LC_StartMessAdr = (void*)GetProcAddress(hInstExe, "LC_StartMessDll");

So, if LC_StartMessDll is found in the calling process, this function is
called. If it isn't found, a default function is called.
Now to my problem: my application consists of geo.exe and gcomm.dll.
gcomm.dll is the part that uses fyba, so I would like to be able to put the
callback functions in gcomm.dll, but since fyba uses the above method to
find the functions, they have to be in geo.exe. Is there a way to modify
the above code so that the methods will be found in gcomm.dll. More
precisely, I want to find the callback functions in the dll/exe that calls
fyba, not in the "top"-process (geo.exe). I hope I made myself clear.

Thanks in advance!

--
Daniel
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Guest]

So, if LC_StartMessDll is found in the calling process, this function is
called. If it isn't found, a default function is called.
Now to my problem: my application consists of geo.exe and gcomm.dll.
gcomm.dll is the part that uses fyba, so I would like to be able to put the
callback functions in gcomm.dll, but since fyba uses the above method to
find the functions, they have to be in geo.exe. Is there a way to modify
the above code so that the methods will be found in gcomm.dll. More
precisely, I want to find the callback functions in the dll/exe that calls
fyba, not in the "top"-process (geo.exe). I hope I made myself clear.

You can't do it. You must use a stub function in exe that in turn may
call anything else. Bad design, tough luck, sorry.

Actually, you may hack the code, so that the call to GetModuleHandle
gets redirected, but it is exotic and not recommended (and I never did it).

 

[William DePalo [MVP VC++]]

I'm using a library called fyba. This library reads and writes files in a
format called sosi. fyba uses the following code to determine if the
calling process has own methods to handle errors, messages, etc:

// If this parameter is NULL,
// GetModuleHandle returns a handle of the file used
// to create the calling process.
hInstExe = GetModuleHandle( NULL );

if( hInstExe!=NULL )
LC_StartMessAdr = (void*)GetProcAddress(hInstExe, "LC_StartMessDll");

So, if LC_StartMessDll is found in the calling process, this function is
called. If it isn't found, a default function is called.
Now to my problem: my application consists of geo.exe and gcomm.dll.
gcomm.dll is the part that uses fyba, so I would like to be able to put
the
callback functions in gcomm.dll, but since fyba uses the above method to
find the functions, they have to be in geo.exe. Is there a way to modify
the above code so that the methods will be found in gcomm.dll. More
precisely, I want to find the callback functions in the dll/exe that calls
fyba, not in the "top"-process (geo.exe). I hope I made myself clear.

You did.

There are two properties of Win32, both a little off the beaten track, that
_may_ make this possible.

First, it is not well-known but an executable can export functions. It's a
bit of a hack but I have used the trick once or twice in the last decade,
specifically when I have a DLL which can potentially be loaded into
different contexts. Inside the DLL, I look for an export with a given name
and if I find it, I make the assumption that the DLL is loaded into its
preferred context. It is a slightly brittle technique but that's a subject
for another day. In any event, perhaps you can export the function from your
executable.

Second, I know that what you really want to do is to export from your DLL.
Win32 supports export "forwarding" of DLLs. See this link

http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/ for a discussion. As the
article points out, NTDLL and KERNEL32 both have RtlHeapAlloc() functions.
Rather than implement it twice, or wrap one around the other, a little bit
of linker and loader voodoo is used to share the single implementation. So,
when KERNEL32 DLL is loaded, the loader just binds its RtlHeapAlloc() export
to the one in NTDLL.

Now, the $64,000 question is whether export forwarding works for functions
exported by executables. I don't know. If you try it, I'd surely like to
know, one way or the other.

May the force be with you.

Regards,
Will