ActiveX DLL - separate instances of linked library

I've got a VB  ActiveX object which links to a separate DLL (VC++ based). When I create multiple instances of the ActiveX object from within the same program, I get true, separate instances (all the properties are separate, as they should be). However, I really need the DLL that I'm linking to also be truly separate instances of that DLL but I can tell they are not (based on values stored by the DLL)

Internal to my VB Class, I've got:

' "mycall" is an entry point in mycpp.dll
Private Declare Function mymath Lib "mycpp.dll" Alias "mymath" (ByVal info As String) _
     As Long

' the public version to access that library
Public Function doMath(ByVal info As String) As Long
    doMath = mymath(info)
End Function

' and a property...
Private myInternalProp As String
Public Property Let someProp(value As String)
    myInternalProp= value
End Property
Public Property Get someProp() As String
    someProp = myInternalProp
End Property

Open in new window

If I then instance two copies of this object from a separate VB application (for example)
Dim obj1 As myTools.application
Dim obj2 As myTools.application
Set obj1 = New myTools.application
Set obj2 = New myTools.application

obj1.someProp = "first instance"
MsgBox(obj2.someProp)  'shows empty, thus unique copy of "application"
result1 = obj1.doMath("...")
result2 = obj2.doMath("")    'result2 shows that this called into the same DLL

Open in new window

The "someProp" value is clearly separate between the two objects, but the doMath is calling the SAME instance of the DLL (the DLL saves some values and I can tell from the output of "domath" that it is the same call)

However, if I split obj1 and obj2 and their corresponding calls into two separate VB applications, they are completely separate (doMath clearly calls a separate .dll copy)

Is there some way from the VB side to force each instance of the ActiveX accesses a different copy of the mycpp.dll?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I think there is some confusion about that 'separate instance/copy' issues. Any DLL on Windows (ActiveX or not) is mapped into memory only once, just different data sections are created for each process that is using it. If the DLL in question however is programmed to share a certain data segmants among the processes that are using it (see e.g. - "How to specify both shared data and non-shared data in a DLL in Visual C++") there's ahardly anything you can do about it frm the VB side if you don't have the source code. If this wasn't an ActiveX DLL, you might be able to create a workaround using different physical copyies of the same file and loading them with absolute paths, but since ActiveX DLLs are loaded via COM, that will not work.
jersaAuthor Commented:
Well, to say that it is mapped only once is a bit misleading, isn't it? Because I know that if we split the code so that we have two separate applications, each of which is accessing this ActiveX they behave exactly as we want (they each access a "pure" copy of the C++DLL). So, it is mapped into memory only once PER APPLICATION, right? Each application gets its own copy of the DLL.
Yes and no. You have a "copy" in terms that the code is mapped into your virtual address space via the memory manager. Yet that's not the issue, what you are most likely seeing here are data sections that the ActiveX shares across process boundaries. And, such as it seems, that behavious is intentional, since this has to be explicitly done by the programmer.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jersaAuthor Commented:
After further investigation, it turns out it isn't the C++DLL itself that is sharing data between process boundaries, but something below that.

In other words, it not only isn't my activeX that has the problem, but it is the C++ DLL that has the problem and it isn't the fault of (nor anything that can be fixed by) that DLL either.

Thanks for the confirmation that I'm not going crazy.
jersaAuthor Commented:
The information was accurate and helped clarify that the problem was more complicated than it appeared and couldn't be solved without significant revision.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.