You know I don’t like to be an echo blog, but I couldn’t give up on such a fine piece of code.
This is really one of the things I said to myself “How didn’t I think of that before?” 🙂

Mike Stall has a great post and a piece of code that he wrote about using P/Invoke to access unmanaged Windows API code.

He has written a rather generic wrapper that does all the dirty LoadLibrary, GetProcAddress code and you can generically get a function and execute it without thinking twice.
It uses SafeHandles and make all the necessary releases (if you use it correctly) without you having to worry about it.

Check it out (don’t forget to read the disclaimer he wrote there) and have lots of P/Invoke fun.

I bet one of you (or maybe even me if I’ll find some time) can write a code generation utility that will use this code to create a wrapper for most of the unmanaged Windows API code that goes around making it even more type-safe in the sense if not having to pass around strings to get function names and having to deal with a generics deceleration of the function you are using.

Update 13/6/2006: Updated a few typos.

At my day job (which is part of the reason I’m posting less frequently) I’ve had to P/Invoke a bit and gathered some P/Invoke tips that I’ve decided to share.
Today’s tip is about P/Invoking and C style unions.

Let’s take the following union:

union MYUNION {
int number;
double d;
}

This is quite a standard union, which means its memory is contiguous. Its translation in C# would look like this:

[StructLayout(LayoutKind.Explicit)]
public struct MYUNION {
[FieldOffset(0)]
public int number;
[FieldOffset(0)]
public double d;
}

Notice two important things. First, the StructLayout attribute is set to LayoutKind.Explicit, this means that using the FieldOffset attributes we are building the memory layout of the struct and it will look exactly like this. When usually handling C structs in .NET and P/Invoking we usually use LayoutKind.Sequential so that the memory layout will be as described using the layout of the fields as we have put them.

The second important thing is the FieldOffset attribute. Notice that both fields have the same offset. This will tell the P/Invoke layer that these two fields are actually part of the same memory (remember, these two fields were declared inside a union!).

This is how unions will work for you in your P/Invoke code. Enjoy!

Technorati : , , , , , , ,
Del.icio.us : , , , , , , ,
Ice Rocket : , , , , , , ,

One of the big changes in P/Invoke in .NET Framework 2.0 vs. .NET Framework 1.0/1.1 is that you can now pass function pointers from a C API back to .NET.

In previous versions (1.0/1.1) you could pass a delegate as a function pointer to a C API, but could not receive a function pointer from the C API back to .NET.

This technique of passing a pointer from within the API is relatively common in more than a few APIs in Windows, where you have one function that initializes a special struct that simply contains pointers to various functions. This is like an interface for an unobject oriented language like C. It gives the designers of the API the ability to plugin and replace an implementation of a certain function dynamically depending on either the environment or parameters passed to the function that initializes the struct.

Quite cool!

This also means that various other Windows APIs (SSPI, for example) can now be called directly from C# and does not require a bridging C dll or writing a mixed (managed and unmanaged) code in C++ to glue things together.

I’ve previously covered a few of the common problems in P/Invoke code, so be sure to read that if you are facing problems when P/Invoking code!

In this post, I’ll talk about some issues that one must understand about mixing finalization and P/Invoke Interoping.

Usually, when you have a class that has an IntPtr as a member due to some P/Invoke code you implement a Finalizer and the IDisposable interface in which the necessary cleanup code will be implemented to release the unmanaged resources you have allocated.

The main problem starts when that same class has other member variables that are managed.
These managed member variables will not get collected until our class’ instance is finalized and that can generate memory pressure that is not really necessary if things are implemented correctly.

So, what can we do about it?

There are a few approaches that can help us minimize the effect of P/Invoking and finalizers:

  1. Don’t declare the IntPtr variable as a member variable.
  2. Create a class that wraps the IntPtr and P/Invoke code without declaring managed member variables.

Let’s examine both approaches.

The first approach talks about not declaring IntPtr variables as member variables. This means that if you have some function that needs to interop, delcare the IntPtr variable as a local variable, use it and clean everything up. This is the best approach but will only work if there are no (serious) performance penalties such as calling some heavy P/Invoked Windows API.

The second approach is a more viable one if there is a need to continuously call some unmanaged API such as ReadFile on a socket or file. In this case, writing a dedicated class that holds the reference to the unmanaged resource only and a finalizer and IDisposable would be a great way of making sure that it will not hold back the GC of other resources (not to mention it would be cleaner to have a dedicated class for wrapping such API 😉 ).

That class we have an IntPtr as a member variable and will have additional functions to manipulate the data that is being held behind that unmanaged resource.

By implementing one of the two approaches I’ve discussed above you can, quite easily, ease the memory pressure on your application with little change to your code and functionality.

In .NET Framework 2.0 that will come with Visual Studio 2005 (formerly known as Whideby) there is a new mechanism to handle such issues called SafeHandle. You can read more about it here, in this great post from the BCL Team Blog.

I will talk about SafeHandles in a subsequent post.