One of my friends was asking me why I have so much hard drive space, and it’s really because the speed at which good resources evaporate, you’d think with all the storage these days there would be no exothermic information transfers et al.

It took me a while to find this site as I’ve not been there before, but this article (14 parts, each part 1-3pages) on CLR framework interaction had the detail I was looking for, too often did I find dead links to (now defunct), or some unfinished business by a more in-experienced writer. Sure the Microsoft blogs and forums helped out (, but they are usually corrupted by knowledge and may lapse in the simple things that otherwise can take hours to find.

This article finally gave me the whole 9 yards on, exactly what CLSID, IID, API superseded what, I do not develop with COM interfaces often and I need that help these days 😉

The reason I had to dig into the framework was that the technique were currently using for binary instrumentation; is one copy. Not just one copy, but, the memory get’s allocated, assigned to (the initial data collection), then transferred into an ObservableCollection<>() in a single copy, all the while being collected in the context of an external process address space. So that’s a fairly appreciatable level of performance.

Previously I was using a horribly inefficient P/Invoke queuing system to marshal into the runtime, now, I’m able to extend VS 2008’s marshal_as library (this actually made it worth the effort to relearn Managed C++, which I previously gave up on).

Too busy these days, trying to run a startup and develop a product, I’m still merging a lot of new design elements, shifting around the layout of the CLR should hopefully be the last time I have to deal with InterOp (which I have now become an expert at every level).


October 5, 2007

The best laid plans of mice and men… How’s that go?  Unfortunately, I fed the gremlins before midnight or something the day before my presentation and I was not able to show the epic WPF visualizations I had planned.  Better late than never, here are 2 different perspectives of the native heap.  Green is an allocated busy block, red is anything else right now.  I have a ton more data to display but have been working on the interactivity and having the various chunks be more useable.  Right now there just blocks, though they are relative to the actual size, color coded and laid out in a representative fashion to where they lie in the address space.  They do not individually respond when clicked on, to detail the specifics of their allocation.You can definitely see the patterns and layout of the heap, including the pattern demonstrated by the link lists that manage individual sizes.  (re: CORE Security Technologies Gera R. has a paper on heap-defragmentation).I’ll blog more about this process soon; I’m still on the road having just gone to a SwA (Software Assurance) conference in DC (sounds spooky).  There was an interesting talk by Rick Kuhn of NIST on Combinatorial testing and covering array generation. That’s it for now, more soon. Heap View 1Heap view 2