Archive for the ‘General Development’ Category

No GPL software in Windows Mobile Marketplace?

Tuesday, July 21st, 2009

Symbol suggesting GPL v3 is bannedI was just looking at the details surrounding the upcomming app store for the Windows Mobile platform (which seem to change almost weekly). It really seems Microsoft are going out of their way to make it unfriendly for developers making software that they want to publish for free, or as open source.

Not only will free applications require a $99 USD certification / code signing fee (counting towards the 5 free signings you get as a one time bonus until the end of this year) but Microsoft also appears to have restrictions on which licenses you can choose to release your products under.

Section 7 of the Windows Marketplace Application Provider Agreement states that you represent and warrant to Microsoft that:

Your Application does not include software, documentation, or other materials that , in whole or in part, are governed by or subject to an Excluded License, or that would otherwise cause the Application to be subject to the terms of an Excluded License

What’s an Excluded License you may ask? Well it’s defined earlier in the same document as:

“Excluded License” means any license requiring, as a condition of use, modification and/or distribution of the software subject to the license, that the software or other software combined and/or distributed with it be (a) disclosed or distributed in source code form; (b) licensed for the purpose of making derivative works; or (c) redistributable at no charge. Excluded Licenses include, but are not limited to the GPLv3 Licenses. For the purpose of this definition, “GPLv3 Licenses” means the GNU General Public License version 3, the GNU Affero General Public License version 3, the GNU Lesser General Public License version 3, and any equivalents to the foregoing

Putting aside any potential issues or feelings surrounding GPL v3 for the moment, don’t the first three conditions seem overly broad and vague to you?

I’m no lawyer, but that seems to be an OR between the clauses a, b and c. The section also appears to apply not only to any potential modifications of your software, but also the “software subject to the license” itself. The more times I read this section the more interpretations I can make as to its intent and meaning.

In comparision a similiar clause within Apple’s iPhone SDK Agreement is significantly more clearer in intent and purpose:

If Your Application includes any FOSS [free and open-source software], You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the SDK to be subject to any FOSS licensing terms or obligations.

That to me seems like it’s much more easier to interpret and understand as a developer.

As an example, would the Microsoft agreement allow me to publish an application via the Windows Marketplace which I also want to release in source code form via my blog (under a license that requires source code to any modifications to be provided)? As some one who contributes source code to the community, I would be interested in knowing the answer.

What’s up Microsoft?

Programmatically changing the Device Name

Monday, December 15th, 2008

Screenshot of Set Device Name applicationFor some Line of Business (LOB) applications intended for tightly controlled deployment environments you may want to programatically set the Device Name of each PDA. This blog post discusses one common technique for achieving this.

Changing the Device Name

A Windows Mobile device stores the Device Name in the registry underneath the HKEY_LOCAL_MACHINE\Ident\Name value. This means we can make use of the Microsoft.Win32.Registry class to change the value and hence update the device name.

A code snippet for achieving this could take the following form.

using Microsoft.Win32;
 
void SetDeviceName(string deviceName)
{
  // Change the device name of the current Windows Mobile device
  using (RegistryKey key = Registry.LocalMachine.OpenSubkey("Ident", true))
  {
    key.SetValue("Name", deviceName);
  }
}

Verifying the change

The device’s TCP/IP stack utilises the device name as the device’s hostname. So an easy way to verify that the change has been successfully made is to ask what the current hostname is. This process is demonstrated below.

// Determine the current host name
using System.Net;
MessageBox.Show(Dns.GetHostName(), "Current Device Name");

Be aware however that certain parts of the operating system may require additional steps to be taken in order for them to read the updated information stored in the registry. Refer to the article titled “Naming a Device” available on MSDN for additional guidance.

Sample Application

[Download setdevicename.zip - 9.64 KB]

A small sample application is available for download. It demonstrates setting the device name programatically and includes two buttons to enable the user to verify that the change has been correctly made.

The first button asks the DNS subsystem for the current host name, while the second makes use of a technique discussed previously to display the Device ID control panel applet.

Another way to verify the change has been made is to simply connect the PDA to your desktop PC via ActiveSync. The main ActiveSync window displayed on the PC should display the device name in the top left hand corner.

SPARK your (Windows CE) Imagination

Thursday, April 17th, 2008

Microsoft Windows Embedded SPARK Your Imagination logo

First announced with the release of Windows Embedded CE 6.0 R2 the SPARK initiative is designed to provide a source of cheap Windows CE development tools to hobbyists and other non commercial users such as academics.

As Mike Hall mentions in a recent blog entry the first development boards packages under this initiative are finally starting to become available. This announcement neatly dove tails into yesterday’s discussions about low cost development tools for Windows Mobile. In Mike Hall’s own words:

Windows CE has traditionally focused on professional embedded developers, sure we’ve had the evaluation kits for developers to try out the development tools and operating system, but these time out after 180 days, which is ok for commercial developers to make a decision about moving forward with a Windows CE based project but isn’t ideal for the community/academic/hobbyist developer.

The Spark Your Imagination program offers non-commercial developers low cost development boards (both X86 and ARM based options available) combined with fully licensed copies of Visual Studio 2005, and the latest release of Windows CE (i.e. Platform Builder) for essentially the cost of the hardware.

More details, including links to the available hardware options, can be found on the Spark Your Imagination website.

Free Windows Mobile Development Tools?

Wednesday, April 16th, 2008

What tools do you use to develop your Windows Mobile applications? Today I received the following question:

I am looking to develop VB.NET applications for WM5, but I am on far too tight a budget to afford Visual Studio. Is there a way to use VS2008 Express for WM5 development, or is there another free way to do this?

How would you answer this question?

When I first started developing applications as a hobbyist for Palm OS (and then eventually Windows Mobile) I utilised free tools. Free (or at-least cheaply) available IDEs and compilers were a large factor in getting me started in this area of development that has now turned into a professional career. A lot of my friends got started in the same way and Dale Lane mentioned a similar scenario in his recent interview.

I am interested in discussing what tools hobbyists are currently utilising as they discover they can develop custom applications for their PDAs.

At present the main options for Windows Mobile development are most likely as follows:

  • Embedded Visual C++ v4.0 – A free download that supports C and C++ development only. Doesn’t provide full support for newer versions of Windows Mobile and is fairly unsupported these days. A number of open source projects use this tool specifically because it’s a free download.
  • Visual Studio 2005 Standard Edition (or above) – A non free IDE that supports native (C/C++) and managed (C#/VB.NET) development.
  • Visual Studio 2008 Professional Edition (or above) – A non free IDE that supports native (C/C++) and managed (C#/VB.NET) development (adds support for .NET CF 3.5 development).

This means to develop a VB.NET application for a Windows Mobile PDA you require to purchase a copy of Visual Studio. The free Express editions of the IDE are not suitable.

If someone was interested in mucking around on an occasional Saturday afternoon and slowly learning about Windows Mobile development how would you suggest they go about it without occurring “significant” expense? I guess the 90 day trial version of Visual Studio 2008 Professional is possibly an option, but that does not leave too many weekends before the free license expires.

Is the lack of low cost development tools a problem? Are hobbyists an important part of the Windows Mobile ecosystem? What sort of developer would you classify yourself as? What helped you get started in programming PDA applications? Did you get started in your spare time or as part of your day job? Are there alternative development tools worth taking a look at?

I’m interested in your thoughts on this topic. Please post a comment to this blog entry and join the debate!

How to detect Windows Mobile 6.1 (Detecting AKUs)

Monday, April 7th, 2008

Screenshot showing the AKU of a Windows Mobile 6.1 device being reportedWindows Mobile 6 and 6.1 both share the same version of the Windows CE kernel (5.2) meaning that previous techniques to determine the version of Windows Mobile on a device need to be modified to differentiate between these two most recent versions. It is not enough to compare the major and minor version numbers of the kernel. One possible technique is to programatically determine the current AKU in use by the Windows Mobile device as outlined by this blog posting.

What is an AKU?

An Adoption Kit Update (AKU) is an update to the Windows Mobile operating system which is akin to a service pack for a desktop version of Microsoft Windows. An AKU is usually a vehicle to ship an extra feature or fix required by a specific Windows Mobile device under development.

Typically the features enabled by an AKU require specific hardware (such as a new type of keyboard) meaning it does not make sense to make AKUs available to older devices. Occasionally an AKU enables significant features which are of a software nature. For example AKU 2.0 for Windows Mobile 5.0 introduced the Messaging and Security Feature Pack (MSFP) which enabled closer integration with Exchange Server 2003.

Determining the AKU

Since an AKU typically needs specific hardware and generally doesn’t alter the end user behaviour of a device it isn’t typical to need to detect a device’s AKU. However when you must detect the AKU of a device you can look within the HKLM\SYSTEM\Versions registry key for a string value called not surprisingly Aku.

An example of how you may access this registry value is shown below:

using Microsoft.Win32;
 
private string GetAKUVersion()
{
  RegistryKey key = null;
  string aku;
 
  try
  {
    key = Registry.LocalMachine.OpenSubKey(@"SYSTEM\Versions");
    aku = (string)key.GetValue("Aku");
    // Most of the time the AKU string is prefixed with a .
    // so remove it.
    if (aku.StartsWith("."))
      aku = aku.Substring(1);
  }
  finally
  {
    if (key != null)
      key.Close();
  }
 
  return aku;
}

The Channel9 Windows Mobile Developer Wiki contains a list of AKUs that enables you to match up AKUs with OS build numbers which is another way to determine which AKU is present.

Sample Application

[Download akudetection.zip - 10 KB]

A small example application is available for download that demonstrates making use of the GetAKUVersion function outlined above to display the Windows CE Kernel and Adoption Kit Update version numbers for the device the application is currently running on.

If you run this application on a Windows Mobile 6.1 device you will notice that the AKU version is reported as 1.0 (or higher) compared to older Windows Mobile 6 devices which have an AKU version below 1.0 (such as 0.4.2). Both versions of Windows Mobile report the use of various builds of the Windows CE 5.2 kernel.

.NET Compact Framework Platform support

Wednesday, January 16th, 2008

.NET Framework logoQuick! Will .NET Compact Framework 2.0 run on a Windows CE 4.1 powered device?

Today while helping someone with a development question, I rediscovered the Devices and Platforms Supported by the .NET Compact Framework page within MSDN. This page contains two handy charts. The first lists each .NET Compact Framework release and the various versions of Windows Mobile Pocket PC, Windows Mobile Smartphone and Windows CE it supports. The second table lists the version of .NET Compact Framework you can expect to find pre-installed in ROM on a given device.

A lot of questions within online forums come down to what platform support there is for a given .NET Compact Framework release. This page will come in handy in determining the compatibility and deployment requirements for applications using a particular .NET Compact Framework version. It’s particularly handy because it covers a number of corner cases not seen in similiar charts found elsewhere.

Updated Windows Mobile 6 SDK Documentation

Tuesday, August 14th, 2007

The Windows Mobile 6 SDK documentation has recently been updated on MSDN. The new documentation includes a couple of new navigation features which hopefully will make the documentation more discoverable and easier to navigate.

I particularly liked the topic index, which seems to be the work of John Kennedy. His recent posting discusses what’s changed since the last release.

The other thing which has started in the last few months is Jim Wilson’sHow Do I?” webcast series. These appear to be worth keeping an eye on. I like the fact that each video is a bite size tip which covers one topic/problem in depth.

Determine which version of the .NET Compact Framework is in use

Monday, August 13th, 2007

Yesterday I outlined how an end user can determine which version(s) of the .NET Compact Framework are installed on a device. Sometimes it can be useful to query which specific version of the framework an application is currently running on. This could be used for instance, in automated bug report forms to provide your support staff with an accurate picture of the environment your application is being utilised within.

Within an application you can simply query the Envrionment.Version property to determine the version of the CLR your application is running on, for example:

MessageBox.Show(Envrionment.Version.ToString(), "CLR Version Number");

The version property is an instance of the System.Version class. To check if your application is running on a specific version of the .NET Compact Framework you can construct an instance of the Version class to represent the desired version number (see yesterday’s entry for a table) and perform a simple comparision, as the following example demonstrates:

Version targetVersion = new Version("2.0.7045.0");
if (Envrionment.Version == targetVersion)
     MessageBox.Show("You are running .NET CF 2.0 SP1", "Status");

What device is my application running on?

Saturday, July 21st, 2007

Windows Mobile comes in two main variants, traditionally called Pocket PC and Smartphone. If your application must run on both platforms, it may be necessary to detect at runtime what type of device your application is running on. This blog entry will discuss techniques .NET Compact Framework developers can use to achieve this.

Detecting the Platform
The .NET Compact Framework does not have any built in support for determining the type of device the application is running on, so we need to develop a small class library to query this information ourself.

The first platform we can check for is the desktop PC. We may want to determine if a user is attempting to run our Compact Framework application on their laptop, Tablet PC or Ultra Mobile PC (UMPC) for example.

// Returns true if the application is running on a
// desktop version of the Windows operating system
public static bool IsDesktopWindows
{
  get { return Environment.OSVersion.Platform != PlatformID.WinCE; }
}

As you can see it is reasonably straight forward to determine if we are running on a desktop version of Microsoft Windows. We simply query for the platform id of the operating system via the Environment.OSVersion property and return true if it does not equal Windows CE.

By switching the conditional around we can also detect if we are running on a device that utilises a Windows CE based operating system. This is what the IsWindowsCE property does, as shown below.

  // Returns true if the application is running on a
  // device powered by some form of Windows CE based
  // operating system.
  public static bool IsWindowsCE
  {
    get { return Environment.OSVersion.Platform == PlatformID.WinCE; }
  }

As discussed in my blog entry “Is Windows Mobile 6 powered by Windows Embedded CE 6.0?“, Windows CE is an operating system that can be further customised to develop particular variants, such as Windows Mobile. Once we know that a device is a Windows CE powered device, we can query the OS for some additional information which will help us narrow down the type of device even further.

  // Returns true if the application is running on a
  // Windows Mobile Standard (i.e. Smartphone) device
  public static bool IsWindowsMobileStandard
  {
    get
    {
      return IsWindowsCE()
        && (NativeMethods.GetPlatformType() == "SmartPhone");
    }
  }
 
  // Returns true if the application is running on a
  // Windows Mobile Professional (i.e. Pocket PC Phone
  // Edition) device. Also returns true for Windows
  // Mobile Classic devices (no cellular radio).
  public static bool IsWindowsMobileProfessional
  {
    get
    {
      return IsWindowsCE()
        && (NativeMethods.GetPlatformType() == "PocketPC");
    }
  }

The NativeMethods.GetPlatformType() method used in the last two properties is one which we will have to develop ourself. It utilises a Platform Invoke (PInvoke) call to access the SystemParametersInfo operating system API. By querying the SPI_GETPLATFORMTYPE system parameter we can get a string back which enables us to differentiate between the Pocket PC or Smartphone platforms. Since the implementation of NativeMethods.GetPlatformType() is rather long I have not included the source code here, please see the sample project available for download for its implementation.

Notice that as it stands our IsWindowsMobileProfessional property also returns a false positive, since it will return true if the device is a Windows Mobile Classic device (i.e. a Pocket PC without a cellphone). We will correct this issue in a couple of moments.

Detecting the Emulator
By querying yet another system parameter (SPI_GETOEMINFO) we can determine if our application is running on a physical device, or within a Device Emulator running on a desktop PC.

This can be a useful thing to tell. For example, you could disable device specific code (such as barcode scanner interfacing logic) while running within the emulator.

  public static bool IsEmulator()
  {
    return (NativeMethods.GetOEMInfo() == "Microsoft DeviceEmulator");
  }

Detecting device specific features
If possible you should detect specific device features (such as cellular radio presence, screen size or orientation) instead of detecting platform types. This will make your application more robust, since over time it is possible that some of the differentiating features between the platforms will disappear.

To differentiate between Windows Mobile Professional (with cellphone) and Windows Mobile Classic (without cellphone) devices, we will have to detect the presence of a cellular radio.

For some device features there are no nice APIs available to detect their presence. In this case you need to probe the device to determine if DLLs or registry keys specific to that device capability are present on a given device.

Prior to Windows Mobile 5.0 the recommended method to determine if a device had a built in cellular radio was to detect if a DLL called phone.dll was present within the device. This could be achieved as follows:

using System.IO;
 
public static bool HasPhone()
{
  return File.Exists(@"\Windows\Phone.dll");
}

With this additional method we can now alter our implementation of the IsWindowsMobileProfessional property to check that a cellular radio is present. Likewise we can create a new IsWindowsMobileClassic property which returns true only if HasPhone() returns false.

As the Windows Mobile platform grows, and new versions are released, the number of device features with standardised detection mechanisms typically improves. With Windows Mobile 5.0 or above, the OS provides us with a nice managed API we can call to determine if a cellular radio is present, as can be seen in this alternative implementation of the HasRadio() method.

using Microsoft.WindowsMobile.Status;
 
public static bool HasPhone()
{
  return SystemState.PhoneRadioPresent;
}

There are a number of other properties available within the SystemState class which can be used to detect other device features, such as a camera. If developing for Windows Mobile 5.0 or above it is defiantly worth looking into this class.

Detecting Platform Versions
Sometimes detecting that you are running on a Windows Mobile Professional device is not enough. You may desire to display a warning prompt for example, if you application is running on an operating system version newer than the one you officially support.

To do this you must use the properties we have developed above (IsWindowsMobileProfessional, IsWindowsMobileClassic etc) to determine the platform your application is running on and then compare the current operating system version number, obtained via the Envrionment.OSVersion property, against a list of known Windows CE versions for that platform.

For example with the Windows Mobile releases we know that the following Windows CE operating systems were utilised:

Platform Release Windows CE kernel version
Windows Mobile 6 5.2
Wndows Mobile 5.0 5.1
Windows Mobile 2003 SE 4.21

So we could determine if an application was running on a Windows Mobile 5.0 Pocket PC by implementing the following check:

  if (IsWindowsMobileProfessonal 
    && Environment.OSVersion.Version.Major == 5
    && Envrionment.OSVersion.Version.Minor == 1)
  {
    MessageBox.Show("This is a Windows Mobile 5.0 Pocket PC");
  }

In the future
As discussed by Daniel Moth the next version of the .NET Compact Framework (v3.5) will have a new property within the SystemSettings class called WinCEPlatform. This property contains one of the following enumerated values:

  • WinCEGeneric
  • PocketPC
  • Smartphone

This will allow you to detect the platform your application is running on quite easily, without needing to write custom code as we have needed to do.

Example

I have put together a
small demonstration application which demonstrates how to detect the various platforms your .NET Compact Framework application may run on.

If you load the application up within Visual Studio 2005 you should be able to switch between the various platforms via the “Change Target Platform…” option within the “Project” menu. When you then launch the application within different emulators you should be able to see the code detecting which platform the application is currently running on.

If you have a need for detecting the type of platform your application is running on feel free to use a copy the “Platform.cs” file within your own projects.

Development Tools for Windows Mobile Devices

Sunday, July 8th, 2007

Photo of box for Microsoft Windows CE Toolkit for Visual C++ 6.0 productA common question asked in online support forums is which version of Microsoft development tools are required for a device powered by a particular version of Windows Mobile. With the pace technology is changing, there are numerous Microsoft products which can be utilised to develop mobile applications.

Native Development
If you are developing in native code (C or C++) you have a number of choices. Back in the early days (before Pocket PC or Windows Mobile), development was achieved via an extension to the desktop version of Visual Studio 6.0. This extension was called the Microsoft Windows CE Toolkit for Visual C++ 6.0.

The first Microsoft development environment targeted specifically for mobile developers was called Embedded Visual C v3 (EVC3). This IDE was specifically designed for developers working on Windows CE and Pocket PC devices. The functionality and UI was very similar to Visual Studio 6.0, but was slightly extended to support development against multiple device types and deployment/debugging on actual devices. Embedded Visual C version 3, via the installation of additional SDKs supported producing applications for Pocket PC 2000 and 2002 devices as well as older Handheld PC (HPC) and Palm PC platforms.

The next upgrade was to Embedded Visual C v4 (EVC4) which was released in 2003, and only supports Windows Mobile 2003 devices. This is not to say that applications developed with EVC3 would not run on Windows Mobile 2003 devices, the Windows Mobile operating system is highly backwards compatible, meaning that applications developed for previous versions of the operating system will in most cases still run on newer versions of the operating system unmodified.

However developing applications for newer versions of the operating system using older tools which don’t explicitly support them has two main problems.

  • Lack of debugging and deployment support – you can compile applications which will run on the new operating system version, but the IDE will not be able to automatically deploy your application to a device, and you will not be able to debug your application running on a real device.
  • Lack of access to new APIs and features – For example Windows Mobile 2003 SE introduced dynamic screen orientation support (toggling between landscape and portrait), but if you use EVC3 and utilise the Pocket PC 2002 SDK you will not have easy access to the APIs which support this, since the Pocket PC 2002 header and library files will not include the information required to use them.

EVC3 and EVC4 are very old tools, which are reasonably unsupported by Microsoft at this stage. EVC3 is effectively unsupported and EVC4 is very close to being near the end of it’s mainstream support life-cycle (see Microsoft Support Lifecycle for Development Tools page for further details). They are fairly non functional under Windows Vista for instance, with Microsoft’s recommended practice being to use the tools within a Virtual Machine running a copy of Windows XP, which has its own problems.

The replacement for Embedded Visual C has been Visual Studio 2005. Visual Studio 2005 is the first version of Visual Studio .NET which has included support for C and C++ development for smart devices, which is Microsoft’s current term for PDAs and embedded devices running Windows CE. While EVC3 and EVC4 were available as free downloads, Smart Device development is not available in the free versions of Visual Studio (such as Visual Studio 2005 Express), meaning developers must purchase a copy of Visual Studio 2005 Standard or higher to develop for Mobile devices (see Microsofts’s Product Feature Comparision page for further details on the various SKUs of Visual Studio 2005).

Out of the box Visual Studio 2005 only supports developing applications for Windows Mobile 2003 devices. However additional SDK downloads enable you to develop applications targeting the additional features present in the Windows Mobile 5.0 and Windows Mobile 6 releases of the operating system, with full debugging support etc.

In summary for native development you are best to

  • use EVC3 for Pocket PC 2000, 2002 (and older)
  • use EVC4 for WM 2003
  • use VS2005 for WM2003, WM5.0, WM6

Managed Development
Visual Studio .NET 2002 saw the start of Compect Framework support within Visual Studio. Support was included via an additional download which was called the Smart Device Extensions (SDE) which was only available as a beta. This development environment supported development for Pocket PC 2002 devices which utilised Compact Framework version 1.0.

Visual Studio .NET 2003 was the first version of Visual Studio .NET to officially support the Compact Framework, having the Smart Device Extensions functonality included in the core product. Although it was functional it was not tightly intergrated, for example the GUIs designed in the form designer had little resemblance to the look and feel of the controls used on the actual device.

Visual Studio 2005 introduced a number of improvements for managed developers, as well as a significantly improved forms designer which had the same look and feel as actual devices, it also included additional support for Compact Framework version 2.0, as well as the existing support for version 1.0.

Visual Studio 2008 will support Compact Framework v2.0 and Compact Framework v3.5 which will be released in the same timeframe. For those wondering, there will be no version 3.0 of the Compact Framework. The Compact Framework team decided to skip version 3.0 in order to keep “in sync” with the versioning of the desktop variant of the .NET framework which has already had a version 3.0 release.

In summary for managed development you are best to

  • use VS2005 for CF1.0 and CF2.0
  • use VS2008 for CF2.0 and CF3.5 (when it becomes available)

Summary
Most development tools support atleast two versions of the Windows Mobile operating system. The latest version and the previous one. As new versions of the Windows Mobile devices become available your applications should run on the devices, but you will not be able to debug your applications via the IDE. You will typically need to upgrade to the latest version of Visual Studio for this to function.

The Windows Mobile Team Blog has a posting which manages to condense the information I have outlined here into a neat looking table in a posting titled “Windows Mobile Tool Support Matrix“.