Larry
Wed Oct 06 10:18:04 CDT 2004
[Top-posting undone for sake of comprehension.]
"michael" <a@b.com> wrote in message news:emX3A65qEHA.3848@TK2MSFTNGP14.phx.gbl...
> "Larry Brasfield" <donotspam_larry_brasfield@hotmail.com> wrote in message
> news:O6EhWeAqEHA.1308@TK2MSFTNGP14.phx.gbl...
>> [Top-posting undone for sake of comprehension.]
>> "michael" <a@b.com> wrote in message
> news:O5rdjf$pEHA.3428@TK2MSFTNGP11.phx.gbl...
[...]
>> > Yes I am refering to linkage. I did include Lib2.dll as a dependency in
>> > Project 2 and also the header #include A.h in C.cpp, what else do I need to
>> > do in order to reference the static class member UserName in Project 1
>> > from Project 2?
>>
>> If both projects create a DLL, and neither DLL loads the
>> other, then you cannot readily accomplish what you want
>> unless you are willing to do something, in another DLL
>> or .exe that loads both of them, to get an address defined
>> by one known to the other. This could be done using code
>> (as I said earlier), but you have indicated an unwillingness
>> to do that. There is no other way to do it that is made easy
>> by the toolset you appear to be using. There is a way to
>> do it, but it would require more work and expertise than
>> the code solution, so I hesitate to recommend it. Here is
>> a rough outline of how it could be done.
>>
>> Force the DLL which defines the static class member
>> object to be loaded at a fixed address within the
>> process that loads it. Using the object offset within
>> the space occupied by the DLL, calculate the final
>> load address of the object. Create a .obj, using
>> assembler, which defines a constant having the same
>> name as that object, with whatever attributes are
>> needed so that the .obj can satisfy the outstanding
>> references generated in code that uses the object.
>> The value of the constant will be that same final
>> load address calculated earlier. Include this .obj
>> in the link for the referencing DLL.
>>
>> Since this is not something that is commonly done,
>> you are on your own here. The tools will not make
>> this easy. In effect, you will have to wade ashore,
>> find a suitable small tree or limb, and hew a paddle
>> out of it. Then you can navigate the creek.
>>
>> I suggest (again) that you relax your requirement.
>> Find another way to effect cross-DLL referencing
>> or change your design to not need such references.
> Larry,
>
> thanks for the reply.
>
> I can relax my requirements, so here goes: how can I reference an
> instance of a static class member between dll's? I have tried linking the
> dll to the export library of another. I am using visual studio 7.1 which
> has option explicit on. The syntax is tighter in 7.1 because I have had
> issues trying to give global variables external linkage. Not to get off the
> subject, in the model that I have below, in the Linker input properties, for
> project 2, in the dependencies box I have added Lib1.lib, there's the
> reference! And in Project 1, I attempted to declare external linkage:
> Extern CString _cdecspec(dllexport) A:UserName but the linker
> indicated that the syntax was illegal. In project 1, I had internal linkage
> because I was able to reference the static class member A:UserName from all
> modules, but again, I was not able to reference A:UserName in Project 2,
> the linker indicates that it is a unknown symbol. So bottom line,
> requirements are relax other than I need to be able to reference a static
> class member from different dll's.
>
> thank you in advance
After thinking this thru some more, I am convinced that the right
way to fix your problem is to revisit the design and change it.
As DLLs are usually designed, they provide services and possibly
(but less often) data to a 'client' .exe or .dll that loads the DLL in
order to use its features. You seem to want to use part of a DLL
without loading it. That is strange and the root problem here.
Without seeing what you are trying to achieve at a higher level,
it is impossible to make a specific recommendation.
Why not make your design conform to the convention, "To use
a DLL, load it then use its functions and data." ?
Why is this code, having interdependencies going every which
way, split into separate DLLs in the first place?
I think you should stop looking at this as a DLL mechanics
problem, step back, and get the dependencies straightened
out. Rethink your packaging scheme. In doing so, you should
be aware that it is perfectly fine (and well supported) to have a
single DLL be "loaded" several times in the same process, by
either the .exe itself or its DLLs. The actual load occurs only
once while the dynamic linkage occurs where needed when
the DLL export library is used.
If you cannot fix the design, you can, once the relevant DLLs
are loaded, inititialize pointers via code to effect the references
you have mentioned. You would use GetProcAddress() to
get the loaded address of the data item in one DLL, use it
again to get the address of the pointer in the other DLL, then
set the pointer value to reference the data item. Then, code
in the DLL hosting the pointer could get at the data item by
indirection thru the pointer. This may sound convoluted, but
I would see that as one of the natural consequences of a
design with poorly controlled interdependencies.
--
--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.