March 12, 2008
I’ve been interfacing a third-party library for a project at work. The third party library is a DLL with a C interface. Now most libraries for Windows usually have a __stdcall calling conventions and for some reason I assumed that would be case with the C library. I guess it was because the demo application had not done anything to give a hint otherwise. Since the client component was going to be in .net component, I wrote a nice little C++/CLI wrapper around the unmanaged native library, so that I could easily call it from C#. I decided against using P/Invoke because I don’t like using meta-information in source code to identify implementation of interfaces. In my opinion using P/Invoke client code too dependent on a specific library. That’s a topic for another post.
One of the functions of the library needed a function pointer to a callback function. The prototype of the function was something like this, wrapped with linkage.
<span style="color:blue;">extern </span><span style="color:#a31515;">"C"
</span>{
<span style="color:blue;">typedef void </span>(*SomeCallbackType)(<span style="color:blue;">int</span>, <span style="color:blue;">char</span>*, <span style="color:blue;">float</span>);
<span style="color:blue;">void </span>SetCallBackInNativeFunction(SomeCallbackType p){<span style="color:green;">/*...*/</span>}
}
Since I wanted the callback mechanism to hook up to .Net delegates I did something as follows,
<span style="color:blue;">using namespace </span>System;
<span style="color:blue;">using namespace </span>System::Runtime::InteropServices;
<span style="color:blue;">delegate void </span>FooDelegate(<span style="color:blue;">int </span>arg1, <span style="color:blue;">char</span>* arg2, <span style="color:blue;">float </span>arg3);
<span style="color:blue;">ref class </span>AClass
{
<span style="color:green;">///...
</span><span style="color:blue;">public</span>:
<span style="color:blue;">void </span>FooCallback(<span style="color:blue;">int </span>arg1, <span style="color:blue;">char </span>*arg2, <span style="color:blue;">float </span>arg3){<span style="color:green;">/*...*/</span>}
<span style="color:green;">///..
</span>};
<span style="color:blue;">static </span>GCHandle globalGCHandle;
<span style="color:blue;">void </span>SetCallback()
{
AClass ^theObj = <span style="color:blue;">gcnew </span>AClass();
FooDelegate ^del = <span style="color:blue;">gcnew </span>FooDelegate(theObj, &AClass::FooCallback);
<span style="color:green;">//We want to do this because the callback will be called many times.
//and may live through many garbage collection sprees.
//This would be freed at the end of the program.
</span>globalGCHandle = GCHandle::Alloc(del);
IntPtr ptr2Func = Marshal::GetFunctionPointerForDelegate(del);
SetCallBackInNativeFunction((SomeCallbackType)ptr2Func.ToPointer());
}
Now every time time I ran my program, it would start up normally, but then would mysteriously crash with really strange return values like 0xC00005, 0xC0000013, etc. I recognized these return codes that indicated access violation and stack corruption exceptions. I turned on exception handlers in the debugger but the debugger refused to catch those exceptions. I was mystified. I thought that the exceptions were happening because the garbage collector was moving around my delegate, which is why I used the globalGCHandle = GCHandle::Alloc(del). This didn’t help. Turned out the program was crashing because Marshal::GetFunctionPointerForDelegate returns a function pointer with __stdcall calling convention. Now as everyone knows __stdcall and __cdecl (the default in C compilers) are incompatible, and it causes really confusing errors because the stack always ends up corrupted. The compiler (at least VC compiler) would have helped had I been passing a native function pointer. With managed code, the compiler happily let me shoot myself in the foot. The solution was to add the following attribute to the delegate declaration
[UnmanagedFunctionPointer(CallingConvention::Cdecl)]
<span style="color:blue;">delegate void </span>FooDelegate(<span style="color:blue;">int </span>arg1, <span style="color:blue;">char</span>* arg2, <span style="color:blue;">float </span>arg3);
which I got from here
The program worked flawlessly after that (I mean it did what I wanted it to do).
2 Comments |
C#, C++, CLI, Programming |
Permalink
Posted by bybitsandbytes
March 11, 2008
I’ve been working with a large project that has a lot of unmanaged MFC and C++ code, and new managed code using C#, C++/CLI with a many third-party libraries written in unmanaged code. Because of the complexity of the code, and sheer number of projects (>50 at the last count), I’ve been debating on using some scripting language to prototype and test code. I know Python, so I’ve started off with that. Unfortunately, Visual Studio 2005 does not have a good integration with the IronPython console. I tried getting the add-in sample to integrate with Visual Studio, but after wasting a few hours decided to use it without intellisense.
F# on the other hand has pretty good integration wit a REPL console, compiler and interpreter. Although, I know some functional programming, (doing some programming in Lisp, Haskell, and Boost.(Lambda|Bind|Spirit) in C++), F# seems to have an alien syntax. I’m pretty sure that after a few hours, I should get the hang of it. Probably, next weekend. Although its looking more and more likely that I’ll be at work this weekend again.
I do like this T-shirt though.

Brought to you via here.
sidenote:
I wish plain old C enums played nicely with CLS enums, or that I was smart enough to remember the nuances of how they differ.
Leave a Comment » |
C#, C++, F#, LISP, Programming, Python, Software |
Permalink
Posted by bybitsandbytes
January 22, 2008
Ever since I moved from Visual C++ 6.0 I’ve missed OleView. OleView was released as a sample and continued to work under Windows XP. Under Vista however, everytime I double click on something to read the type library, the application freezes up and goes into an infinite loop. I’ve tried debugging it but due to some laziness on my part and a new idea that’s been forming in my head for some time, I haven’t been able to solve it yet.
Besides there are many other things that are wrong with OleView. OleView relies exclusively for the registry, which really slows it down while it traverses the registry. With Side By Side installation, a theoretical type library viewer should be able to access the type information directly from the component itself, and should the user so desire traverse the registry.
Leave a Comment » |
C++, Programming, Windows |
Permalink
Posted by bybitsandbytes
January 20, 2008
that is not a default dual interface, always create a Standard Dispatch interface using CreateStdDispatch(…) and the IUnknown implementation, and return it as a VARIANT.
… I learned that over the weekend the hard way.
Leave a Comment » |
C++, Microsoft, Programming, Windows |
Permalink
Posted by bybitsandbytes
January 5, 2008
I was designing a simple COM based scriptable DirectX framework, in C++ and ATL. I wanted to support multiple interfaces that were callable from JavaScript. Unfortunately, scripting clients cannot access interfaces that are not marked default. One way of handling this was to make my automation compatible interface a super set of all the interfaces that I was going to implement in my coclasses. that just didn’t seem right, and wouldn’t work with coclasses that were aggregated, because the scripting client couldn’t find the aggregated interface.
So I googled the problem and came across this and this that seemed to be relevant. Chris Sells’ page about multiple IDispatch implementations listed about 5 ways to do this. However, out of all the methods listed only one of them worked without modifying the component. [Method 5 on this Page]. Unfortunately, none of the references listed on the page weren’t working. So I set out to making my own implementation. Last night I finally got it to work properly. Here’s some sample JavaScript code.
var dispqi = new ActiveXObject(“MultiDispQI.CoDualInterfaceQuery”);
var dog = new ActiveXObject(“DogCatComponent.DogCat.1″);
dog.Bark();
var cat = dispqi.QueryInterface(dog,”DogCatComponent.DogCat.1″,”ICat”);
cat.Meow();
print();
Here is the source code.
2 Comments |
C++, Programming, Windows |
Permalink
Posted by bybitsandbytes
January 1, 2008
So Far So Good! Not much is going on to write about. It was really cold today, so I didn’t go out at all. I was planning an early morning trip to the Gym, but that didn’t happen. Tomorrow, I’ll be returning to work after 10 days of vacation/holidays. That should be interesting.
I have been working on writing a mechanism for querying another interface through a dual interface. Basically, I would like to have a mechanism that mimics IUnknown::QueryInterface through a IDispatch interface to get another IDispatch interface that can make calls to another dual interface.
Unfortunately, with all the attention to .Net programming nobody is working on COM programming these days, and a lot of links to information about the topic have gone dead. Below is what I have been able to find which seem to be the most relevant.
1). http://www.codeproject.com/KB/atl/multidisp.aspx?print=true
2). http://www.sellsbrothers.com/tools/multidisp/
These were the top two results when I did a Google search on “multiple Idispatch implementations”
Leave a Comment » |
All Random Notes, C++, Programming |
Permalink
Posted by bybitsandbytes
August 1, 2007
////////////////////////////////////////////////////////////////////////////////////
// MANDATORY ERROR CODES REVISITED.
// http://www.ddj.com/dept/cpp/191601612
//
// This is implementation is copied from an article I had read about forcing the use of
// error codes in C++ programs. I'm not a fan of error codes in general,
// because I think people should use exceptions instead, but the exception
// model in C++ is so hard to get right, that sometimes I have no choice but to
// use error codes. However, even error codes lose their so called convenience when
// not taken care of. Hence the use of this framework.
//
////////////////////////////////////////////////////////////////////////////////////
#pragma once
#include <string>
#include <stdexcept>
namespace return_code_usage
{
///////////////////////////////////////////////////////////////////////////////
// A simple class to indicate that a return value can be ignored. Used by a
// programmer who is sure about s/he is doing.
///////////////////////////////////////////////////////////////////////////////
struct ignore_return_code{};
///////////////////////////////////////////////////////////////////////////////
// Simple exception class that is thrown when a return value is not handled
// correctly.
///////////////////////////////////////////////////////////////////////////////
class unhandled_return_code_exception
: public std::exception
{
public:
unhandled_return_code_exception()
: err_text_("")
{
}
unhandled_return_code_exception(const std::string &err_text)
: err_text_(err_text)
{
}
const char *what( ) const{
return err_text_.c_str();
}
~unhandled_return_code_exception(){/* */}
private:
std::string err_text_;
};
///////////////////////////////////////////////////////////////////////////////
// This is the class that wraps the return code. If its not recieved by a
// return_code class then the exception will not be disarmed, and an exception
// will be thrown in the destructor.
//
// By having a sepereate class with a exception-throwing exception, it is ensured
// that should a function returning a throwable_return_code object, throws an exception,
// then an exception from throwable_return_code's destructor is not thrown, when
// the stack is unwinding.
///////////////////////////////////////////////////////////////////////////////
template <class CODE>
class throwable_return_code
{
template<class CODE> friend class return_code;
public:
// constructor recieve the code and arm the exception
throwable_return_code(CODE r_code)
: code_(r_code)
, throw_(true)
{
}
//explicitly ignore error codes and avoid exception
operator ignore_return_code(){
throw_ = false;
return ignore_return_code();
}
~throwable_return_code(){
//will throw unless something is done to prevent it.
if (throw_){
throw unhandled_return_code_exception();
}
}
private:
CODE code_;
bool throw_;
};
///////////////////////////////////////////////////////////////////////////////
// Simple class that recieved the throwable_return_code, and disarms the
// throwable_return_code exception-throwing destructor. This class is only used
// by a developer who knows what s/he is doing when disarming the exception.
///////////////////////////////////////////////////////////////////////////////
template<typename CODE_T>
class return_code
{
typedef CODE_T code_type;
public:
// Explicit ctor to make sure that hte user of this class
// knows what s/he is doing
explicit return_code(throwable_return_code<code_type> &code)
: code_(code.code_)
{
code.throw_ = false;
}
~return_code(){ }
operator code_type (){
return code_;
}
private:
code_type code_;
};
}
Here is test implementation.
#include <iostream>
#include "return_code_usage.hpp"
using namespace std;
using namespace return_code_usage;
void print_function_name(std::string function_name)
{
std::cout
<< std::string(function_name.size(), '-')<<std::endl
<< function_name <<std::endl
<< std::string(function_name.size(), '-')<<std::endl;
}
#define PRINT_FUNCTION_NAME print_function_name(__FUNCTION__)
throwable_return_code<int> fallible_function(){
PRINT_FUNCTION_NAME;
return 1;
}
struct point_class{
int x,y;
point_class(int x_, int y_)
: x(x_), y(y_){}
};
// For custom types, need to have overloaded operators for comparison
// not needed for basic types.
bool operator == (const point_class &a, const point_class &b){
return (a.x == b.x) && (a.y==b.y);
}
throwable_return_code<point_class> another_fallible_function(){
PRINT_FUNCTION_NAME;
point_class p(1,2);
return p;
}
int main(int argc, char *argv[]){
// Okay
return_code<int> result1(fallible_function());
//This doesn'nt work with an explicit constructor
return_code<int> result2 = (return_code<int>)fallible_function();
// OK
if((return_code<int>(fallible_function()) == 0)){
}
// OK
if (0==(return_code<int>)fallible_function()){
}
//OK because explicitly ignoring error
(ignore_return_code)fallible_function();
//OK
return_code<point_class> result3 = (return_code<point_class>)another_fallible_function();
//OK - with thedefinition of overloaded equality operator
if (return_code<point_class>(another_fallible_function())==point_class(1,2)){
}
// OK with overloaded equality operator.
if (point_class(1,2) == (return_code<point_class>)another_fallible_function()){
}
// will throw an exception
fallible_function();
return 0;
}
Leave a Comment » |
C++, Computer science, Programming |
Permalink
Posted by bybitsandbytes