C / C++ / MFC

Why DllMain is not be called when I load the DLL file?

8-Apr-09 12:46

Do you mean when you use CString::Format? I'd do it like this:

CString a;
double d = 5.0000;
a.Format("%d", (int)d);

i.e. cast it to an int and treat as an int.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

ernst200205308-Apr-09 9:16

ernst20020530

8-Apr-09 9:16

// DLL10.cpp : Defines the exported functions for the DLL application.
//

#include "stdafx.h"
#include "DLL10.h"

static HHOOK hHook = NULL;

static HINSTANCE hInst;

BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
hInst = hModule;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

// This is an example of an exported variable
DLL10_API int nDLL10=0;

// This is an example of an exported function.
DLL10_API int fnDLL10(void)
{
return 42;
}

// This is the constructor of a class that has been exported.
// see DLL10.h for the class definition
CDLL10::CDLL10()
{
return;
}

int getNumber()
{
return 1;
}

This is my DLL file, and When I load the file, DLLMain is not called?

Re: Why DllMain is not be called when I load the DLL file?

Stuart Dootson8-Apr-09 9:22

Re: Why DllMain is not be called when I load the DLL file?

8-Apr-09 9:22

How have you verified that DllMain isn't called?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

CPallini8-Apr-09 10:12

CPallini

8-Apr-09 10:12

Possibly he didn't hear the call... Roll eyes | :rolleyes:

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Re: Why DllMain is not be called when I load the DLL file?

ernst200205308-Apr-09 12:37

ernst20020530

8-Apr-09 12:37

I set printf() in DllMain, but didn't show the result
and I set break point int DllMain.

Re: Why DllMain is not be called when I load the DLL file?

Stuart Dootson8-Apr-09 13:22

Detecting Windows SDK version using macros

8-Apr-09 13:22

ernst20020530 wrote:
I set printf() in DllMain, but didn't show the result

Not a surprise

ernst20020530 wrote:
I set break point int DllMain.

I presume you had a separate executable to run that referenced that DLL?

When I did that with your DLL code, I was able to break in the DllMain. I used this as the code for my executable:

int _tmain(int argc, _TCHAR* argv[])
{
   LoadLibrary(_T("dll-name"));
   return 0;
}

where dll-name is the name of the DLL I built.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

tareqsiraj8-Apr-09 7:01

8-Apr-09 7:01

Hi there,
I was wondering if there is any standard way to detect which version of Windows SDK is installed using macros. SDK 6.1 defines some function signatures a bit differently than the Platform SDK that ships with VC++ 2005. If there is such a trick, I was thinking of using the new function signature for the newer SDKs while still letting the the people without the windows sdk 6.1 compile. Or, is there a better way to handle this situation? Thanks in advance.

--
Regards,
- Tareq

Stuart Dootson8-Apr-09 8:38

8-Apr-09 8:38

tareqsiraj wrote:
SDK 6.1 defines some function signatures a bit differently than the Platform SDK that ships with VC++ 2005

You mean the extra bits on parameters, like in this definition of CoInitializeEx?

WINOLEAPI  CoInitializeEx(__in_opt LPVOID pvReserved, __in DWORD dwCoInit);

They don't make any difference to the compiler - they're just macros that expand to nothing unless you're using Prefast[^].

Just #include things and don't worry about them.

tareqsiraj wrote:
If there is such a trick, I was thinking of using the new function signature for the newer SDKs while still letting the the people without the windows sdk 6.1 compile

Not entirely sure what you mean there - as I said, just use the SDK headers and don't worry about what version they are unless they're too old for the version of Windows you're targeting and don't contain the functions you need.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

tareqsiraj8-Apr-09 9:00

8-Apr-09 9:00

Umm... thats not what I meant. For example, the dbghelp.h that ships with VS2005's PSDK uses PSTR for the first param of PENUMLOADED_MODULES_CALLBACK64 while the dbghelp.h that ships with SDK6.1 uses PCSTR. Now, I want both who does and doesn't have SDK6.1 to be able to compile the app. Hopefully this makes things a bit clear.

--
Regards,
-Tareq

Stuart Dootson8-Apr-09 9:20

8-Apr-09 9:20

Ah, right - hadn't noticed that before. Not quite as obvious as all the __in things on function parameters Smile | :)

Now, looking at the SDK headers (v6.0A), they use the macro CONST to add const-ness to SDK parameter specs.

So, you could do something like:

#include <Windows.h>
#ifndef CONST
#define CONST
#endif

and then use CONST instead of const?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

tareqsiraj8-Apr-09 9:53

8-Apr-09 9:53

Thanks for spending some time on this... unfortunately, the PSDK that comes with VC++2005 does the same with CONST. So it will have the same effect regardless of SDK6.0+.

-Tareq

Randor 9-Apr-09 1:12

Randor

9-Apr-09 1:12

Hello,

I use the following to detect the version of Platform SDK/Windows SDK.

#include "ntverp.h"
#if !defined(VER_PRODUCTBUILD) ||  VER_PRODUCTBUILD < 3790
	#pragma message ("********************************************" 
	#pragma message ("Error: You need the latest Microsoft Platform SDK to compile this project.")
	#pragma message ("********************************************" 
#endif

There are other constants defined in the header which may be of use to you. I believe my preprocessor directives above simply check that VER_PRODUCTBUILD is at minimum Platform SDK for Microsoft Windows Server 2003. There is another constant VER_PRODUCTBUILD_QFE which I *think* can determine patches and service packs.

Best Wishes,
-David Delaune

tareqsiraj9-Apr-09 7:35

9-Apr-09 7:35

ah... just what I was looking for. Thanks Smile | :)

-Tareq

New Thread and WM_QUIT

TheScientistIsDead8-Apr-09 7:00

TheScientistIsDead

8-Apr-09 7:00

I don't like how, in a Windows environment, upon resetting the focus on a minimized window or having the window perform some other complex operation, the thread may stall (temporarily hang, not translating any messages). What if I want to break these operations?

Isn't it possible to spawn a new thread at initialization that either:
1)Solely searches the message queue for WM_QUIT and sets a global flag when triggered. Somehow, before performing any resource and time intensive operations (that might cause a small hang), any function calls check for the flag and break if it is present.

2)Or maybe have the entire message pump in the new thread, as a busy program isn't even able to receive messages while performing operations.

I think the biggest problems would be:
1)Having a separate thread pump messages from the parent
2)Figuring out how to break operations when the WM_QUIT flag (which was set in another thread) is set

Any input, tips, thoughts, examples that might help me?
Thanks, The Scientist.

Stuart Dootson8-Apr-09 8:29

8-Apr-09 8:29

It's a good idea - but you've got the conclusion backwards. You put the busy work in a different thread, leave the main (UI) thread alone. Look up worker threads[^].

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

TheScientistIsDead8-Apr-09 16:44

TheScientistIsDead

8-Apr-09 16:44

I'm a little new to multi-threading.

Isn't there an issue regarding threads and access to process-wide variables/data?
Will I be able to kill a thread, while its in the middle of doing some kind of processing, from the main thread? And can I change the flag's status (if quit is posted after I initialize the new thread)?

Stuart Dootson8-Apr-09 20:10

8-Apr-09 20:10

TheScientistIsDead wrote:
Isn't there an issue regarding threads and access to process-wide variables/data

Oh yeah - you've got to be very careful. The general rule is that you read things like ints (i.e. 4 bytes or less) without synchronisation, but everything else needs to be synchronised, really.

TheScientistIsDead wrote:
Will I be able to kill a thread, while its in the middle of doing some kind of processing, from the main thread?

There is TerminateThread[^], but its use is discouraged.

TheScientistIsDead wrote:
And can I change the flag's status (if quit is posted after I initialize the new thread)

Yes. In your WM_QUIT handler, I'd do something like this:

// we have a thread handle, hThread and a shared LONG variable lQuit which is zero until it's time to quit
InterlockedExchange(&lQuit, 1);
::WaitForSingleObject(hThread, INFINITE);

and in the worker thread function:

// do stuff
if (lQuit) ExitThread(0);
// do some more stuff
if (lQuit) ExitThread(0);

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p