I'm tyring to convert a MSVC project from VS 2005 to VS 2008. It contains a IDL file that outputs a header and stubs used for RPC. The VS 2005 project uses MIDL.exe version 6.00.0366. The VS 2008 project uses MIDL.exe version 7.00.0500.
Here's the problem: MIDL v6 outputs the following prototype for me to implement in my server code:
HRESULT PRC_Function(UINT input);
MIDL v7 with the same command line outputs this prototype:
HRESULT RPC_Function(handle_t IDL_handle, UINT input);
I don't want to have to go through and add the handle_t parameter to all my existing implementations. (Plus I still need the implementations to compile with VS 2005 for a while longer.)
Question: How can I get MIDL.exe v7 to output the same RPC server prototypes as v6?
Looks like I can answer my own question...
MIDL v6 appears to automatically default the handle type to auto_handle for the server prototypes. MIDL v7 does not, so the solution is to use a Server.acl file with the auto_handle setting in it. This outputs a Server.h file with function prototypes that is the same between MIDL v6 and v7.
However, it also outputs a warning indicating that "auto_handle" has been depreciated. Instead I used implicit_handle(handle_t IDL_handle).
Too bad this site doesn't give me badges for answering my own questions. Nor can I flag my own answer as the correct answer.
The handle_t IDL_handle is for the explicit RPC binding handle. On the server side, you can do cool stuff with it like pull the calling client's token for impersonation through the various RPC functions, but if you don't need to use it, it is fine to just set it as an unreferenced parameter (UNREFERENCED_PARAMETER(IDL_handle);). It seems like implicit binding handles are deprecated now.
On the client side, you use the binding handle you get when you bind to the RPC server for the IDL_handle parameter.
Related
I have built Xerces-c_3_1.dll from source using the Visual Studio solution provided in the download package. It works with the sample applications that are part of that package (as long as they're built with VS).
But I need to use the DLL with apps developed in C++ Builder 10 Seattle. The incompatible linkage and COFF-vs-OMF format issues (import lib) mean I need to tweak the build instructions. I believe I need to change the calling convention in the project properties from __cdecl to __stdcall, and add a DEF file to translate the exported functions for my environment.
(I believe this because I wrote and support a DLL that is used by programmers writing in many languages. I do my development in C++ Builder [familiarity with the environment], and create the release version in VS Express 2015 [massive performance improvement over Embarcadero, I'm sorry to say]. Added a DEF file for just the 32-bit version [not needed for VC++ 64-bit, just to make me nuts], and it works for everybody.)
Running TDUMP.exe on my DLL gets me output that looks like this:
EXPORT ord:0060='Edit_RunEdits'
Running tdump -ee xerces-c_3_1.dll >tdump.txt on the Xerces-c_3_1.dll built using __cdecl gets output like this:
EXPORT ord:1763='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
EXPORT ord:1764='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
Running impdef def.txt xerces-c_3_1.dll on the __cdecl build gets output like this:
?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z #1763; ?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z
Repeating TDUMP and IMPDEF on the __stdcall build gets similar results.
And this is expected.
But how can I create a DEF file from this noise? I would be perfectly happy with a sample of the format to use to turn "Initialize#XMLPlatformUtils" into something the linker can match to "XMLPlatformUtils::Initialize()" in my client app.
By the way, I also used IMPLIB on both versions (__cdecl and __stdcall) to create an import library, which I added to my test project, but the linker continues to issue "unresolved external" errors for my calls to XMLPlatformUtils::Initialize and XMLPlatformUtils::Terminate. I believe that should be expected because of the name mangling.
After building in Release mode, I am seeing exceptions which didn't occur in Debug mode. When debugging the release build, it looks like string references are not being passed correctly from the EXE (our application) to the DLL which is receiving the string reference.
Our EXE code looks like this:
string contents = "handle_message(): received=" + msg->encode();
LOG4CXX_DEBUG(logger, contents);
The LOG4CXX_DEBUG is going to log4cxx.dll, whose code looks like this:
CharMessageBuffer& CharMessageBuffer::operator<<(const std::basic_string<char>& msg) {
if (stream == 0) {
buf.append(msg);
} else {
*stream << msg;
}
return *this;
}
Looking at the Call Stack in the debugger, when I navigate down to the frame which has our source, I can see that contents is a valid string with size=583, capacity=838.
In the frame inside the log4cxx.dll (the next frame above in the stack) the string reference shows size=838, capacity=363113231 (and the values are all garbage).
Both our app and log4cxx.dll were compiled on the same machine, using the same runtime settings (/MD), but different versions of Visual Studio. The log4cxx dll was compiled using Visual Studio 2008 and our application was compiled using Visual Studio 2010. Running dumpbin on the 2 objects shows:
Our App (EXE)
MSVCP100.dll
MSVCR100.dll
log4cxx.dll (DLL)
MSVCP90.dll
MSVCR90.dll
Is this problem due to the fact that they are using different runtime versions?
If you pass non-POD (plain old datatypes) between DLL/EXE boundaries (like STL string or CRT FILE pointers) you must use the same shared CRT.
In your case, you must recompile all DLLs/LIBs with the same compiler!
See also: I can pass std::string for a Dll and what i can do with DLL´s?
The implicit question is:"Is there a way to pass data, hopefully using string and other STL containers, to DLLs of another version of visual studio either previous or later than the one that I'm using?".
Aside from using POD, there are probably three approaches: shared memory, sockets( to local host ) and MSMQ. All of these methods require additional extensive programming, but the deeper answer is found in how the interface is changing the input parameter.
I have found a possible solution to the string passing problem on the internet. It removes one layer of corruption; cast a pointer to the container to a uint and pass the uint. Dereference the uint to the pointer and the object is revealed. Beware, auto_ptrs are usually deleted in this process, so don't use them. If the passed object is still offset incorrectly( this happened to me with VS08 passing to a VS13 ), then pass the c_str() of the string instead. It's certainly inelegant, but we need to know all the alternatives. See "HowTo: Export C++ classes from a DLL" in Code Project( Nov 22, 2012 ).
dllmain.cpp(16): warning C4447: 'main' signature found without threading mode
l. Consider using 'int main(Platform::Array<Platform::String^>^ args)'.
Above is a warning I got from building a Windows Store App DLL project. I didn't change anything in that default dllmain.cpp file except for including my own version of pch.
The documentation for this warning (along with many VS2012 errors/warnings) is nowhere to be found on MSDN and here is the only relevant link I can find:
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/6daa9587-fe54-4e84-a8b9-0e5c52c2f6e8/
and the op there didn't get an answer.
If anyone knows what it means and how to fix it, it would be great!
As far as I can tell, you can safely ignore the warning. The compiler cribs when it sees a Win32-style DllMain being compiled using the /ZW flag (Consume Windows Runtime Extensions). However, the function gets called as you'd normally expect.
Alternatively, you can work around the warning by compiling dllmain.cpp without /ZW. You might need to adjust the PCH settings for this to properly work. This is the path taken by the DLL (Windows Store apps) C++/CX project template in Visual Studio.
Incidentally, the reason you do not get the warning when you're trying to build a Windows Runtime Component project (which builds everything using /ZW) is that a Windows Runtime Component doesn't declare a DllMain. This is not to say that it can't; it just picks up the dummy DllMain that the CRT defines (which basically turns off per-thread initialization and reports success).
I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.
I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?
Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()
EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?
At the request of the original owner of the green check-mark, I am submitting this summary.
The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.
Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.
All the tedious details are in the two reports linked above.
Check the preprocessor defines.
You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe
You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.
My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)
See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers
EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.
So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477
I'm currently trying to load a plugin assembly dynamically in a monotouch app.
To do this, I'm referencing the plugin dll in my app project, setting the limker to 'sdk only' and then i'm trying to call Assembly.Load(filename) within my app when the plugin is required.
This is the same approach that I've previously successfully used in monodroid. However currently, this is failing in monotouch with a FileLoadException.
Is this approach possible in monotouch? Is there a special file path you need to include? Or is this not supported in the aot environment?
Note: Obviously there are other ways I can achieve a similar effect - and I do have a backup plan... but this is my preferred route (if I can make it work)
Code like:
var a = Assembly.Load ("mscorlib.dll");
Assert.NotNull (a);
works fine with both the simulator and devices. However the parameter for Load is assemblyString which is not a filename (even if the exception thrown make you think it is).
Many other overloads exists (for Load) and other methods too (e.g. LoadFrom) but they might not all work inside MonoTouch (since some runtime support might be missing).
NOTE
Handling of mscorlib.dll is special (and works in more cases than other assembles, i.e. shortcuts). However the reflection-based methods seems to work as expected in more cases, e.g.:
string filename = System.IO.Path.GetFileName (GetType ().Assembly.Location);
Assembly assembly = Assembly.ReflectionOnlyLoadFrom (filename);
Assembly.Load (or any other way of loading code dynamically) is not supported in MonoTouch.
This is an iOS restriction - all the executable code has to be in the app (and it has to be native code, which is why we use AOT to generate native code at compile time).