Share via

Support Boundaries for Windows Mobile Programming (Developing Drivers, for example... Or even WiFi Programming)

  • Article

Now an "administrative" post... no code here but a clarification about some support boundaries, since sometimes it happens that as Microsoft Technical Support engineers we can't help developers and device end-users and here I'd like to try explaining when and why.

Above all, if you're in the Mobile-business you should know that Microsoft provides device manufacturers (OEMs) with a tool called “Adaptation Kit for Windows Mobile” (a special edition of “Platform Builder”): this contains about 90% of source-code of the Operating Systems and drivers’ sample codes. OEMs use this tool to adapt their Operating System to their hardware. They physically BUILD the platform after possibly having developed their own DRIVERS based on the samples that Microsoft provides: they might or might not follow Microsoft recommendations. All the DLLs you see in a Windows Mobile-based device have been compiled by the OEM, after possibly modifying the code provided by Microsoft as pure samples. Finally, it's completely up to the OEMs to choose which Security configuration select for their platforms. Therefore:

- when device end-users have a problem with a driver, Microsoft may well not be able to help, because we have no clue about how the OEM customized their platform

- when a problem is specific to a device model or manufacturer, chances are that it's due to a customization that OEM did and therefore Microsoft may not be able to help

- developing DRIVERs for Windows Mobile is technically achievable by anyone, but only OEMs are meant to do so and therefore they only can ask for support. Only the OEM or device manufacturer of a particular device is equipped to support device driver development on their platform, Microsoft does not have the knowledge of the device specific implementation necessary to be able to assist third parties developing device drivers which have a direct dependency on the custom In-ROM implementation of each different Windows Mobile device. It’s up to an OEM to give the opportunity to driver-developers to develop drivers for their platforms. Some OEMs prefer to not give this opportunity to avoid possible system instability. Some OEMs prefer to give it to have an “open and customizable” product. This is the reason why you should refer to OEM’s Technical Support in those cases.

On top of that OEMs may also provide a DEBUG build of their image: a RETAIL device doesn't have the debug symbols or the KITL-enabled features to allow an ISV Application Developer to get details of a problem. These are the reasons why Microsoft cannot help an ISV Application Developer to write a driver. Finally, Windows Mobile products don't have a DDK, and the necessary documentation to write a driver is provided only to Windows Mobile OEMs: the SDK doesn't cover drivers.

If your goal is to develop a driver, then the best way you may have is to partner with one or more licensed Windows Mobile OEMs, and ask them to sponsor you as a Windows Mobile In-ROM IHV (or ISV). The OEM would need to nominate you and Microsoft would then evaluate that nomination. If the nomination was accepted you would be eligible to receive the Windows Mobile OEM Adaptation Kit, so you'll have access to the same source and samples that the OEMs have access to.

 

Let's take another example: WiFi Programming. It’s up to the OEM to implement the WLAN stack (basically, the WiFi driver) by following or not the recommendations about WZC (Wireless Zero Configuration) APIs that Microsoft gives, and furthermore not every OEM allows developers to programmatically access the driver through a Private SDK. So, you'll have devices where you can even programmatically manage certificates associated to the WiFi connections, others where you can simply turn on\off the WiFi and others where you can't do anything... A Private SDK is a set of libraries that OEMs may create independently on the “standard” Windows Mobile’s SDK, available on any Windows Mobile-based device.

Even if the WLAN driver the OEM developed does implement the WZC interfaces, the WZC APIs are usually a feature that only OEMs use, in order to eventually customize their WLAN-settings applications. Technically it's possible for ISV Application Developers to use WZC APIs (only on those devices for which the OEMs decided to implement the WZC Standard interfaces, in any case), but it’s not "supported", i.e. you can't ask for support in case you need help.

An example about this was provided by OpenNETCF's guru Chris Tacke through the MSDN article Building a Wi-Fi Discovery Application with the .NET Compact Framework 2.0, however read: "[…] If a wireless card's driver is written to interface with WZC, it can be controlled and queried through this standardized interface, making configuration and status querying code consistent-regardless of the manufacturer of the adapter. While not all wireless cards are WZC-compatible, many are, and the high adoption rate is making it a defacto standard on both Windows-based desktop computers and Windows Mobile operating systems.".

Comments