C / C++ / MFC

Re: UnmanagedToManaged Bridge called from unmanaged DLL

14-Dec-06 8:25

[^]

After reading the link above I created a Bridge to be able to call a .NET
assembly and it worked with a unmanged tesp app. But when I try to use the bridge via an Unmanaged dll the dll will not load giving the error loadLibrary(): "Invalid access to memory location". What do I need to do to make this bridge work with my DLL as it works w/ my test app.

Jose Viveiros

Jose Viveiros

George L. Jackson14-Dec-06 8:42

George L. Jackson

14-Dec-06 8:42

Please don't cross post.

"We make a living by what we get, we make a life by what we give." --Winston Churchill

Re: UnmanagedToManaged Bridge called from unmanaged DLL

Jose Viveiros14-Dec-06 9:06

Re: UnmanagedToManaged Bridge called from unmanaged DLL

14-Dec-06 9:06

Hi,

I had posted this question under Managed C++/CLI and I got sent here by the manager. Because this is a unmanaged to managed call I do not know where to go ?

Thanks Jose

George L. Jackson14-Dec-06 11:18

George L. Jackson

14-Dec-06 11:18

You referenced an article here at Code Project. There is a section below the article to ask the author questions. You might get a reply there.

"We make a living by what we get, we make a life by what we give." --Winston Churchill

Re: UnmanagedToManaged Bridge called from unmanaged DLL

Mark Salsbery14-Dec-06 12:19

Re: UnmanagedToManaged Bridge called from unmanaged DLL

14-Dec-06 12:19

Is the DLL an MFC extension DLL?

Jose Viveiros15-Dec-06 3:43

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 3:43

Hi,
this Unmanaged DLL is not MFC but some of the applications that will use the DLL could be MFC but in this particular test I was using a Console application. The DLL does us some MessageBox() calls.

Jose Viveiros

Mark Salsbery15-Dec-06 5:05

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 5:05

Ok, just so I have this right....The DLL is unmanaged. If the app is unmanaged then LoadLibrary
works but if the app is managed then LoadLibrary fails?

Jose Viveiros15-Dec-06 5:18

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 5:18

Hi Mark,

No that, Here is the list of modules that work and the list
that does not work.

works works DoesNot work
------------- ------------- -------------
Unmanaged App Unmanaged App Unmanaged App
| | |
UnMng2Mng Bridge Unmanaged Dll Unmanaged Dll
| |
Assembly DLL UnMng2Mng Bridge
|
Assembly DLL

Jose Viveiros

Jose Viveiros15-Dec-06 5:24

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 5:24

Hi Mark,

Let me try again (as my last email colapsed some spaces)
works:
Unmanaged App -> UnMng2Mng Bridge -> Assembly DLL

works:
Unmanaged App -> Unmanaged Dll

DoesNot works:
Unmanaged App -> Unmanaged Dll -> UnMng2Mng Bridge -> Assembly DLL

Mark Salsbery15-Dec-06 6:05

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 6:05

Ok got it, thanks. And what is failing and where? LoadLibrary on the bridge DLL?

Jose Viveiros15-Dec-06 6:21

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 6:21

LoadLibrary( ) is failing to load the Unmanaged DLL if that DLL links to the unManged2Manged Bridge.
What is strange is that the Brige loads fine if it is loaded directly from the Unmanaged app but it causes problem if you try to use it with a unmanged Dll in between ????

Jose Viveiros

Mark Salsbery15-Dec-06 6:33

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 6:33

Jose Viveiros wrote:
...if that DLL links to the unManged2Manged Bridge.

How is this "link" done? Through an import library or explicitly with LoadLibrary?
If LoadLibrary, then where are you calling that from in the unmanaged DLL?

Jose Viveiros15-Dec-06 6:48

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 6:48

hum !
The link between the unmanaged Dll & the Bridge is not done via loadLibrary.
I link in the Bridge.lib and include bridge.h. Is this a problem?

The link between the App & the unmanged Dll does use loadLibrary

Thanks Jose

Jose Viveiros

Mark Salsbery15-Dec-06 7:41

Re: UnmanagedToManaged Bridge called from unmanaged DLL

15-Dec-06 7:41

Jose Viveiros wrote:
I link in the Bridge.lib and include bridge.h. Is this a problem?

Hmm no, it shouldn't be. Calling LoadLibrary from DllMain is a problem - that's why I asked.

1) works:
Unmanaged App -> UnMng2Mng Bridge -> Assembly DLL
2) works:
Unmanaged App -> Unmanaged Dll
3) DoesNot works:
Unmanaged App -> Unmanaged Dll -> UnMng2Mng Bridge -> Assembly DLL

So using method 1 above, you linked using Bridge.lib, correct? If that worked then I would
expect method 3 to work.

Are you doing anything with entry code in your DLLs (DllMain)??

I had problems once with mixed MFC and managed/unmanaged DLLs and found the following article to
be helpful. Although the topic of the article doesn't match the problem, the "Resolution" section
has great info on how to initialize the C runtime (CRT) if you're using it in your DLLs...
You receive linker warnings when you build Managed Extensions for C++ DLL projects[^]

This article has interesting info as well, although it probably doesn't apply to the problem you
are having: Mixed DLL Loading Problem[^]

Jose Viveiros15-Dec-06 8:36

15-Dec-06 8:36

Hi Mark,
Yes I was also expecting that if method 1 worked method 3 would too. I will check the two articles you send me and I'll let you know if they help me thanks for your help.

Memory management

BlitzPackage14-Dec-06 7:54

BlitzPackage

14-Dec-06 7:54

Greetings,

Let's say I do this:

vector<cmyclass *=""> m_vMyVector;

void SomeFunction(CString strID, bool bStatus)
{
CMyClass * pMyObj = new CMyClass(strID, bStatus);
m_vMyVector.push_back(pMyObj);
pMyObj = NULL;
}

Let's say SomeFunction(...) is in a loop and I create several of these objects. When I call m_vMyVector.clear() will there be a memory leak? In essence, I want to know if I have to go back and call delete on each of the elements in m_vMyVector or will the memory be freed once I call the vector's "clear" method or once the vector is destroyed when the class containing it is destroyed. Also, once I add pMyObj to the vector and reassign the one in the function to point to null, the vector still retains its own valid pointers to the objects in memory, correct?

Thanks for any help or insight you can provide.

Sincerely,
BP

Maximilien14-Dec-06 8:12

Maximilien

14-Dec-06 8:12

You will need to loop the vector to delete each item individually, unless you are using auto_ptr thingies.

/// pseudo code.
it = m_vMyVetor.begin();
while (it!= m_vMyVector.end() )
{
 delete *it;
 ++it;
}
m_vMyVector.clear();

and you are correct about the second thing, IMO, assign it back to NULL is not necessary, but a nice touch.

Maximilien Lincourt
Your Head A Splode - Strong Bad

BlitzPackage14-Dec-06 8:15

BlitzPackage

14-Dec-06 8:15

Thanks,

I appreciate your response.

BP

peterchen14-Dec-06 13:11

peterchen

14-Dec-06 13:11

Hi,

It's not safe to use auto_ptr in a standard container (reference: see e.g. here[^], here[^]

But generally, smart pointers is the way to go. (only auto_ptr is a troubled implementation)

I've written an article about the smart pointer library included with boost - Clickety[^]. That might give you some ideas.

Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!

peterchen14-Dec-06 13:12

peterchen

14-Dec-06 13:12

Maximilien wrote:
auto_pt

do me a favor, never use auto_ptr Wink | ;)

BlitzPackage14-Dec-06 13:31

BlitzPackage

14-Dec-06 13:31

Thanks PeterChen,

I have heard a lot of great things about boost. Being new to programming, it seems a bit intimidating to use and I am admittedly frightened at the prospect of including it then having to deal with Visual Studio 2003 not playing nice with it. Is boost easy to use?

At any rate, I'll check out your article.

Peace,
BP

peterchen14-Dec-06 14:31

peterchen

14-Dec-06 14:31

boost can certainly be intimidating. It is a collection of many different libraries, and some of them are clearly made for advanced program(mer)s.

The smart pointers are an exception. They are (IMO) a very important concept, maybe the first step away from beginner towards advanced programming. They should be easy to understand if you have mastered basic memory management and RAII (using constructors and destructors to acquire and release resources like memory, file handles, ...). I also tried to make the article suitable for beginners (if you read it, please tell me if it works for you Wink | ;)

)

I've been using them with VC6 and VC8, so VC2003 should be no problem. But if boost is still to intimidating, there are many other smart pointer implementations. I recommend boost because they are well designed, flexible, but still fairly simple (a good balance).