Visual C++ to Borland C++ data exchange

Hello,

I'm working on a project that involves making two dlls: one of them is in Borland C++ (file1-bc.dll), the other one is in Visual C++ (file2-vc.dll). Right now I'm prototyping and trying to make them as simple as possible and to see data being exchanged from one side to another. The working scenario is as follows: file2.dll uses LoadLibrary("file1-bc.dll") and FindProcAddress to invoke methods to obtain data from file1-bc.dll.

Came to the point of loading a set of information; using a std::list seemed like a good idea. Although both projects are compiling and linking ok, when I try to use on one side a list created on the other side; the program crashes (Access Violation).

Scenario 1
I tried instantiating the list on file2-vc.dll and passing it as an argument to be filled in the other dll: at the very first attempt of using it inside file1-bc.dll the program crashes

Scenario2
I tried instantiating the list inside file1-bc.dll and returning it to the caller: still got a crash


The list is filled with pointers to a custom defined structure (see the attached SavedUrlItem.h). So it's a std::list<SavedUrlItem*>




And here are my questions:
- can this approach work?
- if yes what would need to change (perhaps in the project settings) to make it work


Thank you,
Marius

Here's the content of the SavedUrlItem.h file:

struct SavedUrlItem {
char url[2048];
char profile[256];
char name[128];
char value[512];
int indexInPage;

char designation;
char type;
};

Marius,

Getting C++ to work from a DLL share is tricky at best. If I were you, I would make the entire interface between the DLL and your main App straight C. You can use C++ inside the DLL and inside the App, but communicate only by C. The reason for this is that there is no name mashing and a pointer is just a pointer. (Convert the std to a normal WCHAR array.)

Otherwise, make sure you are using shared libraries, passing a class pointer without a shared reference will not make any sense to the DLL or App.

Thanks for the reply; I don't know exactly what you are meaning by straight C.

Would this mean only exchange data through plain structures? How would I deal with the situation when I need to populate a structure with a variable number of elements?

Also the Visual project doesn't make use of MFC... (i've seen there Use MFC in shared dll)

Which of the project settings would make the project using shared libraries?


I was able to make a successful test if the caller and dll are both in Borland C++

Quote:

---

Originally Posted by Galois77

... I don't know exactly what you are meaning by straight C.

Would this mean only exchange data through plain structures? How would I deal with the situation when I need to populate a structure with a variable number of elements?

---

You pass the head of the linked list.

The problem is that when you pass a class, the DLL and the App don't necessarily match. If you are passing a normal memory pointer, it works great.

Quote:

---

Originally Posted by Galois77

Also the Visual project doesn't make use of MFC... (i've seen there Use MFC in shared dll)

---

What does MFC have to do with anything?

Quote:

---

Originally Posted by Galois77

Which of the project settings would make the project using shared libraries?

---

Look under General Settings. There is (it changes from VC version to version) something like "Use Shared C Libraries".

Quote:

---

Originally Posted by Galois77

I was able to make a successful test if the caller and dll are both in Borland C++

---

That just proves my point about mis-matched C++ classes.

Quote:

---

Originally Posted by Galois77

Hello,

I'm working on a project that involves making two dlls: one of them is in Borland C++ (file1-bc.dll), the other one is in Visual C++ (file2-vc.dll). Right now I'm prototyping and trying to make them as simple as possible and to see data being exchanged from one side to another.

---

No. This is not going to work.

Code:

---

using a std::list seemed like a good idea. Although both projects are compiling and linking ok, when I try to use on one side a list created on the other side; the program crashes (Access Violation).

---

Hmm... I didn't know that the Borland C++ development team and Microsoft's C++ development team spoke to each other and shared their C++ library code.

Of course I'm being sarcastic -- the point I'm making is that std::list internals are different for each compiler -- the only thing that is the same is the public interface. So basically, the two std::list's are vastly different. You cannot "share" std::list between the two compilers. Even with the different compiler versions of the same compiler, you can't use std::list between compiler versions.

The proper way to share data is to not use C++, as egawtry mentioned. The only "universal" interface between DLL and application is to use 'C', and only the basic Windows types (LONG, WPARAM, LPCSTR, BOOL, char, etc. pointers to these types, arrays of these types, etc.). Anyway, I believe in the long run this is the better approach -- what if the container is no longer std::list, but something else? Your application and your DLL would have to change to the new type. By using generic Windows types, you are not forcing the app to know what data structure is being used.

Regards,

Paul McKenzie

Thanks Paul, you explained it much better than I did. :)

-Erik

Hello there,

Thank you for the ideas you provided.

As mentioned, the only thing std::list shared between the two languages is the interface. The pointer sent from one side to the other made no sense on the other end.

I was able to find a solution to my problem involving a variable number of elements by using a simple pattern similar to iteration over a list of found files.

bool findFirstItem(void* pItem);
bool findNextItem(void* pItem);

The address is sent from the Calling App and the dll only copies information to the supplied pointer. Inside it will keep track if there are more results and when the last result is returned, the internal list entities will be freed.


All the best,
Marius