Now on Codeplex: the OpenNETCF CAB Installer SDK

Ages ago I created an SDK that allows you to extract device CAB files and create a replacement for wceload if you wanted (we used this on a couple customer applications).  We also tried to sell it as an experiment in “value-based pricing“.  Well the experiment showed, largely, that people would pay the minimum and very, very rarely come back and pay anything more so either it was of low value, or people are just cheap.

At any rate, I don’t feel like maintaining it internally any longer so it has become yet another project that I’ve open sourced for the community at large.  The full download is now available over on Codeplex.

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.

I told you Windows CE wasn’t dead

There has been rampant speculation for some time that Windows CE was dead and that Microsoft was abandoning it.  The announcement that Windows 8 will run on ARM only added fuel to it, despite the fact that Win8 is undoubtedly going to have a large, desktop-style footprint and no capability for real-time operation.  Well, Microsoft finally decided to tell us what many of us suspected for some time.  Windows Embedded Compact (i.e. Windows CE) is still on their product roadmap.  It will have a v Next, and it will be supported in newer versions of Visual Studio (well native development will be anyway).  Read the full press release here.

Windows Embedded Compact 7 Released (not killed)

In case you missed the pretty quiet announcement this week, Windows CE Windows Embedded Compact (love those marketers) 7.0 was released to manufacturers this week.  You can download the eval as well.

There are some nice new features in this release, but what’s more important is that it’s actually been released.  There seems to have been a lot of speculation lately about the demise of CE, and this concretely says “no, CE is not dead”.  This release means that it is officially a supported product for the next 5 years with extended support for another 5 after that.

I spent most of this week in Redmond talking with some of the teams and I came away with a pretty positive impression about the future of CE Compact.  Microsoft has failed lately to provide information about the future and direction of Compact, and that lack of communication has led to a lot of people making implicit assumptions that we’ve been reassured are not true.

I don’t have any specifics that I can share right now, but I can say that I personally would have no qualms about recommending CE 7 Embedded Compact 7 and the Compact Framework as a base for new products that you intend to ship for the next decade. 

I’ll share more news as I get it.

Padarn Host implementation for MTConnect Agent SDK

The MTConnect Agent SDK I published last week is really only useful if you implement a Host to actually serve up the data.  The IHost interface isn’t complex, but if you don’t have an example, it’s a bit difficult to understand my intent.  I’ve published a desktop implementation that uses Padarn as the web server.  In theory the same code should work under Windows CE as well, but I’ve not yet tested it to be certain.

Drawing Performance with a Rotated Display

In one of the mailing lists I’m on today, someone noted that on their Windows Mobile device the performance of GDI is much better in portrait mode than it is in landscape mode and was wondering why.  The reason is actually pretty simple.  Think of the image on the screen as just a contiguous stream of bytes (which is probably is).  The physical display needs to get that data and “paint” it.  Displays are engineered to essentially take in the data in a linear fashion, left to right, top to bottom.  So it’s a pretty simple operation to just send out the framebuffer data to the display.

Now consider what happens if you want the display rotated 90 degrees. Remember, the display requires the data top to bottom, left to right, as it will show on the screen.  To get it into that state you have 2 options.  You can either A) rotate the data as you take it out of the frame buffer and send it to the display or B) rotate all calls to draw into the framebuffer.  In either case you have to do a matrix transform, which is expensive and gets worse the larger your display gets (so a VGA device will be more affected than a QVGA device).

Of course some devices have hardware acceleration that can greatly improve things by having matrix functions right in the silicon, but that still requires that the OEM actually modifies the driver to use that function (you’d be surprised how many don’t).

So how bad is the performance penalty?  Well, since I like to actually quantify stuff I decided to resurrect an old GDI test app I had and rework it for this.  The results of my testing, as well as tests sent in from other people (if you want to add a test to the table, send me your results):

Device Processor OS Portrait Landscape Penalty
Axim x51 PXA270 WinMo 5 188 ops/s 77 ops/s 59%
Asus P750 PXA270 520MHz WinMo 6 Pro 241 ops/s 55 ops/s 77%

As you can see, there’s a significant price to running rotated.

The test application (source and ARMv4I binary) is available here (10.46 KB)