Ask anyone that knows me and they'll say I'm pretty modest about my programming abilities - almost to a fault (it's making finding a new job or contract work right now a bit difficult), but this paper really excites me.  Basically it's the preliminary results of a set of Serial benchmark tests that include the OpenNETCF implementation, and we're way, way out in front.

Of course I'm not solely responsible for the OpenNETCF.IO.Serial library but I did architect it and put a lions share of the code into place (though Udo has been doing a hell of a lot lately as well).  It turns out that our code has latencies that are orders of magnitude less than a commercially available package.  For example, the OpenNETCF library has a latency of around 1ms running on XP, where the commercial library is over 100ms!  The tests gave similar results on two separate Pocket PCs as well.

We didn't have any input or influence on the tests - in fact I wasn't even aware they were being done, so we did no tweaks or fixes to improve the results, these were straight out of the box.  I'd be interested to see the same tests run on some other libraries, including the upcoming implementation in CF 2.0.  It goes to show you don't always get what you pay for.

As a side note, I've got to give kudos to the Microsoft developer that wrote the Queue class.  When I implemented the FIFO in the Port class, I used a Queue, but was concerned about possible performance problems (just look at the comment I put in the code).  This test pretty much removes any doubt in my mind about it's performance.  I'm positive it's done as a basic linked list, but it's still really heartening to see things work so well.

I'll be the first to admit we don't have enough samples.  I've got plans to rectify that, and it starts with opening up all of our current sample source and letting anyone and everyone easily get, modify and upload.  I've done it by just placing it in the OpenNETCF Wiki.

It's a bit frightening becasue we're relinquishing all control for these, and people could easily write crap code and upload it, which I'd really hate to see, but I think we've got a big enough community that it should be able to self-sustain these libraries and even show some neat stuff.

This is the first step in improving the samples - the next I'm waiting to announce, but it should be a *lot* of fun!  Stay tuned, once I'm back from the Embedded DevCon I'll get things moving.

They've finally done it!

Good - it's no Hello Nasty but they've come a long way since I saw them in the University of Montana University Ballroom on their first tour....

As if to mock me, I had three comment spams added to the blog last night.  While I would like to continue allowing comments, especially since sometimes readers post code fixes and useful information, but I refuse to allow spam and don't have time to implement a captcha.  If you've got one working for dasBlog, email me and let me know, otherwise commenting here will be turned off until I find the time to integrate one myself.

For those curious about what I've been up to, I'm working on a thing - can't really name it, but it's longer than an article, but not quite a book.  Think of a 3-chapter technical book.

The working title is “Communication with VB.NET” but it's somewhat misleading.  When I say “communication” I mean data marshalling.  It's going to cover intra-thread, inter-thread and inter-process data marshalling.  Basically if you have one Form and you need to get data to another, how do you do it?  How about from one thread to another?  Or one process to another?  These kind of questions come up frequently in the newsgroups, so I'm putting together a definitive guide. 

As you may know, I think print media is dead for technical subjects, so I'll be PDFing it and selling it through OpenNETCF Consulting.  It'll probably be in the $5-$10 range.  If it's successful, we'll try to do a series of them on several topics and in several languages (think C# or VB, not English v. French).  Any topics you think need to be covered?

This one will be unusual in that it will apply to desktop developers in many instances, but all code will be targeted to run under the CF.  It's a real pain when CF developers have to “down-port” desktop code in a book to use it.

Well I've migrated my blog engine to dasBlog.  I'm not happy about the fact that it has poor FireFox support (readable, but not editable), but it does add the ability to edit and delete stuff without having to manually modify the XML and since it was based on BlogX it was pretty simple to migrate the content.

The primary motivator for the migration is blog spam.  Neil's using dasBlog and hasn't seen any spam yet, so I'm hoping just changing engines will work - at least for a while.  I implemented a CAPTCHA in the Wiki, but adding it here is a bit more work and I'd really rather do other things.