name-decoration

I'm stuck on a fix to a legacy Visual C++ 6 app. In the C++ DLL source I have put extern "C" _declspec(dllexport) char* MyNewVariable = 0; which results in MyNewVariable showing up (nicely undecorated) in the export table (as shown by dumpbin /exports blah.dll). However, I can't figure out how to declare the variable so that I can access it in a C source file. I have tried various things, including _declspec(dllimport) char* MyNewVariable; but that just gives me a linker error: unresolved external symbol "__declspec(dllimport) char * MyNewVariable" (__imp_?MyNewVariable@@3PADA) extern "C"

When we compile a dll using __stdcall inside visual studio 2008 the compiled function names inside the dll are. FunctionName Though when we compile the same dll using GCC using wx-dev-cpp GCC appends the number of paramers the function has, so the name of the function using Dependency walker looks like. FunctionName@numberOfParameters or == FunctionName@8 How do you tell GCC compiler to remove @nn from exported symbols in the dll? __stdcall decorates the function name by adding an underscore to the start, and the number of bytes of parameters to the end (separated by @). So, a function: void _

I'm trying to call from C# a function in a custom DLL written in C++. However I'm getting the warning during code analysis and the error at runtime: Warning: CA1400 : Microsoft.Interoperability : Correct the declaration of 'SafeNativeMethods.SetHook()' so that it correctly points to an existing entry point in 'wi.dll'. The unmanaged entry point name currently linked to is SetHook. Error: System.EntryPointNotFoundException was unhandled. Unable to find an entry point named 'SetHook' in DLL 'wi.dll'. Both projects wi.dll and C# exe has been compiled in to the same DEBUG folder, both files reside

I have a rather large and complex set of programs to port from VC8 to VC9. One of the modules has a number of layered typedefs, which cause the compiler to generate a C4503 warning (decorated name truncated). The generated LIB file will not properly link to other modules in the project. VC8 had no trouble with this, leading me to conclude that either the decoration process has changed to generate even longer names, or the internal limit for the length of a decorated name has decreased. What's the best way to get over this? For legacy code reasons, the MSDN suggestion of replacing typedefs with

Why is this? transform(theWord.begin(), theWord.end(), theWord.begin(), std::tolower); - does not work transform(theWord.begin(), theWord.end(), theWord.begin(), tolower); - does not work but transform(theWord.begin(), theWord.end(), theWord.begin(), ::tolower); - does work theWord is a string. I am using namespace std; Why does it work with the prefix :: and not the with the std:: or with nothing? thanks for your help. using namespace std; instructs the compiler to search for undecorated names (ie, ones without :: s) in std as well as the root namespace. Now, the tolower you're looking at is

This question is related to "How to make consistent dll binaries across VS versions ?" We have applications and DLLs built with VC6 and a new application built with VC9. The VC9-app has to use DLLs compiled with VC6, most of which are written in C and one in C++. The C++ lib is problematic due to name decoration/mangling issues. Compiling everything with VC9 is currently not an option as there appear to be some side effects. Resolving these would be quite time consuming. I can modify the C++ library, however it must be compiled with VC6. The C++ lib is essentially an OO-wrapper for another C