Jono's blog entry has the list of fixes and the download details.

A new interest group called WE-DIG was launched at DevCon last week.  They've put quite a bit of work into it and it looks promising.  They're starting in the Seattle area, but there's already been a lot of interest for other regions, so it may grow quickly.  Check them out.

Neil covered some great mechanisms for getting 10,000 records into a device database:

<quote>
1. Tie one end of a piece of string to the WiFi antenna, if your device has
one, and tie the other end to a tin can. Enumerate the 10,000 records on
your desktop computer and verablly dictate each record into the tin can.

Performance: slow;
Success rate: zero.
Implementation: easy peasy lemon squeezy.

2. Purchase a flock of carrier pigeons, 10,000 in number. Hand-write each
record onto a piece of paper and attach to the bird. Aim the bird at the
device and release.

Performance: slow:
Success rate: zero.
Implementation: possibly very messy.

3. Move to SQL Server. RDA and Merge Replication are your friends.

Performance: good!
Success rate: >1,000,000,000 pigeons.
Implementation: well documented.

4. Hire 10,000 people and get them to memorize one record each. Get them to
follow the device wherever it goes.

Performance: In theory, should outperform Oracle for record access. In
reality, you're statistically likely to get a few "slow" records
Success rate: Depends on the demographics of your recordset.
Implementation: costly, just like Oracle :)

5. Populate the DataSet on the server and transmit as a DataSet object using
Web Services ().

Performance: suffers from a serialization/deserialization overhead which is
costly with 10,000 records.
Success rate: Jackpot, baby!
Implementation: piece of cake.

6. Re-architect your solution. No one should need 10,000 records on a
device. Don't even think about loading that into a ListView either :)

Performance: the best yet.
Success rate: it's the pot of gold at the end of the rainbow.
Implementation: requires some research and reading of those folded paper
thingies.... (books)
</quote>

If you're a fan of data mining, then you'll love this cool newsgroup mining tool done by Microsoft Research (pointed out by Jono).  You'll see the compactframework newsgroup is #6 for activity out of all of them - pretty impressive!

Oh, and I actually added a MathEx namespace with a couple FFT implementations and a boatload of new constants to the SDF just before leaving for DevCon, so look for that in the next source drop (maybe in the next week or so?).

I'm back from the Embedded DevCon and I'm working on a new test project idea (true real-time managed code - more on that later). In doing so, I've added some more to the SDF source.  Using Alex Yakhnin's MSDN Article as a base, I've added a ToolHelp namespace with a ProcessEntry class to the SDF.  You can actually create a real Process Viewer (not the crap “running programs” in the PPC) with essentially 2 lines of code beyond the UI work:

To show the processes in a ListBox:
myListBox.DataSource = OpenNetCF.ToolHelp.ProcessEntry.GetProcesses();

To kill a selected process in the list:
((ProcessEntry)myListBox.SelectedItem).Kill();

Once again, I love managed code!

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.