Confusion between two ExternalLibrary instances having functions with the same name

[James Foster]

I have a tool (Jade) built in Dolphin that provides an IDE for GemStone. GemStone provides a DLL (different for each product version) that is used to interact with the database (much like ODBC for relational databases). As part of my GUI, the user selects which database version they want, and I select the proper DLL and instantiate an appropriate ExternalLibrary instance to interact with GemStone. This all goes fine until I try to load a second DLL to interace with another GemStone instance that has a different version. It seems that Dolphin always calls functions in one DLL, even when I use the handle to the second library.

I am able to create instances of two different ExternalLibrary subclasses and I verify that they have different handles. When I use each handle as an argument to separate calls to KernelLibrary>>#'getProcAddress:lpProcName:' I get two separate entry points for the same function name ('GciVersion'). But when I call the function through the ExternalLibrary instance, I get the same result even though I'm calling different library instances.

The following is some sample code that demonstrates the general problem:

| gs31 gs32 |
gs31 := LibGciRpc64_310x open: 'libgcirpc-3.1.0.2-32.dll'.
gs32 := LibGciRpc64_32 open: 'libgcirpc-3.2.0-32.dll'.
gs31 handle -> gs32 handle. "an ExternalHandle(16rFA10000) -> an ExternalHandle(16rF940000)"
gs32 gciVersion -> gs31 gciVersion. "'3.2.0' -> '3.2.0'"

If I close the image and start over changing only the last line, I get the following:

| gs31 gs32 |
gs31 := LibGciRpc64_310x open: 'libgcirpc-3.1.0.2-32.dll'.
gs32 := LibGciRpc64_32 open: 'libgcirpc-3.2.0-32.dll'.
gs31 gciVersion -> gs32 gciVersion. "'3.1.0.3' -> '3.1.0.3'"

Thus, it seems that whichever function is called first gets remembered, and subsequent calls to functions in another library will reuse the first entry point.

Windows recognizes that each library has a function with the same name:

| gs31 gs32 |
gs31 := LibGciRpc64_310x open: 'libgcirpc-3.1.0.2-32.dll'.
gs32 := LibGciRpc64_32 open: 'libgcirpc-3.2.0-32.dll'.
(KernelLibrary default getProcAddress: gs31 handle lpProcName: 'GciVersion') ->
(KernelLibrary default getProcAddress: gs32 handle lpProcName: 'GciVersion').
"an ExternalAddress(16rFA1A5C0) -> an ExternalAddress(16rF94A540)"

It seems like there is some "optimization" (or caching) that avoids the getProcAddress() lookup if we have done the lookup before.

[James Foster]

I've figured out what is happening. The function address is being cached with the method. In my case the method is in an abstract superclass. Duplicating the methods in each subclass seems to solve the problem.