Homebrew Embedded Hacking

I finally have my busted laptop back. I paved it and was in the process of reinstalling the important stuff when the storm hit. Since I’ll be moving back to that machine very soon, I figured I could break quarantine on the machine I’m currently using. Since the one thing you can’t run in Virtual PC is the embedded device emulator, I decided to install Windows CE. I stumbled across this article for DIY Wireless Access Points (from Wireless Hacks) which pointed me to a couple of embedded system vendors – Soekris and OpenBrick. I’d love to get CE up and running on one of those boxes and roll my own media client device, to learn about hacking embedded if for no other reason. I know Duncan has a cool homegrown audio PC project, but I was thinking something embedded would be even cooler.

There doesn’t seem to be much, if any, grass-roots community around building CE based devices. All the efforts on the embedded website seem to be geared towards large companies. For example, the US distributors of CE don’t list prices on their pages. I can only assume it’s a case of “if you have to ask, you can’t afford it”, at least for the individual developer. CE is not included in MSDN (though it used to be if memory serves). I can only find info on homebrew embedded hardware on Linux sites.

Where are there any other DIY or homebrew embedded sites that I don’t know about?

P2P in Longhorn

I realized I wasn’t going into the office today @ 6am. My wife’s school called to let us know school was canceled. Given how hard it has been to get my email all day, I’m guessing I’m not the only one. Since I’m not at work or doing email, I figured I’d mess around with my new Longhorn machine.

I noticed browsing through the samples that Longhorn has a managed P2P API. The PDC build only supports PNRP and identities, which means you can’t acually communicate with another machine via P2P (yet), but it’s nice to see that it exists.

Objects vs. Data

Christmas was crazy (my wife’s blog has the details), so I didn’t get a chance to blog about Sean & Scott’s desire for unification of objects and data, Erik Meijer’stwopapers on the topic, or Dare’s responses to both. Programming language evolution is something I’ve keenly interested in. When I first started this blog almost a year ago, one of my early posts was about a disruptive programming language technologies presentation from MS Research. Among the areas mentioned for improvement: were database integration and XML manipulation. Sounds like the Xen language demoed @ XML 2003 is a step in that direction.

When you read Erik’s papers, you’ll notice that one of the goals is to natively integrate XML into the language. He writes: “In our approach XML documents or document fragments become first class citizens.” What’s interesting about that is that if you take XML to mean pure-infoset-data (as opposed to angle-bracket-serialization-format) then you can argue that Data (with a capital D) is not a first class citizen of today’s Object-Oriented languages. Given that a lot of OO code has been written to manipulate data, having a language that explicitly distinguished between the two could be valuable (assuming it made the programming easier and the programmer more productive).

Note, this is the opposite approach from tools like O/R mappers and XSD.exe which attempt to hide the differences from the programmer. We’ve seen a similar evolution in the way we think about invoking objects across the network. Tools like DCOM and .NET Remoting attempt to hide the RPC and make it appear as a local call. But as the thinking evolves, tools like Indigo is designed to make the boundaries across apps and machines explicit. Initial thoughts on data access were to make it all look like objects (i.e. O/R mapping). But as the thinking evolves, maybe we need to make the boundaries between objects and data explicit (and easy) as well.

Eating Dogfood

I know I blogged that I haven’t been dogfooding, but Don’s post about programming without generics hit home. For example, look thru the source code for dasBlog and you’ll see a ton of hand-written type-safe collection classes that Whidbey will just eliminate en masse. So I loaded up an older laptop with Longhorn & Whidbey. I have been more interested in Whidbey than Longhorn so far, but I figured since I could dedicate hardware (LH runs much better on my 650MHz P3 than in a VPC on my 2GHz P4) I might as well go all the way. Plus, an old friend who spent his Christmas vacation @ Whistler brought me an authentic Longhorn Saloon & Grill hat.

Support for MSNP8

Robert M. Wagner Jr. sent me (and Chris) an update for IMCLI to support MSNP8. I haven’t tested it or integrated it into Messenger.NET yet, but here’s the code if you don’t want to wait.

I’ve spun up a GDN Workspace for IMCLI and Messenger.NET. Nothing’s up there yet until I get Chris‘s permission to post his code. Permission has been granted – I’ll have the code up there in the next day or so.