how to work with 3rd party SDK

  • Thread starter Thread starter Sam Carleton
  • Start date Start date
S

Sam Carleton

The 3rd party SDK that I would like to use in C# (I am an C/C++
programmer) is designed to be used from C/C++. This is how it
works:

The vendor is abstracting things a bit. The real DLL has only one
actual exported method, one of the parameters on the DLL takes an
enum which determines which internal function is being called.
Then the vendor provides a header file with a very large number of
enums and structs. There is also a file called function.c with
the sample which contains all the different "internal" functions
and wraps up the parameters to send through the on entry point.

To top it all off, one of the functions in the function.c goes off
to the registry, learns where the DLL is located and then does a
LoadLibrary().

I know that I re-write the whole function.c file in C# and port
the 1000+ lines of header files, too. But my objective in
working in C# is to speed things up, not slow them down;)

Is there an easier way of calling this SDK? I know that I can
compile the function.c as a DLL, but then the issue of the header
files remain, is there any way to include them into the managed
world without having to re-write all the structs and enums?

Sam
 
Sam Carleton said:
The 3rd party SDK that I would like to use in C# (I am an C/C++
programmer) is designed to be used from C/C++. This is how it
works:

The vendor is abstracting things a bit. The real DLL has only one
actual exported method, one of the parameters on the DLL takes an
enum which determines which internal function is being called.
Then the vendor provides a header file with a very large number of
enums and structs. There is also a file called function.c with
the sample which contains all the different "internal" functions
and wraps up the parameters to send through the on entry point.

To top it all off, one of the functions in the function.c goes off
to the registry, learns where the DLL is located and then does a
LoadLibrary().

I know that I re-write the whole function.c file in C# and port
the 1000+ lines of header files, too. But my objective in
working in C# is to speed things up, not slow them down;)

Is there an easier way of calling this SDK? I know that I can
compile the function.c as a DLL, but then the issue of the header
files remain, is there any way to include them into the managed
world without having to re-write all the structs and enums?
Click to expand...

In your place, I might be asking myself now, "What in the hell am I doing
re-writing this ^%$$& &^%$##& in C# for? :-)

Assuming you have a reason ...

Table C# for know. Define a class structure that you like in MC++ or
C++/CLI, whatever floats your boat. Make sure the class' member return types
and arguments are CLS types so that C# can use the class.

public __gc class YourClass
{
public:

YourClass();

t1 fn1(argList1);
t2 fn2(argList2);
...
tn fnn(argListn);
};

where the fns() are proxies for what you call "internal" functions and the
ts are return types. Then decide how you want to get these managed wrappers
to call the native functions. You can either put the native functions in an
unmanaged segment in the same source file and use "it just works" to call
them:


#pragma unmanaged

t1 fn1Unmanaged(argList1)
{
//....
return t1(x);
}


#pragma managed

t1 fn1(arg1List1)
{
fn1Unmanaged(argList1);
}

or you can use Platform/Invoke if you have the unmanaged proxies in an
external DLL.

As for the issue of the structs, that depends. If it seems natural in C++,
it _may_ be natural in C#. On the other hand, if the vendor just got lazy
and used a structure where he should have used an argument list than your
unmanaged implementation can take the parameter list and build a structure.
But you don't have to expose that composition, just expose the parameter
list.

Once you have the managed (__gc in MC++) class defined, C# can use it as
easily as any other class written in a CLS language.

Regards,
Will
 
Back
Top