The future of the Smart Device Framework

I just got an email in the Support inbox over at OpenNETCF asking about the libraries support (or really lack thereof) for Wireless Networking in Windows Embedded Compact 7 (rolls off the tongue, doesn’t it?).  While this is a question about a specific feature of the SDF, it really opens up the broader question of what our plans are for the future of the whole product.  In fact you could say it really opens up the question on what our general company plans and philosophy are.

First, let’s address this specific issue, as it deserves answering and has a little bit of a back story leading to a minor rant which is always fun. 

The SDF supports an object model for wireless networks that is based around the Wireless Zero Config (WZC) API.  Microsoft introduced WZC in CE 5.0 (IIRC) in an attempt to “standardize” the way the platform and apps would communicate with the wireless drivers, since NDIS doesn’t really have any specification for a lot of the wireless properties.  While I applaud the spirit, WZC is convoluted at best, and was definitely not designed to make the life of someone who has to use P/Invoke to communicate with it any easier.  Still, it was some sort of standardization so we rolled up our sleeves and created a managed interface for it. 

I’ll readily admit that what we ended with isn’t ideal, but I’m a fierce self critic and I rarely think what we do is as good as it could be.  Still it provided a programmatic interface for something that a *lot* of people wanted and that Microsoft had not implemented in managed code.

Well with Compact 7 (I’ll just call it CE7) Microsoft decided that WZC wasn’t the way to go, but instead Native WiFi was.  Painfully they didn’t follow a sensible “deprecated but supported” track for WZC and support side-by-side, they just dropped WZC support altogether.  That meant that we could not interface with a wireless adapter under CE7 using our existing code base at all – it was a flat-out break.

To make things worse, Microsoft went radio-silent for about 2 years (and still counting – yes I’m looking at you Redmond!) on what, if any, future the Compact Framework, or CE for that matter, might have.  The original WZC work was probably 4-6 weeks of development and it required that we buy several devices for testing.  Believe me, it was a real pain in the ass.  Do we (more specifically do *I*) really feel like doing that all again for the Native WiFi interfaces?  If I do, where do I get a CE7 device with WiFi support?  If I do all of that work, what’s the ROI if Microsoft kills the Compact Framework?  What’s the ROI if they revive it and implement Wireless themselves?

It’s really difficult to answer those questions, and we’re not the only ones who are wondering these things.  I can say, though, that we’ve very recently decided that yes, we will continue to do both support and new development for the SDF.  What that new development will entail I can’t say.  Not because it’s some big secret, but because I can’t make those plans until Microsoft tells us their plans (and they haven’t).  If they decide to release a new version of the Compact Framework, I’d like to not have a load of functionality duplication between it and the SDF.

So, is the SDF a dead product?  No.  We will continue to support it and have plans for feature additions.  We just don’t know exactly what those features will be or when they will be written (confidence inspiring, I know). 

Will we provide Wireless support for CE7?  If Microsoft does not, then yes, we will.  Again, we don’t know if they will or not.  If they did, we don’t know when that would be.  Ideally, though, programming for WZC and Native WiFi should be the same, so if they don’t do it, we’ll add support that looks and feels just like what’s in the SDF today.  If they do add it, I’d be inclined to update our object model to match theirs (keeping the old stuff for compatibility though).

Don’t read too much into this.  Yes, I’m optimistic about the Compact Framework and Windows CE Windows Embedded Compact but I’ve been using them for over a decade and I’ve based a whole lot of my knowledge, business and life on them.  I almost have to be optimistic.  But let’s face it, CE and the CF are still great tools for delivering products.  We’re still shipping products based on them.  Still doing new development and new installs.  Still writing proposals for them. 

Yes, we’ve tested the waters with Android and iOS.  We’ve even delivered finished products for them both, but using those tolls only reinforced my feelings about the strength and possibilities of the CF and CE and we’re still committed to using and supporting them.

A sign that everyone has just given up

I’ve been working in the Windows Embedded space for over a decade now, and I must say it’s a far different picture today than it was in years past.  That’s not a jaded nostalgia either – Windows Embedded used to have a real annual conference at nice venues in Las VEgas.  We has good speakers and great content.  The teams in Redmond shared loads of info about what was going on and what was coming down the pike.  Teams cared about what they were doing and what their customers wanted.

Slowly, though, it seems to have atrphied to the state that it’s in today.  I know of no one using Compact 7 in an actual product.  The Compact Framework hasn’t had an update in something like 4 years and there is absolutely no word at all what its future might be.  The tools required to do development for non Windows Phone devices are no longer available unless you purchase a full (expensive) MSDN subscription.  I can usually count the number of questions that get asked in public forums and places like Stack Overflow in a week on two hands – sometimes just one.

Today I got what had to be one of the most telling things I’ve seen though.  A sign that the people is Redmond just don’t care any longer either.  For years, Microsoft has sent out a monthly embedded newsletter – the Windows Embedded InfoBlast – and while the quality of the contents has been in the same slow decline as the rest of the industry, the one I received today just pegged the “I no longer give a shit” meter.  This is exactly how it looks in Outlook for me:


Obviously either no one cared enough to even look at that before it went out, or if the did they didn’t care if anyone actually read it.  Looking at it is like looking into the sun, but without the benefit of the warmth on your face.

X509 Certificates + Compact Framework = WTF?

So a customer asked me last week if I could provide them some managed code to allow them to insert a certificate and a private key into the certificate store on a Windows CE device.  A simple enough request, right?  Heh, isn’t that how they all start?

To be honest, I’ve done very little work with certificates in the past – basically I’ve created certs for use with Padarn and SSL but that’s about it. So my first order of business was to do some due diligence to try to get an idea of the scope of the problem.  I pulled up the MSDN docs of the Compact Framework’s support for X509 stuff.  It shows that there is device support for the X509Store as well as the X509Certificate so I told them it should be pretty easy to achieve their goal.  I mean the docs sure look like it would be easy.

Next I needed to write a little code to familiarize myself with the object model.  I fired up a device that most definitely has several certificates installed.


Then I wrote some simple code to give me an idea which of the six stores these fall into:

public void DumpCertCounts()
Debug.WriteLine(” Current User Local Machine”);

var userStore = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
var deviceStore = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
Debug.WriteLine(string.Format(“Root: {0} {1}”,

userStore = new X509Store(StoreName.My, StoreLocation.CurrentUser);
deviceStore = new X509Store(StoreName.My, StoreLocation.LocalMachine);
Debug.WriteLine(string.Format(“My: {0} {1}”,

userStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.CurrentUser);
deviceStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.LocalMachine);
Debug.WriteLine(string.Format(“CA: {0} {1}”,

Easy enough.  The problem was that then I actually ran the code.  This is the output.


Really?  Zero certificates in any store?  Was my code right?  Yes.  Did I target the right device from the debugger?  Yes.  Alrighty, so it seems that “existence of a class in the BCL” doesn’t necessarily mean “actual functionality is implemented.”  This doesn’t bode well.

Technically I don’t need to know what certificates are installed on the device for the customer’s request, right.  Sure, it would be nice to see if a cert is there before trying to install it, but we can always just wrap the call in a try/catch and ignore any exception thrown when we try to install a duplicate.  Not the ideal solution, but workable since this will be done infrequently.

I then generated some test certs with makecert.exe and pushed them to the device.  Now I needed to create code to import them, hopefully an import works better than enumerating existing certs. 

Let’s see, how would we bring in a cert?  How about the Import method on the X509CerticateCollection?  Oh, not supported in the CF.

Ah, but the Add method is, so I just need to create an X509Certificate and Add it.  Let’s see, the X509Certifiacte class has two static methods – CreateFromCertFile and CreateFromSignedFile.  Of course those aren’t supported in the CF.  That would be too easy.

How about from a constructor? Looks like the only constructor supported is the one that takes in a byte array.  What on earth is that byte array.  Oh, the example shows that it’s easy to get by Exporting from a certificate you already have.  How un-useful is that?

So it appears that the entire namespace in the Compact Framework is useless.  Actually worse than useless because I can’t create a direct replacement or I’ll end up with naming conflicts with the existing useless garbage.

So now I have to create the objects in the namespace and implement the methods required to achieve “import a certificate into the device store”.  The starting point is the C source code for the Certificates control panel applet you see above, which ships with Platform Builder.  It’s an ugly load of P/Invoking methods that deal with lots of pointers to structs that contains pointers to structs that contain pointers to structs that contain…you get the idea.

So I spent a day just getting the import of a CER file working (much easier than the PVK import is going to be) and my exact same test code now outputs this:


See, an implementation that actually does something.  I have no idea what was going on at Microsoft when this namespace was “implemented” or how it got out the door.  It definitely wouldn’t pass even the most rudimentary of functional tests.

This is a classic case of why I’d love to see the Compact Framework open/shared sourced.  I could actually go in and fix these things.

New MSDN Article

So it seems MSDN just release a new article on
Developing Stylus-Free Windows Mobile Professional Applications. I’m glad they’re wisely spending the very little resources they seem to use for mobile development on getting new and fresh information out.  I mean, it’s not like the same information has been available for 2 years already, and that the article was actually *submitted to them* for publication even before it was posted on the Web independently.  You go, MSDN!  If you’d like some other content you might look at any one of these (which we actually started publishing because MSDN apparently isn’t interested).

PayPal needs a lesson in customer service

So this morning we got an email from PayPal:

The PayPal User Agreement states that PayPal, at its sole discretion, reserves the right to limit an account for any violation of the User Agreement, including the Acceptable Use Policy. Under the Acceptable Use Policy, PayPal may not be used to send or receive payments or donations for obscene or certain sexually oriented goods or services. The complete Acceptable Use Policy addressing Mature Audiences can be found at the following URL:

We are hereby notifying you that, after a recent review of your account activity, it has been determined that you are in violation of PayPal’s Acceptable Use Policy regarding your website: Therefore, your account has been permanently limited.

If you have a remaining balance, you may withdraw the funds to your bank account. Information on how to withdraw funds from your PayPal Account can be found at our Help Center.

You will need to remove all references to PayPal from your website(s) and/or auction(s). This includes not only removing PayPal as a payment option, but also the PayPal logo and/or shopping cart. We thank you in advance for your cooperation. If you have any questions, please contact the PayPal Acceptable Use Policy Department at


PayPal Acceptable Use Policy Department PayPal, an eBay Company

Right off you can tell that they didn’t like something in our public Forums – a place where anyone who can enter a user name can post anything they’d like.  Offhand I don’t even know what was at that topic ID as Neil deleted it once he saw this notification.  We also use the PayPal account very, very rarely – I’d guess there were probably 5 transactions in the last 12 months, so how the hell they figured some violation by “reviewing account activity” is beyond my comprehension.

So Neil replid to them that we had no activity of the sort and that the material was removed.  Shortly after that we got this:

Dear Chris Tacke,

Based on the information provided to you in our last email your account has been permanently closed. Under the Acceptable Use Policy, PayPal may not be used to send or receive payments or donations for obscene or certain sexually oriented goods or services. The complete Acceptable Use Policy addressing Mature Audiences can be found at the following URL:

Unfortunately, we will be unable to overturn the limitation on your account. I do apologize for any inconvenience this issue may be causing you at this time.

PayPal Acceptable Use Policy Department
PayPal an eBay Company

Nice.  One “infraction” of material, which we didn’t post (again spammers are the lowest form of life) and which we removed, and the close the account with really no appeals process.  Not only do they charge fees way above what any other merchant provider charges and not only do they tend to monopolize eBay commerce, they evidently also employ a large number of morons. I like how they term “permanently closed” as a “limitation on your account.”

How does a company like this stay in business?

The costs of Wiki spam

Well I just read a simple question in the newsgroups that had to do with an InitializeComponents method exceeding the 64k JITted code maximum so I figured I’d post a link to the FAQ on the OpenNETCF Wiki.  I went to get the link and lo and behold once again the wiki was just full of spam.  Rather than go through it page by page an find the changes I pulled down the DB locally and eradicated the spam.  So there’s 45 minutes that I intended to spend working on a white paper that instead went down the toilet. 

I’m at the point that I’ve got no idea how to prevent the spam, and I just don’t have the time to routinely go in and clean the damned thing.  Don’t be surprised if in the near future the Wiki becomes unwikified and we just disable all posting or redirect it back to the forums. It seems that what had the potential for being a useful tool for agregating and disseminating information has been ruined by a few complete jackass spammers.

Sorry, no more commenting allowed

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.


New Blog Engine

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.

Success! For now anyway…

Well, I’ve added a CAPTCHA ( Completely Automated Public Turing Test to Tell Computers and Humans Apart  ) to the OpenNETCF Wiki.  That should just about kill all this Nigritude Ultramarine SEO Challenge (no link intentionally) bullshit going around from our perspective.  While the challenge itself is interesting, it’s taken many people down the spammer path to try to get to the top, making me hate the challenge presenter Dark Blue (again I refuse to link there).