C / C++ / MFC

Re: DllMain and its usage (Followup to a post by Jeremy Falcon)

31-Aug-06 8:46

In a recent post Jeremy Falcon[^] provided a link to a white paper about DLL best practices. Basically the paper outlined the does and don'ts of the DllMain function. One of the references cited in that paper is http://blogs.msdn.com/oldnewthing/archive/2004/01/27/63401.aspx[^] where the author says never create a window in response to DLL_PROCESS_ATTACH.

Now this brings up a question in my mind. I have a dll where I have declared a global class that calls the CreateWindow() API in it's constructor. While the window is technically not created in DllMain, it does get created every time the dll is loaded but before DllMain is called.

Everything seems to be working fine so far, but am I asking for trouble using this approach? Or is the fact the window is not created in DllMain mean that I am avoiding the locking issues mentioned in those papers? I guess my question can be summed up as: Is this a safe way to create global window objects in a dll?

Global class:

class CDllWindow
{
public:
    CDllWindow();
private:
    HWND DllWindow;
};

CDllWindow::CDllWindow()
{
    DllWindow = CreateWindow(...);
}

Dll cpp file:

#include "DllWindow.h"
CDllWindow DllWindow;     // Creates a window

BOOL APIENTRY DllMain(HMODULE, DWORD, LPVOID)
{
    return TRUE;
}

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

Zac Howland31-Aug-06 9:03

Re: DllMain and its usage (Followup to a post by Jeremy Falcon)

31-Aug-06 9:03

You are asking for trouble in 2 different ways here.

First, using operations like CreateWindow in your constructor is dangerous since if CreateWindow fails, you have not completed your construction of the object. It is safer to initialize any variables and have a separate Create function to create your window.

Second, Doing this as part of the static memory allocation for your Dll can cause problems if the DLL fails to load properly. Basically, the same arguments for not calling CreateWindow inside your DllMain apply to calling it before it gets called as well.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

PJ Arends31-Aug-06 9:19

Re: DllMain and its usage (Followup to a post by Jeremy Falcon)

31-Aug-06 9:19

Zac Howland wrote:
First, using operations like CreateWindow in your constructor is dangerous since if CreateWindow fails, you have not completed your construction of the object. It is safer to initialize any variables and have a separate Create function to create your window.

I disagree with you on that one. If CreateWindow fails the DllWindow member will be NULL, but the CDllWindow class object will still be successfully created.

Zac Howland wrote:
Doing this as part of the static memory allocation for your Dll can cause problems if the DLL fails to load properly. Basically, the same arguments for not calling CreateWindow inside your DllMain apply to calling it before it gets called as well.

That is what I was afraid of, but I was hoping it was not the case. Oh well, I guess I will have to think up a different method to do what I want.

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

PJ Arends31-Aug-06 9:33

Re: DllMain and its usage (Followup to a post by Jeremy Falcon)

31-Aug-06 9:33

Ok, taking your two points into consideration I think I have come up with a solution that should work. I still disagree with your first point on a general level, but in this instance a seperate Create function is just what I need.

Thanks for your input Smile | :)

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

Michael Dunn31-Aug-06 18:42

Michael Dunn

31-Aug-06 18:42

The rule is actually "Don't do anything dangerous while the loader lock is taken." This is usually shortened to "Don't do anything dangerous in DllMain()" because that version is more easily understood.
Your DllMain() is only one part of the module initialization. There is CRT code that runs before DllMain() (by default it's called DllMainCRTStartup() IIRC) that is responsible for constructing globals in the DLL. All that code runs while the loader lock is taken, so it must not do anything that would cause a deadlock.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

Re: DllMain and its usage (Followup to a post by Jeremy Falcon)

PJ Arends31-Aug-06 21:14

31-Aug-06 21:14

Thanks Mike Smile | :)

You may be right
I may be crazy
-- Billy Joel --

Within you lies the power for good, use it!!!

Heap corruption?!

Nader Elshehabi31-Aug-06 7:55

31-Aug-06 7:55

Hello

Looks like my C++ is getting really rusty. While playing a bit in a console project the following code gave me a strange heap corruption error.

#include <iostream>

using namespace std;

void main()
{
	char* MyText = new char;
	cin>>MyText;
	delete[] MyText;
}

It's not even an exception. Sometimes it says "Windows have set a breakpoint in your application because of a heap error." And a break point appears somewhere in the iostream file.

Other times, an ugly error message appears saying "HEAP CORRUPTION DETECTED after a normal block. CRT detected that application wrote to memory after end of heap buffer.",

Any clue??

Regards

Zac Howland31-Aug-06 8:15

31-Aug-06 8:15

Nader Elshehabi wrote:
char* MyText = new char;
cin>>MyText;
delete[] MyText;

new matches up with delete. new[] matches up with delete[]. Calling delete[] on something that was new'd will result in a heap corruption.

To fix the problem:

void main()
{
	char* MyText = new char;
	cin>>MyText;
	delete MyText;
}

void main()
{
	char* MyText = new char[100];
	cin>>MyText;
	delete [] MyText;
}

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Nader Elshehabi31-Aug-06 9:01

31-Aug-06 9:01

Hello
Thanks for replying.

Well, the first coder didn't work, while the second did. Yet, that makes a buffer of N chars. That's not what I want. What if the user inputs n+1 chars. I tried it and it made the same heap corruption error. Also what if I dynamically reallocate my array -or pointer-??

If you got more details or point me to some article about this issue, I'd be grateful.

Thanks again.

Regards

Zac Howland31-Aug-06 9:08

31-Aug-06 9:08

Nader Elshehabi wrote:
Well, the first coder didn't work, while the second did.

The first code has another problem due to the fact that cin's operator>> will pull in 2 characters even if you only typed 1 (the character you typed and a '\0' to terminate the string). If you are only trying to pull in 1 character, the cin.getc() would work better.

Nader Elshehabi wrote:
Yet, that makes a buffer of N chars. That's not what I want. What if the user inputs n+1 chars.

You will not be able to use the operator>> to do this (at least not yet ... as I said, the new proposal for the C++ standard has all overloaded operators that deal with char* now also overloaded for string). What you can do is iterate through it:

char ch;
string input;
while ((ch = cin.getc()) != '\n')
{
   input += ch;
}

That will prevent any possibility of a buffer overflow issue, but will also be VERY slow (in comparison to pulling down a whole set of data at once).

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Nader Elshehabi31-Aug-06 9:49

31-Aug-06 9:49

Hello

Thanks again for your reply! I got two more questions Big Grin | :-D

. Take a look at this code;

char* MyText = new char[5];
cin>>MyText;
MyText = new char[10];
delete[] MyText;

Now , I called a second new without deleting the first one. Is there a leak here??

What if I didn't call a delete at all!! Once my program finishes and closes. Will the memory be freed?
Or will it be permanently locked until reboot?

Regards

David Crow31-Aug-06 10:09

David Crow

31-Aug-06 10:09

Nader Elshehabi wrote:
Is there a leak here??

Yes.

Nader Elshehabi wrote:
Will the memory be freed?

Yes.

"Talent without discipline is like an octopus on roller skates. There's plenty of movement, but you never know if it's going to be forward, backwards, or sideways." - H. Jackson Brown, Jr.

"Judge not by the eye but by the heart." - Native American Proverb

Nader Elshehabi31-Aug-06 12:21

31-Aug-06 12:21

Hello

Short, and straight answers!!

Thanks Big Grin | :-D

Regards

Zac Howland31-Aug-06 10:20

31-Aug-06 10:20

Nader Elshehabi wrote:
Now , I called a second new without deleting the first one. Is there a leak here??

Are you coming from a Java/C# background by chance? Yes, this will result in a memory leak. Whenever you use new, you must have a delete call to match it. Having 2 calls to new and only 1 call to delete means here is a leak.

Nader Elshehabi wrote:
What if I didn't call a delete at all!! Once my program finishes and closes. Will the memory be freed?
Or will it be permanently locked until reboot?

When the program exits its memory will be freed. You do NOT want to rely on this, though. Always clean up your memory properly.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Nader Elshehabi31-Aug-06 12:29

31-Aug-06 12:29

Hello

Zac Howland wrote:
Are you coming from a Java/C# background by chance?

Well, somehow Smile | :)

! I was a good old timer C++ programmer Cry | :((

. But last time I ever wrote C++ code was more than 3 years ago. So I got really rusty, coming back these days to C++ as a new comer.

So, while refreshing all that good ol' C++ of mine, it's nice to have you guys around;)

Thanks again.

Extra Regards Rose | [Rose]

Stephen Hewitt31-Aug-06 14:10

Stephen Hewitt

31-Aug-06 14:10

That's code is a good the way to read a single line, try this instead:

getline(cin, input);

Steve

Zac Howland1-Sep-06 3:56

1-Sep-06 3:56

That still has the problem that he will need to limit his buffer size in order to prevent overrun problems. And the safer version is:

char buffer[100] = {0};
cin.getline(buffer, 99);

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac