   DLL - host communication
  Is it possible to somehow retrieve information from the host application within a dll?   
  Maybe.What exactly are you trying to accomplish?   ;  I've a program which Im trying to build a plugin-framework for. Its supposed to work with .dll files. I can load the dll file from my program,now I want to send a string from the program to the dll file. (and likewise retrieve information from the host).  So far I can send a string to the dll file (using a function call within the dll). But not send data backwards.;  The DLL and Host process reside in the same address space - so you should simply be able to pass pointers back and forth between them.  However they may be using different heaps/free stores so you cannot deallocate memory in a dll that is allocated in the host or any other such combination.This means that passing SC++L objects accross DLL boundaries can cause problems - is this what you are trying to do?Unfortunately I don't know how to resolve such issue - though someone else here almost certainly does.   ;Quote:Original post by attahollanderI've a program which Im trying to build a plugin-framework for. Its supposed to work with .dll files. I can load the dll file from my program,now I want to send a string from the program to the dll file. (and likewise retrieve information from the host).  So far I can send a string to the dll file (using a function call within the dll). But not send data backwards.DLL can never discover who's using it (in a reasonable manner).So you'll need to pass it some context (a pointer, a structure, raw bytes) that allow your DLL to access whatever host application provides.But as mentioned, be wary of changing data. For SC++L classes (strings are one of those), passing them as const might work, although const char * might be a better idea in this case.Generally, plugin systems work one way only. When you load a plug-in, you provide it with application data that remains valid until plug-in shuts down. But plug-ins generally cannot query their hosts, since then they are no longer plug-ins, but usually components, and act as equivalents to host application (which no longer exists as such).;  The good way:// Some header file shared between the DLL and EXE:class IHost{public:   IHost() {}   virtual ~IHost() {}   virtual void SomeFunc() = 0;   virtual HWND GetMainWindow() = 0;   // Etc};// Header file only in the EXE:class Host : public IHost{public:   Host();   virtual ~Host();   virtual void SomeFunc();   virtual HWND GetMainWindow();   // Etc};// Provide implementation of Host class in a file in the EXE// Assume this function is exported from the DLL:void DoThings(IHost* pHost);// Call the DLL function, passing a Host class, to allow it to communicate with usHost* pThis = new Host;DoThings(pThis); // This would probably be called via a function pointerdelete pThis;The bad:// In an EXE source file:extern "C" {   __declspec(dllexport) void SomeHostFunction();}// In DLL:typedef void (*LPSomeHostFunction)();HMODULE hParentProcess = GetModuleHandle(NULL);LPSomeHostFunction pfn = GetProcAddress(hParentProcess, "SomeHostFunction");pfn(); // Call the host functionThe "good" way has the host application passing a class to the DLL that the DLL can use to communicate with the host application. It's a pure virtual interface, and the host provides the implementation; that stops the DLL from needing to know all the details of the host class.The "bad" way abuses the fact that GetModuleHandle(NULL) always returns the handle to the EXE, and that EXEs can export function too. It just uses GetProcAddress to get the address of some function in the EXE, then calls it.   ;  Thanks, I got it all working now. I wrote 2 plugins today :)In unix system ".so" files are equivalent for dll?   ;Quote:Original post by attahollanderThanks, I got it all working now. I wrote 2 plugins today :)In unix system ".so" files are equivalent for dll?Generally speaking, yes, that is the traditional file extension for a "shared object" library in unix.  Although, just like in Windows, the behavior is determined more by the contents of the file than by its name.  (For instance, Windows has OCX files, which are just DLLs with a different extension and there is no extension concept generally in unix at all, in particular the convention for executables is that they don't have any suffix.)   