Why are the mangled names are a bit different?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi, can anybody help please!

I've got an app with a few dlls. When I run the app I get the following
message in a message box:

The procedure entry point
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@VCAccessGroup@PAC500DB@@$00$0A@UUI_24@Bus2Types@@$OBPE@K@2@XZ
could not be located in the dynamic link library.

Looking at the library with dependancy walker I find the exported symbol is
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@UCAccessGroup@PAC500DB@@$02$00$0A@UUI_24@Bus2Types@@$0BPE@K@2@XZ

The main difference I see here is that CAddessGroup is preceeded with a V in
the error message, but the symbol really has a U infront of it. I found a
posting that mentions U preceeds struct names. That seems to make sense.

But why do I get a V in the error message, what does V mean and why would I
be getting a difference between what my app in importing compared to what the
dll exports?

Any help would be really appreciated.
Thanks,
-Scott
 
Scott said:
Hi, can anybody help please!

I've got an app with a few dlls. When I run the app I get the
following
message in a message box:

undname.exe, which is included with VC++ is your friend in cases like this.
Try it out (in your said:
The procedure entry point
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@VCAccessGroup@PAC500DB@@$00$0A@UUI_24@Bus2Types@@$OBPE@K@2@XZ
could not be located in the dynamic link library.

Are you sure you pasted that name correctly? According to undname it's not
a valid decorated name.
Looking at the library with dependancy walker I find the exported
symbol is:
?GetAccessGroups@CThe500Database@PAC500DB@@SAAAV?$CEntityCollectionMap@UCAccessGroup@PAC500DB@@$02$00$0A@UUI_24@Bus2Types@@$0BPE@K@2@XZ

This decodes to

public: static class PAC500DB::CEntityCollectionMap<
struct PAC500DB::CAccessGroup,3,1,0,struct Bus2Types::UI_24,500,unsigned
long> &
__cdecl PAC500DB::CThe500Database::GetAccessGroups(void)

The main difference I see here is that CAddessGroup is preceeded with
a V in
the error message, but the symbol really has a U infront of it. I
found a
posting that mentions U preceeds struct names. That seems to make
sense.

But why do I get a V in the error message, what does V mean and why
would I
be getting a difference between what my app in importing compared to
what the
dll exports?

A couple of suggestions:

1, Make sure that the DLL and the caller (another DLL or EXE) are compiled
with the same version of the compiler. The fact that the first name above
doesn't decode as a valid name under VC++ 7.1 while the second does suggests
to me that there might be two different compiler versions.

2. Make sure that all #defines (and command-line/IDE defined preprocessor
symbols) are the same when the header file that contains the definition for
PAC500DB::CThe500Database is seen in both modules (the DLL and the caller).

-cd
 
Hi Carl,

Thanks for the help. "undname.exe" is an excellent tool. You're right, I
couldn't copy the decorated name out of the message box, so I typed it in. I
put a O where there should have been a 0! The corrected version decoded to
something similar to the exported symbol... except instead of "struct
CAccessGroup" I got "class CAccessGroup".

This confused me for a bit longer because CAccessGroup is defined using
struct. However, it does derive from a class... it appears that this is
somehow affecting the decorated name, but it's different between the
__declspec(dllexport) and __declspec(dllimport) versions.

Anyway, I've changed CAccessGroup so that it's declared as a class instead
of a struct, and this seems to work ok.

The dll and exe are compiled in the same solution using Microsoft Visual C++
..NET 69586-335-0000007-18635.

-Thank-you very much for your speedy help,
Scott
 
Scott said:
Hi Carl,

Thanks for the help. "undname.exe" is an excellent tool. You're right, I
couldn't copy the decorated name out of the message box, so I typed it in. I
put a O where there should have been a 0! The corrected version decoded to
something similar to the exported symbol... except instead of "struct
CAccessGroup" I got "class CAccessGroup".

This confused me for a bit longer because CAccessGroup is defined using
struct. However, it does derive from a class... it appears that this is
somehow affecting the decorated name, but it's different between the
__declspec(dllexport) and __declspec(dllimport) versions.

Anyway, I've changed CAccessGroup so that it's declared as a class instead
of a struct, and this seems to work ok.

The dll and exe are compiled in the same solution using Microsoft Visual C++
..NET 69586-335-0000007-18635.

-Thank-you very much for your speedy help,
Scott

:

Yes that is an unfortunate bug in our compiler. We should not name
decorate a class and a struct differently, but fixing this would
completely break binary compatibility so it is something we cannot do.
Of course the fix in the source is as you already did.

Ronald Laeremans
Visual C++ team
 
Back
Top