回复： Re: is there anyway to open multiple instances of a dll?

[test_man]

I have a dll in which controls an instrument. I need to communicate to multiple instruments with this dll. This dll only supports 1 instrument at a time. Is there anyway to load multiple instances of this dll and call same functions from each dll instance for different instrument.

[OZI]

Hi,
just to be sure that I understand your problem correctly:
- You have for example two devices which you want to control by a dll
- You can only adress one of them at the same time
- But you can adress them ? That means it is possible to adress also the second device not only the first ?

I am not 100% sure, but I think it is a problem of the memory space.
Example:
If you have a thread running in your program it uses the same memory space like the program. If you run a process, the process creates an own memory space. So, for example, if you run two processes at the same time, each process is like an own program.

My first though of your problem was: Is the DLL running in the same memory space of the program? If no, I think you can run several instances of the same DLL. If it is running in the same memory space and if the DLL handles the parameters of the device internally, it can be difficult to control to devices.

Question: Do you have handles to control your device ? Or is the control just over the API functions ? If there is no control of the device outside I think it is difficult to control two devices.
But if you can create processes from your program. Each process can handle one of the devices.

Not sure if I could help you

cu
Oliver

[GarthE]

Hi test_man,

A dll can only be loaded into a processes memory once.  The way I got around this is to write a wrapper for the LoadLibrary function.  LoadLibrary returns the same handle if the dll has already been loaded.  The wrapper keeps a running list of handles that have been loaded by the system.  If a handle returned by LoadLibrary is already in the list the dll is copied to the windows temporary directory.  The copied dll is then loaded and gets a new handle (and memory space).  If you need to load the same dll more than twice you will have to name all the dlls differently.

[jr_2005]

But if the underlying instrument driver design cannot cope with more than one instrument at a time, this approach will not overcome that limitation. For example, it is common to use a Windows Mutex to ensure that only one instance of a driver is in control at any time - this will apply even across different process spaces.

It sounds as though this particular instrument driver concept is weak if it can only support a single instance, so I wouldn't expect too much from trying this technique.

JR

[test_man]

my problem is I have multiple dll dependecy. for example

I want to call a function which is in 1.dll but 1.dll function calls 2.dll, 3.dll and 4.dll.

I can rename 1.dll  and load new file using LoadLibrary but new file will still call 2.dll, 3.dll, and 4.dll.

So I can load 1.dll twice but all its dependecies 2.dll, 3.dll and 4.dll  would have only once instance.

Any idea?

[lemontree33]

 I think u can solve it with a async function in your dll. That's mean u implement your function in dll with multithread. Any call to it will begin a new thread, and return immediately.
 

[robertinventor]

Yes you can load multiple instances.

Make sure each one has a different file name. You can do a wrapper for LoadLibrary which automatically makes a renamed copy of the dll - e.g. append the part number.

Then IN THE CALLING PROGRAM you declare all the routines that you get from the library (i.e. the ones you load using GetProcAddress(..) ) as __declspec( thread ).. This makes sure that each thread uses the routines from its own instance of the dll. Then there is no problem with collision of data - each thread is only using data from its own instance of the dll.

This works, I just used it with my own dll I wrote to do Direct2D drawing - needed to have a way to asynchronously do it in a worker thread to create an extra bitmap in the background and needed to be in a dll that's dynamically loaded to maintain compatibility with XP - and this ruled out possibility of using declspec(thread) in the dll variables - and TslAlloc was way too complicated for the particular use.

Anyway details don't matter main thing is, it works, and I tested it in a demanding environment where any collision between the thread data would cause an immediate crash almost certainly.

[Virginia_Solomon]

Someone written about doing a LoadLibrary wrapper. What that means? Is it in fact a dll wrapper of the original dll in which the handles to the original dll can be managed to output them to Labview?

Can someone clarify this for me , eventually to attach an example or a screen picture if it is handled in Labview only?

Thank you,

Virginia

[Gloorious_Leader]

Hi Virginia,

I don't know for sure what the previous posters may have been doing, but it sounds like they were creating a function or process that uses the LoadLibrary function and keeps a record of all DLL handles in use. Considering that the last post was made in 2010 and the original post was made in 2007, it might be better to create a new thread for your question.

[rolfk]

The idea as I understand it is something like this:

HANDLE MyLoadLibrary(LPSTR dllname)
{
  //  check in a global list if the DLL is already loaded
  //  if it is
  //     copy it to the temp directory with a different name and load it from there with LoadLibrary()
  //  else
  //     LoadLibrary() the requested DLL
  // store the DLL name and handle in our global list
  // return the handle
}


void MyFreeLibrary(HANDLE handle)
{
  // search the handle in our global list and remove the entry
  // FreeLibrary(handle);
}

That all said it may work for a particular driver but more likely the driver will stumble somewhere over the fact that its functions expect to have exclusive control over certain lower level resources. It's definitely a sure way into maintenance nightmare and you should consider to use or create a different driver almost at all costs if possible at all.