If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

run program in dll mode (if that is the right concept)

I have a program that I would like to be able to call from other programs and pass data between the two programs though memory (meaning not file based). The program being called (calledApp.exe) is in cpp, and I would like the other end (callingApp.exe) to be flexible, meaning that there would be appropriate abstractions to allow callingApp.exe to be in cpp, java, browser based, etc. In short, I would like to make my program a tool that can be called by other programs at runtime, not an API to include at link time.

I think that one way to do this would be to have calledApp.exe be some kind of dll, but I don't really know enough about this to even think about the problem properly. Can some one point me to a good reference that would give me the basics for the possible ways things like this can work? Some sample code for simple programs would be great as well. The data would probably be passed between the apps using pipes or shared memory, but I know java has things like stream, etc, so that part of the code may be abstracted as well.

This also will need to run under windows xp, win7, linux, and OSX, so that is another consideration as well.

I know this is a very open ended question, so I appreciate you patience. I will be able to ask better questions once I get a bit further into this.

Re: run program in dll mode (if that is the right concept)

This is a very common issue, and key if you want to write extremely modularized programs.

Look up the functions dlopen, dlsync, and dlclose. Windows has their own functiotns called OpenLibrary, GetProcAddress, and FreeLibrary.

Then you define the interface with extern "C" and the compiler will do the rest for you. You can load a dll, grab its functions, and call them with function pointers.

The only caveat is that if you allocate memory in the library, the library must be the thing that frees it.

Thanks, that's a bit help. I will probably make generic functions (open_lib, sync_lib, close_lib) and abstract the OS specific functions in those. Is there a standard for passing data between the calling program and the library? I have done some IPC with pipes and shmem, and that isn't too bad, but I was wondering if there were specific method for use with dlls. I suppose that would depend some on the language that the calling app is written in, meaning that a java app might pass and receive data from a dll differently than a cpp app.

Re: run program in dll mode (if that is the right concept)

I suppose that would depend some on the language that the calling app is written in, meaning that a java app might pass and receive data from a dll differently than a cpp app.

No, there is no difference between how different languages will communicate with a DLL. All languages that have the ability to call external DLL functions do exactly the same thing when calling the function. For example, there is no "C" way to call DLL functions as opposed to a VB way of calling those same DLL's functions. Yes, the syntax of how you set up the DLL calls are done differently in those languages, but ultimately both languages wind up doing exactly the same thing. The DLL knows nothing about the language that is accessing its external functions.

The trick to how this works is that the DLL accepts parameters and returns values using universally known types. For Windows, those types are things such as DWORD, BOOL, LPCTSTR, TCHAR, LONG, etc. and pointers to these types. If you look at the Windows API functions, you will see that practically every function that takes parameters or return values uses these types. If a DLL sticks to these types, then any language can use the DLL.

Re: run program in dll mode (if that is the right concept)

Originally Posted by Paul McKenzie

No, there is no difference between how different languages will communicate with a DLL. All languages that have the ability to call external DLL functions do exactly the same thing when calling the function. For example, there is no "C" way to call DLL functions as opposed to a VB way of calling those same DLL's functions. Yes, the syntax of how you set up the DLL calls are done differently in those languages, but ultimately both languages wind up doing exactly the same thing. The DLL knows nothing about the language that is accessing its external functions.

The trick to how this works is that the DLL accepts parameters and returns values using universally known types. For Windows, those types are things such as DWORD, BOOL, LPCTSTR, TCHAR, LONG, etc. and pointers to these types. If you look at the Windows API functions, you will see that practically every function that takes parameters or return values uses these types. If a DLL sticks to these types, then any language can use the DLL.

Regards,

Paul McKenzie

Thanks Paul, this has been helpful. Now I need to make up a simple dll and play around with the calling code. The amount of data being passed back and forth is not small. I would expect the calling code to pass ~1MB to the dll and the dll to return ~3MB. This is something I can adjust, but it would be helpful to be able to keep it as it (more or less). The calling code passes something like string or char* and the dll will mostly return float, along with some string. It looks as if there are a variety of int and char types, are there also float types?

Re: run program in dll mode (if that is the right concept)

The calling code passes something like string or char* and the dll will mostly return float, along with some string.

You need to be careful about this. There are certain methods that are used to pass and return string data to and from a DLL.

One thing you don't want to do is have the DLL dynamically allocate string data using C/C++ library functions, and hoping that the application deallocates the data. This won't work for obvious reason, the most obvious reason being that the caller program has no idea how to deallocate the data (was the data allocated new? new[]? malloc()?), let alone that it may not even be a 'C' or C++ program calling the DLL (so malloc(), new, new[] doesn't even exist).

The only exception to this rule is if the DLL uses a function such as GlobalAlloc(), HeapAlloc(), or any OS-specific memory allocation function that all languages has access to, then the deallocation is done by calling the OS-specific function.

I always have persons look at the string-related Windows API functions to see the sure-fire way of dealing with string data properly. One way is that the caller provide the string buffer to fill in instead of the DLL attempting to create strings. The other way is that the DLL implements a "mini-API", where the caller has to use exported functions from the DLL to create, manipulate, and destroy the data.

As to float -- the usual 8 byte IEEE doubles should work. There was an issue a while back concerning differences when returning floats when using different C++ compilers (I think it was Borland's C++ compiler compared to Visual C++), but again, that was a long time ago and I don't think it's an issue now.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.