I’ve been spending a little time recently writing a custom Wireshark dissector plugin for the UDT protocol. This didn’t prove to be that difficult once I got over the initial problem of actually getting the Wireshark source to build with VS2008. My problem was that I’d found a CodeProject article which is now slightly out of date and which I followed too closely - setting up the Platform SDK version that the article stated was required.
I’m currently looking at the new concurrency profiling tools that come with Visual Studio 2010. It’s interesting and useful stuff. The tools provide what I have attempted to develop in the past by using API Hooking but it’s vastly superior in speed and functionality.
One of the big problems for me with my API Hooking concurrency tools (Deadlock detector and Lock Explorer) was that the instrumentation often caused the target process to run pretty slowly.
I’m building my managed XLL tool in two versions, a ’normal user’ version and a ‘pro’ version. The ‘pro’ version has additional features that I don’t feel would necessarily appeal to all of my potential users; things such as easy Excel RTD server support and Asynchronous worksheet functions.
The fact that the core code is identical between the two versions has caused me a little trouble as I want to package the code in a single assembly and, although it’s all C++/CLI, I can’t work out how to build the common code in one project and link it with each of the final product projects to produce two single assemblies that both include the common code.
Has anyone got anything to say about the relative merits of Parasoft Insure++ vs the BoundsChecker parts of the Microfocus DevPartner Studio product?
I’ve used BoundsChecker for a long time, and it has plenty of faults but the fact that all support channels seem to have vanished during the transition of the product from Compuware to MicroFocus means that I’m now considering moving to something else.
So far my impression of Insure++ isn’t being helped by the fact that the sales person seems to require a ’land line’ to contact me on to enable them to talk to me about how I might get something to evaluate (oh good, “enterprise” marketing) and no, my mobile number isn’t any use to them even though they’re supposed to be based in the same country as I am.
I upgraded one of my build machines to Windows 7 almost a month ago now but I only managed to get around to doing my main developer machine at the start of this week. Apart from the fact that the Windows 7 in place upgrade failed on me, twice, and rolled back to Vista without leaving me with much information as to why it had failed (removing Compuware’s DevPartner Studio did the trick), the upgrade went pretty smoothly.
By an interesting coincidence I happened to be searching for a few new C++ blogs to follow and I also happened to have just updated this entry about Stan Lippman’s VC6 rant (since I found a link to the original posting which had been deleted before I could comment on it back in 2005…).
Anyway, back to the point, The Lone Coder asks “Why oh why do people insist on using compilers that are way out of date?
Back in October 2005 some of my clients started to complain that the latest version of the Platform SDK (the April 2005 version) broke their builds. The culprit was uuid.lib which had been built with debugging information that the VC6 linker didn’t understand and which caused a link failure. The end result was that the last version of the Platform SDK that worked with VC6 was the February 2003 version. This all seemed quite unnecessary to me at the time; as if the latest Platform SDK was deliberately unusable for VC6 which had (in September 2005) just become unsupported.
Since I complained about how the Microsoft File Transfer Manager sucked when I was downloading the Windows 7 Beta back in March I thought I should be balanced and point out that last night I kicked off a download of Windows 7 and the x86 and x64 SDKs and this morning they were all present and correct and that I had none of the problems that had plagued me last time.
I’m fairly set in my ways about the value (or lack of) of comments in C++ code. I tend to have very few comments in my code and I tend to favour names and structure over comments; names and structure compiles and doesn’t lie. Sometimes I go too far in that direction and I’m forced to fight with some of my old code and at that point I might add a comment that explains the non obvious but I’m more likely to attempt to refactor the code into something where the names and structure tell the story better.
Jamie Fristrom over at GameDevBlog thinks that “Globals are underrated”. I disagree, and, agree with most of the comments that Noel makes; globals and their 90’s equivalent, singletons, are evil.
As anyone who has looked at the code that I present on my blog knows, I tend to favour ‘prarameterise from above’ in my designs. That is code that doesn’t reach out to a global for something but that only works with what it has been given.
