DDK build environment

Maybe I'm just spoiled by years of writing user-mode code in Visual Studio, but I'm less than impressed with the DDK build environment. This is it:



It's not very friendly about reporting errors, although it does at least have color-coding support- errors are red, warnings yellow, etc. But in general, the whole thing is just a huge wad of chewing gum and duct tape around nmake and shell scripts. Welcome to 1993! Spaces in your directory names? Ha! You'd better have your DDK installed on the root of your disk, or nothing's gonna work. Same goes for your project path. Want to reference non-DDK headers from C:\Program Files\Microsoft SDKs? Too bad- no matter how you escape it, quote it, or anything else, the spaces just get collapsed. Short of sym-linking the crap out of my drive, using 8.3 filenames (not necessarily stable across machines) or making copies of the entire SDK include tree, it's just not going to fly. This probably wasn't much of an issue before UMDF- kernel drivers have little business referencing user-mode headers outside the DDK. I'm comfortable enough in a command-line environment, but it seems like PowerShell + MSBuild would be a killer combo for this kind of thing, with the side-effect of being much more pluggable into VS for those of us who have left life in vi and the command-line behind us.

DDKBUILD is a nice compromise- it "feels" like a better integrated experience with Visual Studio (it'll do browse info, errors in the VS errors window, etc)... It's far from perfect though- limited support for UMDF, and all the smarts still live in the makefile. Wanna add a few new files in VS? They're just going in the bit bucket until you hack 'em into the makefile. Compile or link flag changes? Makefile. Want to see the text of warnings that are causing your build to fail? Gotta dig them out of a build logfile by hand- only errors are reported in VS (even though the default DDK build behavior is to fail on errors).

I'd probably be a lot less frustrated with this if the Optimus Sideshow driver project were going better. As it is, I'm having trouble getting a .NET UMDF driver up and running- strange stack corruption right after loading the framework. I'm hoping it's something dumb, or something related to the Martian build environment, but I just don't know yet...

Lamenting Nullable support in ADO.NET

I've been using .NET 2.0 heavily since it hit beta1. However, in my old job, I rarely had need to interact with ADO.NET- that was usually someone else's job. In a startup, pretty much everything is "your job"- I've done more ADO.NET in the last 3 weeks than in the prior six years of using .NET... Gotta say, I'm super-bummed that the data provider model wasn't updated to better support Nullable. Granted, in the days before nullable valuetypes, DBNull was a decent compromise for detecting nulls. But inlining code for dealing with DBNull into otherwise simple expressions leaves me feeling dirty and ashamed.

I understand that dealing with nullable types is a function best handled by the individual providers (especially considering the difference in semantics between backends), and I'm sure support will come with time. However, I'm especially disappointed that the Convert class, normally the "hero to the rescue" around DBNull, was also not updated. There's no ConvertToNullableInt32(...) or anything of the sort- we're left with rolling our own conversion methods or inlining things like:

int? MyNullableInt = reader["anInt"] is DBNull ? null : reader["anInt"];

Ick. I feel like I need a shower right now just having typed it. I'm hoping LINQ to SQL will support nullables in a more friendly manner (I seem to recall that it does, but I won't find out for sure until Orcas hits beta- don't have the bandwidth to mess with it now).

I found this recently, which looks similar to what I was considering writing... Still need to peek inside to see if I feel comfortable using it, but there's not really much to it. This covers half of what's missing. The other half is in the parameter type inference model used by individual providers. For instance, the following code breaks:

int? someIntValue = 5;

SqlCeParameter parm = new SqlCeParameter("@MYINT", someIntValue);

since the SqlCeParameter class has a hardcoded list of conversions to its internal datatypes, and Nullable<int> isn't in it. Again, this behavior is understandable- SQL CE has to work on 1.x CLRs, but that doesn't make me feel much better when I live in 2.0.

Oh well. I'm off the soapbox for tonight.

First foray into driver-land

I've been looking for an excuse to write a device driver for a long time now... When the Optimus stuff popped up, it looked like a perfect opportunity.

My first attempts at writing a driver might seem wussy to kernel-mode weenies like Randy (my old college roommate and current USB-head at Microsoft). I've chosen to roll my first driver in UMDF- theoretically meaning I can't BSOD my box when I screw something up, since my driver bits live isolated in a user-mode process instead of rubbing shoulders with busy and important kernel bits. The host process might die, but the kernel should remain stable.

The big goal with this driver is implement as much as possible in managed code. UMDF is very COM-ish, so that makes life much easier for rolling a .NET wrapper around it. I'm told that the UMDF crew initially started to implement the whole user mode driver framework in .NET, providing a COM interop layer for folks who wanted to write in unmanaged code. After the "no managed code in Longhorn" mandate, that all went out the window. I've also been told that it might not work, (them's fightin' words!) so I'm taking a big leap of faith that I understand enough about user-mode Windows and hosting .NET to make it work.

More to come...

"Don't get strangled while wearing this bag on your head"

I don't know why these language-neutral pictograms of "things not to do" are so funny to me, but they are. My previous favorites are the three found on a can of compressed air showing that it's a bad idea to: spray into your mouth, spray upside-down into your mouth, and spray into your ear (apparently, spraying upside-down in your ear or other bodily orifices is OK- there is no indication to the contrary).

Anyway, found this on the bag around a new Dell laptop- I think it's my new favorite. Looks like they're discouraging being strangled while wearing this bag on your head. Doesn't the angle on the hand look like it belongs to someone else?

Optimus Mini Three Fun

I can't explain the thrill of writing software to drive hardware- there's just some strange sense of power that comes from making things happen in meatspace by manipulating software. With that in mind, I've been following Scott Hanselman's trials trying to get .NET plugins working on the Optimus Mini Three keyboard with great interest. Back in February, he posted a request for someone to bridge the Optimus' C++ configurator plugin interface to a more friendly managed version. I'm not much of a dancer, but I whipped off a quick COM interop hack and sent it into the ether.

Fast-forward a few weeks- it's turned into a bit of an obsession. Scott liked my hack, kindly wrote it up, and asked for some enhancements. It got my mind spinning on how one could build a really nice managed bridge API (which it looks like others have also started). One three-hour-of-sleep night later, requested enhancements are working and out the door.

A quick aside- jeers to the dev at Art Lebedev Studios that thought changing a bunch of the plugin API constants and calls between release 1.29 and 1.30 of the configurator was a good idea. It's already hard for average folks to write plugins for your cool toy, but even worse that they break hard between minor releases of the product... I understand why they made the changes they did (clears up some muddiness in the model- one "plugin" per key, period), but it still caused me an extra chunk of work I hadn't planned on when I upgraded at 3am.

I'd originally been told that this hardware was capable of 30fps on each key. Maybe the hardware INSIDE the box, but the USB interface on this thing is actually a Prolific USB->Serial bridge (eg, the device inside the box speaks RS232, not native USB). Thus, the "keyboard" is not a standard HID device (it shows up as a virtual COM port), and has slow-as-molasses communication (relative to USB's capabilities). You're lucky to get 3fps, and that's on one key. If you're trying to animate all three keys, well, let's just say that "animated" is probably a strong word for what you'll end up with. Some back-of-the-napkin math shows that we're not coming close to maxing out the Prolific device's throughput, either, so it looks like the device itself is the bottleneck.

Anyway, griping aside, this thing is still a blast to play with, more so since Scott loaned me his hardware for a few days... We're currently exploring the possibilities of a Vista SideShow driver for this beast. My old college roommate was involved in a lot of the initial design for UMDF (the basis for SideShow drivers), and I've been looking for an excuse to write a driver for awhile now. This won't be the hardcore experience of writing a kernel-mode driver, but it's a fun and easy start, comparatively (and much less likely to BSOD my box).

More to come...

Whodat?

After a number of years lurking in the blogosphere and keeping my writings and doings inside a firewall, I figure it's high time to dip a toe into the bigger world out there. Here's the two paragraph history...

I'm a geek's geek, and I started early- learned BASIC at age 5 on a TI/99-4A, started my first BBS at 9 on a pair of Commodore 64's (you'd think I would've started blogging earlier), and got my first job at a real software company my freshman year of high school. Somewhere along the way, I learned there was more to life than ones and zeroes. Despite aversion to physical activity and the outdoors as a child, at some point I learned to enjoy the natural beauty of the great Northwest and all it has to offer. Perhaps it was the four years in the midwest at Purdue that really made me appreciate what I'd left behind in Oregon. Since moving back in 2000, I've decided I never want to leave again.

Like many geeks, I've also discovered a bit of a creative side while away from the keyboard. I play horn in the Oregon Symphonic Band, and, after marrying a singer, discovered that I too can sing (and actually enjoy it!). I still can't draw a straight line with a ruler, though. Oh well, creativity comes in many forms. Another outlet for mine is the seemingly endless string of home improvement projects at the Davis household. I must have a small ADD streak in me somewhere; I like to start new projects before old ones are finished, as evidenced by the state of my home and the no less than ten outstanding projects at any given time. My wife is a patient woman for putting up with it.

I'm not completely sure yet what form this blog will take. It's likely to be a mix of personal and work, geekin' and not.