Re: Dynamic linking with symbols


"Philip Lawatsch" <philip@xxxxxxx> wrote in message
news:jmgeu2xvmp.ln2@xxxxxxxxxx
> James Brown schrieb:
>
>>>I have an executable which dllexports a lot of stuff. And a dll which
>>>dllimports it (yes, _really_ this way around).
>>>
>>>The idea is that the dll is a plugin for my exe and thus can use all of
>>>the "symbols" inside my executable.
>>>
>>>Now the problem is that in this case the dll has to link against a
>>>specific executable which in turn makes sure I can't use the same dll in
>>>two different executables.
>>>
>>>Now I could put all the exported code from my executables into a dll and
>>>let my plugin dll and both of my executables link against this dll.
>
>>>Is there anything like this available on Windows?
>
>> I think I just had a brain-spasm reading this but I'll have a go..
>
> :)
>
>> Try putting your "exported code" into a static library which your
>> EXE links against. When you build your multiple exe(s), the linker will
>> include
>> this lib file and generate the exports appropriately - so you can get
>> more
>> than one executable exporting the same set of functions.
>
> Thats what I'm doing of course. But the dll can only import from the one
> it used the export stub from.
>
>> This doesn't provide an easy mechanism for the DLL to import
>> from this DLL though. The problem is that an import library for a DLL
>> (or EXE in this case) relies on knowing the name of the module that you
>> are importing from. So you really have to call your executables by
>> the same base-name otherwise it will be very hard to get working
>> (you will need custom build-steps and that kind of thing).
>
> I was afraid about that. Guess I'll use an addition dll for the exported
> functionality then.
>
>> Comment about the DLL importing from EXE:
>>
>> Personally I would do this differently. Pass a structure full
>> of function-pointers to the DLL (i.e. a bit like a COM interface) - do
>> this
>> when you first initialize the DLL. The DLL just needs to #include a
>> header
>> file which defines this structure and the function-prototypes. It can
>> then
>> call these functions in a portable manner and it doesn't matter *who*
>> passes this
>> structure - it could be a DLL, an EXE or something else.
>> Much easier to maintain/manage/design IMHO.
>
> Not at all. I've got several singeltons and stuff like that. My plugin
> simply registers some callbacks inside these singeltons. Thus I need to
> either pass all the singeltons pointers or pass function pointers to
> functions hooking the callbacks into the singeltons. Not very elegant imo.
>
> Since I'm working with OOP quite a lot I definitly would not want a plugin
> writer to use a c style interface (which you would have to use in your
> example). Plugins will have to work with objects created in my executable
> for instance. Writing c wrappers for these would be a pain.
>
> Imho exporting my core functionality either from the exe or an additional
> dll is the more elegant solution in my case.
>
> kind regards Philip

from what you've described I think your idea of the additional DLL would
be the neatest solution. This way you just make one single "server" DLL
which
can be used by all your exe's, and all your plugin DLLs as well - can't see
anything wrong with that - alot easier to code and you don't have to play
games that the compiler+linker don't like very much :-)

cheers,
James


--
www.catch22.net
Free win32 software, sourcecode and tutorials


.

Relevant Pages

  • Re: Plugins in C#
    ... Point taken though, I'll just stay with the extra DLL for now, it works ... make each plugin reference the main application project, ... since you can just copy the DLL with the interfaces in ... If it is in the same directory as the EXE, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Plugin Architecture Question - Best Practice For Forms Update
    ... DLL's used by an EXE don't run on a separate thread. ... class are held in a DLL that's used by your EXE. ... In cases where you use the more reliable timers you must ... > I have an application that follows a simple plugin architecture. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Cannot activate sbcl
    ... but I think what happens is that Windows sees that your executable has a DATA section that might overlap a DLL's address space then it would reallocate that DLL to different address space. ... VirtualAlloc dynamically in your code is that your program and all its ... What can be done here is to have many tiny executables with different BSS sections in them, which then load a bigger executable in the form of a DLL. ...
    (comp.lang.lisp)
  • Tracking down the process that owns a window
    ... My company makes a DLL that acts as a plugin to another product (an EXE). ... While interacting with that product, a message box pops up with the name of ...
    (microsoft.public.vc.mfc)
  • Re: Why do we need executables in certain formats ?
    ... > Can anybody explain me why do we need executables in certain formats? ... Modern virtual memory processors can locate to ... ..DLL files changed out from under them, ...
    (comp.lang.asm.x86)