From within my DLL, I want to load its string table. I'm trying to
use LoadString, but to do so I need a HINSTANCE. I tried using
GetModuleHandle(NULL), but of course this returns a handle to the
calling process - not my DLL.

As a temporary workaround, I'm using the handle returned by LoadLibrary
(which works fine). The drawback is that the DLL's filename and path is
now hardcoded. How can I load my strings without hardcoding the filename?

PS This is not a standard and does not have a dllmain() function.

--
Ritchie

"Ritchie" <qiournvdlirhjgiuhdiuh345@hotmail.com> wrote in message
news:bg66tt$lns18$1@ID-156657.news.uni-berlin.de...
Why not?

The easiest way is to provide a DllMain. Otherwise, you could use
VirtualQuery on an address that you know is in the DLL (e.g. one of your
functions). The AllocationBase returned will be the base address of the DLL.

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

"Tim Robinson" <tim.at.gaat.freeserve.co.uk@invalid.com> wrote in message news:bg6ckj$l3htn$1@ID-103400.news.uni-berlin.de...
Its an MSDN sample which happens not to have one (its also the first dll
source I've ever seen). Since your post, I opened up another sample and
copied/pasted its dllmain; Low and behold, it works a treat. Presumably,
anytime that the o/s loads a dll, it calls dllmain. Hopefully I've have a
fuller understanding soon - I have Charles Petzold's Programming Windows
on order.

Thanks Tim
--
Ritchie

"Ritchie" <qiournvdlirhjgiuhdiuh345@hotmail.com> wrote in message
news:bg6ola$l76k1$1@ID-156657.news.uni-berlin.de...
That's right. Windows always calls the DLL's entry point, which is actually
located inside the C runtime. The entry point is responsible for
initialising the C runtime, after which it calls your DllMain. If you don't
provide a DllMain it provides a dummy implementation which does nothing.

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

On Tue, 29 Jul 2003 17:09:10 +0100, "Ritchie"
<qiournvdlirhjgiuhdiuh345@hotmail.com> wrote:

If you don't want to know the filename of the DLL you want to load a
resource from, then how do you even know that some particular resource
is the right resource? In other words, why don't you want to hardcode
the filename? What are you trying to accomplish?

</dib>
John Dibling
Witty banter omitted for your protection

"John Dibling" <dib@substitute_my_full_last_name_here.com> wrote in message news:21qdivghjpbqov3rv93sqvdrnrprbidtel@4ax.com...
My DLL is loading its _own_ strings. My project is just this one DLL

IMHO, hardcoding the filename is bad practice. And as it happens, now that
I've added a dllmain, the code for loading the strings is shorter than it
would be if I used a hardcoded filename to obtain an HINSTANCE. Its a win
win situation.

--
Ritchie

On Wed, 30 Jul 2003 08:00:38 +0100, "Ritchie"
<qiournvdlirhjgiuhdiuh345@hotmail.com> wrote:


What you are looking for then -- correct me if I'm wrong -- is a
WINAPI function that returns the HMODULE of the calling module, like
this: GetThisModuleHandle(). AFAIK, there is no such function to
call. There is however a way to enumerate _all_ loaded modules; look
up EnumProcessModules() in MSDN. But in using EnumProcessModules()
you will still have the problem of determining which module is the one
you are looking for. I have 2 suggestions in making this
determination.

First, you could use GetProcAddress() on each HMODULE to see if the
module exports a particular function that you know you export.
Suppose for example you have a function GetMyHandle() which your DLL
exports...

<psudocode>

HMODULE GetMyHandle()
{
for( /*each HMODULE found by EnumProcessModules()*/ )
{
FARPROC lpfn = GetProcAddress(hmTest, "GetMyHandle");
bool bThisIsIt = (lpfn == GetMyHandle); // if the ptr returned
by GetProcAddress is the same address as the running-function's start
address, they should be the same DLL
}
}

</psudocode>

Now I must point out that I dont know for certian that the pointer
GetProcAddress() returns would be the same address that GertMyHandle
is at, but I can't imagine it doesn't.

My other suggestion is to just hardcode the DLL's name and use
GetModuleHandle(). I agree with you in principle that hardcoding
things isn't always a great idea. But I find that problems that would
otherwise be solved with hardcoded data or magic cookies have
comprehensive solutions that tend to be brittle. That is, the
comprehensive solution is often complex in implementation, with lots
of plumbing that can get clogged. In industrial code, I will often
choose the simpler, albeit less elegant method of using hardcoded data
and magic cookies because I prefer robustness and effeciency over
elegance. But this is a personal choice so long as the comprehensive
code isn't *too* brittle...

</dib>
John Dibling
Witty banter omitted for your protection

"John Dibling" <dib@substitute_my_full_last_name_here.com> wrote in message news:0oofiv4jdoaip6j2kfc6nuq0b7rh2k7tbl@4ax.com...
John, may be your news server isn't showing all the posts in this
thread, but the issue was resolved yesterday. I sinply added a
DllMain() function and used the HINSTANCE passed to it from the
o/s.

Thanks for the suggestions though, they might come in handy at a later
date.

--
Ritchie