Maaaaan… it’s been way too long since I’ve posted. I’ve been absolutely buried at work, doing 80 hour weeks trying to revamp the way a network component works. I’ve had my head deep into I/O Completion for days, and it’s been fun, but I haven’t had time to do much of anything else in my life.
So, back to regularly scheduled programming soon, hopefully.
I’m currently undergoing the long but not terribly painful process of getting a new Windows 2000 VM patched up for some specific testing, and while I watch a bunch of status bars, I thought I’d toss out a few random things I’ve been collecting, of varying interest to varying people.
First off, the Microsoft MacBU people have had a couple of amazingly good posts this week about some of what makes running software teams so hard. Schweib has an amazing post about MacBU’s decision to drop support for VB in the next release of MacOffice. He gets into some architectural details of the VB implementation and of the necessary changes to support Intel, Xcode, and 64-bit.
The technical stuff is fascinating – on-the-fly C++ object morphing, runtime-generated assembly, etc. – lots of interesting[1] stuff. But more than that, the detailed discussion of the tradeoffs is great. You might have to be a developer or dev manager to really grok what he’s saying, but man, I know *I* have been in that situation before, and it’s painful.
And finally, a plug for corporate bloggers – Schweib’s post is, in my opinion, the very best PR Microsoft could dream of in selling this (painful) issue to its customers. No amount of money can buy the level of trust that’s built by knowing that there are real humans sitting over there wrestling with hard problems like this just as conscientiously as I would.
Another MacBU developer, David Weiss, has a post up about the tradeoffs involved in automating software testing. If you do software test for a living (or manage someone who does), you’ll like this. It’s interesting to remember that the very same problems that apply to small dev shops (like mine) apply to one of the biggest (and certainly richest) shops in the world. Resources simply can’t fix some problems. Then again, we’re all computer scientists here, so we knew that already. 
To complete the trifecta, I just downloaded the newest build of Parallels Desktop, which is a VPC and VMware competitor for MacIntels. Maaaan, it’s fast. We’re talking 7 seconds from the end of the BIOS screen (which is pretty short itself) to the windows XP login prompt. And this is on my fully patched XPSP2 dev VM, with a dozen DDKs, half a dozen SDKs, various Visual Studios, a couple of WinDBGs, and all of the other crap it takes to write code. Plus, my USB smartcard reader now works, which was my biggest remaining beef. I do tons of driver development of software-only drivers in it. Recommended!
Status bars are still crawling across the screen. Oh well, at least they’re fast. 
[1] if you happen to be a big old geek
I’ve been a customer of Gimpel Software’s PC-Lint for a while now.To help programmers adapt to using it, Gimpel publishes a Living with Lint
document that provides practical advice for optimizing the signal-to-noise ratio in Lint’s output, and for optimizing your development process for use with Lint.
In that spirit, here are Steve’s Top 10 Suggestions for Living with PREfast
OK, I guess this list goes to 11. I’d be curious to hear about others’ experiences in really using PREfast for development.
Mark Lacey, a developer who works on the compilers and related tools, has a great blog post up with a definitive explanation of the Interlocked* code generation issue that I mentioned before. He left a comment linking to his post, but I thought I’d link it from the main page since I did complain about this issue on the main page.
I’ll let you read Mark’s detailed explanation of the bug in question, but at a high level, he says that the following functions are affected:
He also suggests a couple of workarounds for code that needs to check return values from these functions.
Note that although he refers to the visual studio compilers, the issue is present in the currently released DDK compilers (13.10) from the 3790 series. It does seem to be resolved by the WDK’s 14.00 compiler (although the WDK is still in beta, of course).
I continue to be impressed with how responsive Microsoft’s bloggers are to the communities they support. I had really only expected a don’t do this
KB article in a few months. Getting an authoritative developer response like this is fantastic. And, from the look of the first dozen or so posts, it looks like Mark’s blog is going to be great. Added to the blogroll!