A Trip Down Memory Lane

Last week and this week, I’ve been busy writing native code in C++... something I haven’t done regularly since switching to managed code programming almost 6 years ago. Recently I found myself needing to implement some funky custom logic for picking a CLR version to run my component against, and the only solution that came up was to write native code with calls to things like CorBindToRuntimeEx.

I have to admit, I didn’t exactly look forward to it. For sometime now, my interaction with native code has been limited to defining and using COM-interop wrappers and P/invoke declarations. Coding directly in native code brought back small nuisances like having separate header files, as well as more stark differences in programming patterns such as calling an API with NULL first to get the required size of the buffer that needs to be allocated, allocating the buffer, and then calling the API once again to actually get the data. Some more things that came back were the HRESULTs and BOOLs, the ???Ex methods, inconsistencies in how the different APIs work, and the need to look at MSDN every so often. But it paid to have had past experience with C++, COM and Win32, and memory management... it all seems to come back when needed. Of course, in the end, this just serves as a reminder of how much more productive managed code really is, and to be thankful I get to use it most of the time. This might sound weird [now], but the irony is that about the time I switched, I preferred native code programming, and was on the fence with the whole "managed code thing!" Times sure have changed...

For the curious, my goals were to create a managed COM object and an NT service that always ran against the latest version of the CLR present on the machine. For the first, the approach I took was to implement the minimal logic in native code (just the IClassFactory implementation, which acted as a shim to load in the right version of the CLR, and then create the managed object in its CreateInstance implementation) while keeping the majority of the logic in managed code. For the second, I had to do more and implement most of the NT service in native code. Both worked like a charm!