DLL basic question
-
When I export a class in a DLL, I'm not actually dealing with dllmain or those DLL_PROCESS_ATTACH , DETACH thing. I just simply export it as a class. Then how things work without implementing these?
grassrootkit wrote:
Then how things work without implementing these?
That depends. If, for example, your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. All the COM calls would fail because that's how COM works. So it depends on what you are doing in your DLL. In other words all DLL's are not equal.
-
grassrootkit wrote:
Then how things work without implementing these?
That depends. If, for example, your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. All the COM calls would fail because that's how COM works. So it depends on what you are doing in your DLL. In other words all DLL's are not equal.
So it should concern us only if we are dealing with COM?
-
So it should concern us only if we are dealing with COM?
-
your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. You mean "if my DLL is a COM dll" and the hosting application not using COM?:confused: I'm really not able to follow you. Can you explain a bit more without taking out the stick?
-
When I export a class in a DLL, I'm not actually dealing with dllmain or those DLL_PROCESS_ATTACH , DETACH thing. I just simply export it as a class. Then how things work without implementing these?
The functions are always called. But for a plain dll (not COM), you don't have to do anything in them. However, you could do some initialization and clean-up stuff but that's up to you.
Cédric Moonen Software developer
Charting control [v1.5] OpenGL game tutorial in C++ -
your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. You mean "if my DLL is a COM dll" and the hosting application not using COM?:confused: I'm really not able to follow you. Can you explain a bit more without taking out the stick?
grassrootkit wrote:
Can you explain a bit more
Um I already did explain more, maybe you missed those parts?
led mike wrote:
That depends.
led mike wrote:
If, for example, your DLL was using COM
led mike wrote:
because that's how COM works.
led mike wrote:
**
So it depends on what you are doing in your DLL.
**
led mike wrote:
In other words all DLL's are not equal.
By the way, that's not a stick, that's just quoting what I already posted.
-
led mike wrote:
Really? That's your interpretation of my post?
Wonderful. :-D
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] -
The functions are always called. But for a plain dll (not COM), you don't have to do anything in them. However, you could do some initialization and clean-up stuff but that's up to you.
Cédric Moonen Software developer
Charting control [v1.5] OpenGL game tutorial in C++Thanks! This is what I asked. Excellent. Straight forward & a neat reply.
modified on Wednesday, April 1, 2009 2:36 PM
-
grassrootkit wrote:
Can you explain a bit more
Um I already did explain more, maybe you missed those parts?
led mike wrote:
That depends.
led mike wrote:
If, for example, your DLL was using COM
led mike wrote:
because that's how COM works.
led mike wrote:
**
So it depends on what you are doing in your DLL.
**
led mike wrote:
In other words all DLL's are not equal.
By the way, that's not a stick, that's just quoting what I already posted.
led mike wrote:
In other words all DLL's are not equal.
I just asked I should take care of dllmain when I'm writing a simple C++ exported class. And you replied with reference to COM! That was little vague or may be I couldn't follow your language. That's why I asked the question again but anyway Cedric moonen got it quite right.
-
led mike wrote:
Really? That's your interpretation of my post?
Wonderful. :-D
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]CPallini wrote:
Wonderful.
Q:When I export a class in a DLL, I'm not actually dealing with dllmain or those DLL_PROCESS_ATTACH , DETACH thing. I just simply export it as a class. Then how things work without implementing these? A:That depends. If, for example, your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. All the COM calls would fail because that's how COM works. So it depends on what you are doing in your DLL. In other words all DLL's are not equal. Q:So it should concern us only if we are dealing with COM? *:Really? That's your interpretation of my post? What's there for you to wonder so much? Don't expect everybody to know everything. I haven't worked with COM. That's why I asked the question that way. I found his reply a bit rude. Now yours is a bit worse. If Cedric Moonen can get question my right why can't you?
-
grassrootkit wrote:
Then how things work without implementing these?
That depends. If, for example, your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. All the COM calls would fail because that's how COM works. So it depends on what you are doing in your DLL. In other words all DLL's are not equal.
So it should concern us only if we are dealing with COM? May be I should have rephrased that as: "We don't need to worry if we are just exporting a class."
-
CPallini wrote:
Wonderful.
Q:When I export a class in a DLL, I'm not actually dealing with dllmain or those DLL_PROCESS_ATTACH , DETACH thing. I just simply export it as a class. Then how things work without implementing these? A:That depends. If, for example, your DLL was using COM and your host wasn't, it wouldn't work if you didn't handle the thread attach event and initialize COM. All the COM calls would fail because that's how COM works. So it depends on what you are doing in your DLL. In other words all DLL's are not equal. Q:So it should concern us only if we are dealing with COM? *:Really? That's your interpretation of my post? What's there for you to wonder so much? Don't expect everybody to know everything. I haven't worked with COM. That's why I asked the question that way. I found his reply a bit rude. Now yours is a bit worse. If Cedric Moonen can get question my right why can't you?
He made an example, you didn't understand it was just an example. For a better understanding see [^]. :)
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] -
led mike wrote:
In other words all DLL's are not equal.
I just asked I should take care of dllmain when I'm writing a simple C++ exported class. And you replied with reference to COM! That was little vague or may be I couldn't follow your language. That's why I asked the question again but anyway Cedric moonen got it quite right.
grassrootkit wrote:
Cedric moonen got it quite right.
Cedric Moonen wrote:
But for a plain dll (not COM), you don't have to do anything in them
No, that is not correct. In a "not COM" DLL you don't have to initialize COM, but you may need to do something else, DEPENDING ON WHAT THE FRACK YOU ARE DOING IN YOUR DLL!!!! There is no way to make that point more clear. If you can't understand it, you should change careers. BTW, I find your refusal to read what I post in reply to your question, very rude. Therefore I don't give a rats ass what you think is rude. Get it? Got it? Good.
-
grassrootkit wrote:
Cedric moonen got it quite right.
Cedric Moonen wrote:
But for a plain dll (not COM), you don't have to do anything in them
No, that is not correct. In a "not COM" DLL you don't have to initialize COM, but you may need to do something else, DEPENDING ON WHAT THE FRACK YOU ARE DOING IN YOUR DLL!!!! There is no way to make that point more clear. If you can't understand it, you should change careers. BTW, I find your refusal to read what I post in reply to your question, very rude. Therefore I don't give a rats ass what you think is rude. Get it? Got it? Good.
-
Actually he was pretty nice today. Never heard about 'Terrible Led Mike' before? :)
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] -
grassrootkit wrote:
Cedric moonen got it quite right.
Cedric Moonen wrote:
But for a plain dll (not COM), you don't have to do anything in them
No, that is not correct. In a "not COM" DLL you don't have to initialize COM, but you may need to do something else, DEPENDING ON WHAT THE FRACK YOU ARE DOING IN YOUR DLL!!!! There is no way to make that point more clear. If you can't understand it, you should change careers. BTW, I find your refusal to read what I post in reply to your question, very rude. Therefore I don't give a rats ass what you think is rude. Get it? Got it? Good.
led mike wrote:
No, that is not correct. In a "not COM" DLL you don't have to initialize COM, but you may need to do something else, DEPENDING ON WHAT THE FRACK YOU ARE DOING IN YOUR DLL!!!!
That's what I was saying in my second sentence: you might want to initialize stuff depending on what your dll is doing :)
Cédric Moonen Software developer
Charting control [v1.5] OpenGL game tutorial in C++ -
led mike wrote:
No, that is not correct. In a "not COM" DLL you don't have to initialize COM, but you may need to do something else, DEPENDING ON WHAT THE FRACK YOU ARE DOING IN YOUR DLL!!!!
That's what I was saying in my second sentence: you might want to initialize stuff depending on what your dll is doing :)
Cédric Moonen Software developer
Charting control [v1.5] OpenGL game tutorial in C++I know that but the monkey can't seem to understand it. Changing subjects, the voting in this thread is a perfect example of how off it can be, my actual (and correct) answer to the question get's no votes but my post flaming someone else get's a '5' :laugh: :laugh: