Jelle Druyts .NET Consultant
Just another ignorant weirdo from Antwerp, Belgium trying to make sense out of it all
I've been quiet here, which would make sense to you too if you'd take the time to look outside and see that it's summer (open the fridge first to let your eyes get accustomed to the light). It's summertime in Antwerp more than anywhere else, so this is not a good time to be victimised by a vicious CRT's electron attack.
Anyway, my latest project involved a rather interesting setting, so I thought I'd share a little of what I like to call my "summer trip to the unmanaged world" (fortunately I have a real holiday coming up to compensate the madness).
The destination
Imagine a stress test tool that is designed to record some actions and replay them ad infinitum (or - in our case - until the machine running it crashed). We wanted to use it to stress test a binary protocol between a PDA application and a communications server, but this involved keeping all sorts of overhead in a database and dynamically creating the buffers to be sent over the wire. So just replaying a recorded script wasn't going to cut it, hence I was asked to develop a library to parse the binary data coming in from the server, log all kinds of overhead data into a database, and assist in creating the outbound buffers.
Getting the green card to pass the border
The stress test tool we're using is expensive and good, but it isn't a development platform to say the least. It doesn't know the CLR, it doesn't speak COM, it can however run some C-style code with a magic LoadLibrary style call to load an external DLL, after which it can call the exported functions in it. That's our entrance.
Packing the suitcase
You may or may not have noticed, but I'm a .NET kinda guy. When I was asked to build this library, I gently proposed to do it in .NET because of all the advantages of the managed world. Not only would the library be more secure and easier to maintain (insert more marketing-speek here), but look at it this way: suppose I'm used to packing suitcases for trips, and I know that the clothes go in the big compartiment and the USB stick goes into a little side pocket. The other way around is just silly. (The laptop and booze go into a carry bag.) Don't ask me to stack a container with randomly sized boxes to get the maximum profitability for a single cargo trip. I'd be able to do it, but it would take a long time. So I built the protocol parser and database logging part in C# in 4 days (it would have been less if the protocol spec was complete and correct); I'd still be busy developing it if I'd have to do it in C++. The CLR really is all about developer productivity in the first place, take it from me.
Building a bigger suitcase
So I have this small cute suitcase full of MSIL goodies, but where I'm going, they only take old-style cases of fixed size where the handles are on predictable places so they can toss it onto the airport cargo reel quicker and easier or something. Fair enough. So I needed to have something to unpack and reassemble the stuff everytime it needed to pass there and back again (with due apologies to J.R.R. Tolkien). In short, I hacked up a mixed-mode C++ proxy DLL that has more or less the same methods as my library, and which marshals the calls to and from the unmanaged world. And it all worked (eventually). We had some trouble along the way but nothing vital, so we were actually quite pleased we got this baby in the air in a short amount of time. When a consultant from the stress test tool's company came over, he was actually pretty amazed at what we'd accomplished since we pulled more out of their own product than they'd ever seen being done before.
The suitcase contents
Depending on the weather, you'll get a more detailed explanation of the tech breakdown (i.e. the good stuff) sooner or later. But let me say this up front: I should not be allowed to develop production C++ code (at least not without a reviewer), and probably neither should you if you're as spoiled as I am and have been programming managed code (albeit .NET or Java) for your entire professional life.
Harsh? Yes. True? Definitely. Writing secure code in the unmanaged world is hard and painful since you have around 10 years of Win32 mistakes to make up for. And it's quite a humbling experience to see a 4-line proxy method getting the heat in all possible ways for a few hours until it conforms to Win32 best practices and security demands.