06300423.txt 30-Jun-00


Subject: dll binding
From: "Alex Fry" <afry@btinternet.com>

"Alex Fry" <afry@btinternet.com> wrote in message
news:8hp20q$j2t$1@plutonium.btinternet.com...

I wonder if anyone can help me, understand a little more
  about the way dlls are created/linked. We have a situation
  here, that questions common logic.
In dll A, we have a function the builds a static array
dll A is early bound to dll B
dll A and dll B are both used in  program C, both  A and B
  are late bound to exe C
Initially the array in dll A  had 20 elements.
It is was changed to 21 elements and the dl was recreated.
** The early bound aef for dll D was not updated however.
A new dll A and a new dll B were recreated along with exe C.
When exe C attempted to access the array through dll B, it
  only accessed 20 elements, not the 21 that were actually
  coded into the dll.
It loaded A first, and indeed reported 21 elements. As it
  continued, it loaded B, and as a result lost the 21st
  element
It appears that dll B, through its early binding of dllA,
  has somehow captured the static appearance of the array
  and not bothered to link it during the late binding.
We know, that we should have updated the early bind aef, but
  how can this influence a direct late call to the dll ?

Any thoughts


Subject: Re: dll binding
From: "Paul Piko" <paul@piko.com.au>

Alex,

Your description of your situation needs some clarification.
- when you say "builds a static array" do you mean it stores
  an array in a global/static global, or that it returns a
  literal array?
- when you say the dll is "early bound", you mean that
  you've included the
_DLL FUNC prototypes, right?
- when you say "late bound", you mean your using
  VOLoadLibrary() to load the DLL?
I was going to put together a small test to try to duplicate
  your problem, but I'm not sure how you're coding it. And
  depending how you're approaching it there are different
  issues involved. I suggest you create new, cut-down
  versions of DLL A, B and app C, with only the minimum
  amount of code and I'll take a look at it. You shouldn't
  need more than a dozen lines in each of the DLLs/app to
  demonstrate the problem.
If things are done right "B" shouldn't "capture the static
  appearance of the array".
Also, on one other point, you said:
>
We know, that we should have updated the early bind aef, but

  how can this influence a direct late call to the dll ?
>
You do not have to do this unless the function prototypes or
  class information changes. If you just change the code
  inside a function you don't need to update the AEF (since
  effectively it doesn't change anyway).

Paul Piko


Subject: Re: dll binding
From: "Alex Fry" <afry@btinternet.com>

Hi Paul,
I found the problem, The second DLL was tied to the First
  DLL directly, not to the imported function declarations
  <Grrrr>

Thanks
Alex


Subject: Re: dll binding
From: "Paul Piko" <paul@piko.com.au>

Alex,

Linking the DLL directly into an app, rather than using the
  prototypes is a very common mistake. It's not immediately
  obvious, but can cause a lot of confusion. At all my
  conference sessions on VO language basics I make sure I
  emphasise this - it is the first thing to check when
  you're getting unexpected behaviour from a DLL.

Paul