Compartilhar via

The Windows Mobile Ecosystem for Developers

  • Artigo

July is a special time around Microsoft. It’s the start of a new fiscal year… which is kind of like the calm after the storm. A few weeks ago, this place was nuts…closing out business, writing performance reviews…clock ticking, time running out to meet those metrics. Once July hits, it’s a brand new game. A ‘tabula rasa’ or sorts. People take some vacation, breath deep for a change, focus their thoughts, and prepare for the re-orgs and business directives that always shake things up as we start again. In some ways, it’s like starting a new job every year and there are always unexpected surprises. It’s also a good time to tackle a post I’ve been wanting to do for awhile..

I field a lot of developer questions around Windows Mobile. Most are straight forward technology inquiries, but there are a number of topics that always lead to discussions about the Windows Mobile ecosystem and our relationship with device makers and operators. For example…

· When will the latest version of Windows Mobile be available for my phone?

· Why do some devices have features that others do not (e.g. - Camera quality, video codecs, available RAM & storage, etc.)?

· I found a bug… when can you fix it?

· How do I disable the security on this device?

· I’m building a SIP/VOIP client and want to integrate it with the phone.

· etc…

It’s an Ecosystem
On one hand, the diverse ecosystem of Device makers, Operators, and Independent Software Vendors (ISVs) creates a healthy pipeline of choice, opportunity, and competition. It’s is a core strength of our platform. On the other hand, the ecosystem comes with some clear (and not so clear) areas of ownership. It’s an important topic for developers to be aware of. I thought it might make an interesting post.

Desktop vs. Windows Mobile
We do our best to create an open platform that is accessible to everyone. Developers can use the same tools and technology they are familiar with (e.g. - Visual Studio, .NET, Win32). They don't have to jump through hoops or qualify for SDKs. Device makers all get the same platform building blocks from us to work with. This allows them to create new and innovative devices based on their industry expertise. ISVs are free to build anything they can dream up using the platform SDKs to run on those devices. The success of any platform depends on everyone working together from a pool of opportunity and the expertise they bring to it. Mobility is a big, big pool right now. The touchy part of any ecosystem comes into play when you start getting into "ownership". Who owns what.

With desktop PCs, you can pick and choose from a plethora of hardware vendors to find the best model and value for your needs. The machine may come pre-configured, but if you want to rebuild it yourself – upgrade the OS, reconfigure the system… go right ahead. You have complete control over the Windows installation on your home PC. Your PC manufacturer might own the BIOS but everything else typically loads from disk storage, so it’s very easy to change things around. This is the model most developers are used to.

Windows Mobile evolved out of the Windows CE model and it’s a very different animal from the desktop PC. CE is a highly customizable and componentized OS, designed for device makers to adapt to any kind of hardware they might produce. “Devices” may not even include storage or a display. CE is designed to work with small memory footprints, so device makers control the decision over what components are included in the device ROM. They could include ONLY the things they needed and save memory by leaving out the stuff they didn’t. That’s great for custom devices, but bad for developers who need a predictable API set and users who need a consistent experience. Windows Mobile is a Microsoft defined CE platform. While we let device makers customize many, many areas – we define base platform requirements that must be met, add a special shell, some core phone and platform applications, and enforce a logo test that device makers must pass before selling as a “Windows Mobile” device. This provides a consistent API set for developers who want to build applications and a consistent user experience as a marketable device. Unlike a PC, the platform still has to be adapted into a device ROM and the device maker is the only person who can do that. We can install an update to persistent storage, but we can’t permanently patch a device maker’s ROM. Only they can do that.

Who Owns What?
When you see an announcement like “Windows Mobile 6 was released today” and wonder why it takes 3-6 months before you see a device in the market, it’s because a lot of work has to happen to go from platform release to the commercialization of a device. The device might say “Windows Mobile” but Microsoft just a part of the team that makes it happen. At a very simplistic level, the release cycle looks something like this today:

1) Microsoft releases Windows Mobile Platform X.X and Adaptation Kit to all licensed device makers

2) Device makers “adapt” our platform to their new hardware (adding radio & drivers, power management, system plumbing, software customizations, select optional components, etc.) to create a Windows Mobile devicethey can sell through Operators

3) Operators negotiate with device makers to choose which devices they think will bring business to their networks

4) Device makers & Operators work together to “brand” chosen devices, include operator specific software/radio, decide on default security model, etc.

5) Devices must pass Microsoft logo testing to meet base level device quality and experience and carry the “Windows Mobile” brand

6) Devices must pass Operator acceptance testing and pre-market prep (sales, support, training)

Once a device is in market, the we continue to release updates on a regular basis to Device makers...

1) Microsoft releases Adaptation Kit Updates (think Service Packs for Windows Mobile) as well as new platform releases to Device makers

2) Device makers and Operators make a business decision on whether to build, test, and provide updates to devices in the market

 

Why It Matters to Developers
Why does the ecosystem matter? Understanding the release cycle helps makes sense of some of the questions around updates, features, bug fixes, and configuration differences you see with device out there. Those are universal questions that apply to both developers, IT, and end-users.

I also mentioned ”areas of ownership”. ISVs often build their business around technology “gaps”… needs that are not being addressed by anyone else. I touched on this a bit in previous blog posts with undocumented APIs. As part of the adaptation process, Device Makers have access to some APIs and customizations not found in the public SDKs. This includes areas like the phone application/canvas, cellular radio APIs, Wireless Manager, DRM, VOIP/SIP, driver development, and low level power details, etc. Most ISVs don’t develop in these areas, but some (e.g. – integrators, peripheral makers, security vendors) do. ISVs that would like to work in these areas need to have sponsorship from a licensed Device Maker who can help them get access to this information where applicable.

Rude Q&A

When will the latest version of Windows Mobile be available for my phone?
That’s a business decision that is entirely up to your mobile operator or your device maker to provide an update.

Why do some devices have features that others do not (e.g. - Camera quality, codecs, available RAM & storage, etc.)?
We enforce some very basic requirements to ensure a device meets a quality bar before it’s branded “Windows Mobile”, but we also leave a lot of room for Device Makers to make those decisions. As a result, you can find Windows Mobile consumer devices in just about every price range and specialized devices for every industry. Device makers choose to make hardware decisions for a number of reasons – cost, target or operator market, memory & driver footprint, etc. Choice is a good thing.

I found a bug… when can you fix it?
Please report it. Microsoft Support does not charge for support cases that are determined to be caused by a bug in our platform and we can’t fix what we don’t know about. Always test it on the emulators and also a comparable device by another manufacturer if you can. If it doesn’t repro (reproduce) in the emulator or a comparable device, it may be a device specific device problem that needs to be reported to the operator or Device Maker. When we fix a bug, that fix typically goes into the next platform update we release to manufactures or they can specifically request individual hotfixes. Bottom line though-- it’s up to the manufacturer to produce an update for their device. If it is a bug in our code, we’ll do our best to help you work around it outside of a manufacturer update.

How do I disable or change the security settings on this device?
Security is initially owned by the Operator (or whoever sells the device). If they don’t have their own root cert on the device, then they may defer to the Device Maker for control. If you are an administrator, you can look to Exchange or SCMDM to help enforce security policies but as a developer, your options may be limited for 2-tier (Standard) devices. See my previous post on Security for Developers.

I’m building a SIP/VOIP client and want to integrate it with the phone.
Anyone is welcome to build a stand-alone client, but in order to integrate with the existing phone application, you need to be working with a licensed Device Maker.

Do I need to be working with a Device Maker to build a LAP?
No, LAP documentation has been released as part of the public Windows Mobile SDK.

What tools do I need to build drivers for Windows Mobile?
In theory, the model isn’t much different from CE and it’s possible to build a driver using Visual Studio – however, it’s not supported unless you are working with a Device Maker and have the proper level of debug tool and documentation.

Additional questions posted by readers…(thanks for the feedback)

Why developers should create software for Windows Mobile if they have to pay 50-60% of fee to intermediary [software distribution] companies … while Apple takes only 30% ?

Developers are not required to pay anything to distribute software on Windows Mobile. Many ISVs take orders off their own web site and distribute corporate apps without ever talking to someone from Microsoft or a distribution partner. The real question is how do you maximize your sales reach? Is it worth paying a software distribution portal to help you reach a larger audience? Many developers think so and this is also an open ecosystem. Software distributors set their own prices and many offer a sliding percentage based on the number of sales they help you make. You can pick the distributor that provides the best deal to help you reach your audience or do it yourself. Competition is a good thing. We don’t force you to sell through Microsoft. A good place to start looking – the Windows Mobile Catalog, which links to several distribution partners. If you choose to list your apps in the Microsoft catalog, we can share that information with our distribution partners and help you extend your reach.

Why still it is not possible to purchase Windows Mobile software from within Windows Mobile - like it is with iPhone ?

It is possible. There are actually several on-device software catalogs out there that allow you to purchase apps right from your phone. Operators sometimes add this in and most of our distribution partners provide client catalogs you can run from your phone. We have a lot of distribution partners and channels to get software so forcing a device to use ONE or list ALL of them doesn’t really make sense. Operators can preconfigure their devices with the client of their choice if they want to go this route. Would it be easier to have a single point of software distribution for everything to make it easy on end-users? Maybe – but as a developer, I don’t really like the idea of being locked into a single distribution channel. Our partners deserve some options. We do hear this a lot though and it’s something we’re working on to make purchasing easier on end-users.

On a Final Note
For some ISVs, this post will be a big snoozer. For others, this is a big deal. Anytime I get into the ecosystem discussion with ISVs, I try to pick my words carefully. Most of the time, it’s a developer who wants to re-engineer some part of the platform that only the Device Maker has access to. Sometimes you need to work with the Device maker…sometimes we can help. We originally did not expose LAP interfaces to ISVs. Our security ISVs set us straight and now it’s public info. My goal is to help share knowledge with those that have struggled in this space and get some good feedback. I also want ISVs to understand the ecosystem so they can help influence it in the right places. I hope this info helps.

Best Regards,
Reed

Comments