Re: Multiple instances of a single DLL


comment inline---

"Serge Wautier" <serge@xxxxxxxxxxxxxxxxxx> wrote in message
news:Ou5tHiYTIHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
Hi Ben,

Thanks for your reply.

Yes, I do have the source code. But moving everything to a common struct
is something I'd rather avoid. That would take too much time. Let's not
even talk about the possible bugs I would introduce.

I'd rather go the separate processes way then.


<quote>

Short story : How can I load a DLL several times in a process? I need to
have multiple copies of the DLL data loaded simultaneously (there will be
one thread acting on each copy).

I thought of simply duplicating the Dll file using different names
(dll1.dll, dll2.dll,.). But it doesn't look very elegant. And I'll need a
few thousands of these copies.

<unquote>

So we have moved from one process hosting a few thousand dll's (and threads)
to a a few thousand processes each hosting one dll???? IMHO, either choice
will be a trainwreck in progress..... Have another look at David L's alarm
bells comment.

Mikep



FYI, another suggestion was to trick the loader by creating hardlinks to
the dll and load instances of it using each hardlink.

Regards,

Serge.
http://www.apptranslator.com - Localization tool for your MFC applications


"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message
news:OTNwi8XTIHA.1164@xxxxxxxxxxxxxxxxxxxxxxx

"Serge Wautier" <serge@xxxxxxxxxxxxxxxxxx> wrote in message
news:%23c9yN5GTIHA.5288@xxxxxxxxxxxxxxxxxxxxxxx
Stefan, Nikolaos,

Thanks for your replies.

Yes, my dll contains global data, which is the root of my problem.
Sorry, I should have been more specific about it.

I initially ruled out TLS for a reason that I now realize was stupid.
I'll investigate that route.

Do you have the DLL source code? If so, eliminate your global variables
by moving them into a "context" struct which the caller must provide.

If you don't have the DLL source code, then you basically will require a
separate process to host each instance of the DLL, it's the only way
(short of creating a custom loader that processes fixups) for the data
addresses placed in the code by the compiler to refer to different
instances, because each process gets its own page table. TLS wouldn't
help you.

I don't think TLS is appropriate for your problem. Sounds reminiscent of
"When all you have is a hammer everything looks like a nail".




.

Relevant Pages

  • Re: how not to expose source code
    ... it's rather easy to take a dll and pop it into full source code ... the salamagar tool even goes as far as ... Compiled dlls have MSIL code but not the real source code. ... The code would compile to a ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: how not to expose source code
    ... I looked at my dll with a hex viewer. ... Compiled dlls have MSIL code but not the real source code. ... The code would compile to a ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: how not to expose source code
    ... Compiled dlls have MSIL code but not the real source code. ... dll and could not be viewed when used in a vs.net project. ... The code would compile to a ... separate dll and could not be viewed when used in a vs.net project. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: how not to expose source code
    ... Blog: http://www.msmvps.com/blogs/alvin ... Compiled dlls have MSIL code but not the real source code. ... dll and could not be viewed when used in a vs.net project. ... The code would compile to a ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: where to find bin, include and lib directories in tcl8.0 version source code
    ... >1) so i went to tcl website and downloaded the tcl 8.0.5 version and ... >somewhere and gave the path and so i generated the dll file. ... >directory at all in the tcl8.0 version source code. ... i have used this link to download ...
    (comp.lang.tcl)