Archive for June, 2007

I had a little bit of spare time over the weekend to start debugging some of the problems my initial builds of Google Gears for the Windows CE platform have had.

With reasonably minor tweaks to the source code to work around some differences between the Win32 API implementations for desktop Windows and Windows CE (HWND_MESSAGE doesn’t exist and you can’t create windows with a client rect of 0×0 pixels) I have managed to get the ResourceStore and ManagedResourceStore demos working.

Remember this cab file will only work on devices which use the Internet Explorer 6 for Windows Embedded CE web browser and not Internet Explorer Mobile, which is the web browser found on Windows Mobile powered Pocket PC and Smartphone Devices (see http://msdn2.microsoft.com/en-us/library/aa908125.aspx for further details). If you try this out on your device, please ignore the two ATL Asserts which occur while Internet Explorer initialises the Browser Helper Object – these are something I have yet to debug.

After getting a complete port to Windows CE devices running the full Internet Explorer 6 for Windows Embedded CE web browser, it is my aim to continue the porting effort to support the popular Windows Mobile powered PDAs, but since a number of required interfaces are not supported by this browser, it will involve more porting efforts which is why I am leaving it until the Internet Explorer 6 for Windows CE Embedded port is more functional.

The current list of features which are non functional or need improving in this port are:

Worker Pool – at present attempts to create worker pool tasks fail. I have not investigated why this is occurring but since I have used the Script Engine hosting APIs to hsot the Javascript interpreter in the past I don’t imagine it’s a major problem.

Local Server – This seems to be caching files properly as evidanced by the Resource Manager demos working, however the Asynchronous Pluggable Protocol implemented by Google Gears to intercept requests for URLs starting with http:// does not intercept requests while offline. Again I have not investigated this one yet, but at present this means Google Gears won’t operate in offline mode.

HTML Dialogs – Google Gears uses HTML based dialogs for permissions prompts and administration, currently these are failing to display properly. To work around this presently I have disabled then, meaning Google Gears allows access to the Google Gears API to any website which requests it.

Build Scripts – The main build script “build-wince.bat” needs improvment to make it work in more systems. Likewise the changes to the main makefiles need tidying up/rationalisation to make it easier for the main google-gears project to eventually accept the patches.

I am keen to hear from anyone which is interested in contributing to this porting effort in any size, shape or form.

I have been making a bit of progress on the Google Gears port for Windows CE. With a little bit of debugging and rework of some directory creation functions I needed to write yesterday, I have managed to get the Google Gears Database Demo working on a Windows CE powered device that uses the full internet explorer web browser as can be seen in the screenshot.

It’s still very early days, but it has been really exciting getting this initial functionality operational.

Things to investigate (and hopefully resolve) in the short term include:

The meaning of two ASSERTS which trigger when the Browser Helper Object is created

What is stopping the HTML based dialogs (such as the permissions prompt which asks the user if they want to grant a particular website access to using Google Gears) from displaying – at present I have had to disable these dialogs and temporarily hardcode the logic to allow all websites access to using Google Gears.

Determine why the default code for determining the directory where Google Gears should save database and local cached files is failing. Again I have temporarily hardcoded the path to match the installation folder for Google Gears.

Initial tests running this on a Windows Mobile device are not too flash (as expected). It seems a more significant porting effort will be required to get Google Gears operational on a Windows Mobile powered PDA or Smartphone. I am very keen to eventually get to this stage (if possible) but want to get this initial port operational first, since it should require less code changes, and will help iron out the majority of platform specific changes required.

PS: The other demos (local server and worker pool related) currently do not function properly in my port. I’m hopeful that they’re reasonably minor problems to fix, but won’t know until I investigate them further. A potentially more difficult problem which will need investigation is that offline mode currently doesn’t operate correctly, since requests for HTTP://… are not passed via Google Gears first, I’m hoping this will be due to the asserts I mentioned I am getting above.

Following on from my previous posting about my initial success I have started a new project on google code. The project is called google-gears-ce and is designed to be a straight port of the standard Google Gears plugin to Windows CE powered devices.

I imagine eventually the code could be merged into the main google-gears repository. However I thought having it as a seperate project would help initially until the code stabilises a bit, and functionality has been verified as working and the hacks removed etc.

It’s very early days yet (and I doubt anyone else can compile the code as is, but I would be keen to get some collaboration going to really see this project go somewhere.

So if this sounds like fun, get in contact with me, or download the source from the SVN Repository on Google Code. Be warned though, you will probably need to tweak build-wince.bat quite a lot to get this building on your machine, and the resultant binaries require some manual tweaks in the registry to make them work. I’ll try to tidy some of this up, and atleast document my thoughts within the wiki.

Recently Google announced a new browser plugin which allows developers to produce applications which can be accessed and interacted with while the browser is disconnected from the internet. This sounds like an exciting prospect for mobile devices such as Windows Mobile powered PDAs, where a solid connection to the internet can not be guarenteed, yet the versioning and deplyoment scenarios enabeld by a web based application are ideal.

Currently Google Gears supports Safari, Internet Explorer and Firefox on desktop class machines. However Google Gears is an open source project with source code available for download, so obviously I had to have a crack at compiling this for Windows CE powered devices.

As you can see from the screenshot attached to this blog posting I have had some success. With a little bit of work I am now able to compile gears.dll (the main google gears binary) for ARMV4I devices and can get Google’s own website to detect the Google Gears API being present within the browser.

It’s still early days, as there are various things I’ve stubbed out, and I havn’t verified any of the more advanced functonality actually works, but it seems a Google Gears port for Windows CE is acheiveable with reasonable ease.

In my previous post I mentioned that I would be discussing the naming nomenclature changes which have occurred within the current releases of Microsoft’s embedded products. Not a lot of details have been given for the reasoning behind the name changes, so the following is based upon my educated guesses.

Windows Embedded

The operating system previously referred to as Windows CE is now correctly refered to as Windows Embedded CE.

I believe this change is designed to further align the names of the various embedded operating systems Microsoft now develops. You will notice that they now all include the word “embedded” within their product names:

Windows Mobile is a platform which has over a decade of history in the market place. During this timeframe there has been numerious name changes and the recently released Windows Mobile 6 release was no exception.

Back in April 2000 the first Pocket PC operating system was released, and was named Pocket PC 2000. In October 2001 an improved version was released with the name Pocket PC 2002.

The Pocket PC operating system was designed to operate on “traditional” style touch screen enabled PDA devices. Somewhere within the Pocket PC 2002 timeframe Microsoft also developed the first operating system designed for more cellphone style devices (no touch screen, and limited keypad data entry options). This operating system was called Smartphone 2002. The operating system had great similiarity to Pocket PC 2002 but had some smartphone specific additions and limitations, mainly UI differences to cope with the user’s inability to tap on controls.

Since both the Pocket PC and Smartphone platforms were highly similiar (and shared a similiar code base), the 2002 releases were the last release to use seperate names for the two operating systems. Instead the next release was broadly labeled Windows Mobile 2003, and this was further split into three main “configurations”.

Although the operating systems were now technically termed “Windows Mobile 2003 Smartphone” and “Windows Mobile 2003 Pocket PC” many people still used the simplier “Smartphone 2003″ and “Pocket PC 2003″ naming nomenclature (including Microsoft in various places within the respective SDKs).

Windows Mobile 2003 was then followed briefly by Windows Mobile 2003 Second Edition which included some additional functionality such as native VGA resolution support. This was the last version of the operating system which included a year within the name.

The next operating system release was called Windows Mobile 5.0. This release saw a further merging of the two platforms with a larger varity of hardware keyboard styles and LCD screen sizes seen on both the Pocket PC and Smartphone platforms. The only real key differentiating factor now being that a Pocket PC has a touch screen while a Smartphone device does not (and a slightly different GUI).

Windows Mobile 6 Naming Nomenclature

As you can see the two device families – Pocket PCs and Smartphones have been steadily converging. In fact Microsoft intends to merge both operating systems into a single customisable platform with their next release.

The Windows Mobile 6 release can be seen as a first step at doing this by changing the naming conventions to ones which are more closely aligned to this desire.

The new naming nomenclature is as follows:

Windows Mobile 6 Professional – formerly a Pocket PC Phone edition

Windows Mobile 6 Classic – formerly a Pocket PC

Windows Mobile 6 Standard – formerly a Smartphone

You can see now that a “standard” device can potentially have all the features of a “professional” device except for a touch screen and (at present at least) they have a slightly different GUI look and feel.

I speculate that with the next Windows Mobile release (due in 2008) that some of the GUI differences will be removed or atleast made configurable. With this change the new naming conventions can be seen as quite logical. In particular it is reasonably easy to explain why the smartphone platform may be protrayed as being the “lesser equal” of a Pocket PC device, as given the choose between a Standard and Professional device, wouldn’t most people by instinct choose the Professional one.

One last thing worth mentioning for those with a pechant for detail is that Windows Mobile 5.0 is correctly referered as version 5.0 not version 5 (notice the lack of a minor version number). With Windows Mobile 6 on the other hand Microsoft have chosen to use a single digit version number. I assume this is because “point releases” are now more likly to be distributed as Adoption Kit Updates (AKUs) and hence reasonably invisible to end users (they are all “Windows Mobile 5.0″ devices), so essentially the version number is only changing for significant platform changes which deserve a major version number.

The relationship between the Windows Mobile and Windows CE operating systems is one which is not well understood by some ISV developers and the recent naming nomenclature changes have not helped.

So to answer the question “Is Windows Mobile 6 powered by Windows Embedded CE 6.0?” I will first have to explain the difference between these two products.

Windows Embedded CE is an operating system designed by Microsoft that targets a wide range of embedded hardware devices – set top boxes, wireless routers, robots and PDAs etc. Unlike the Windows XP or Vista operating systems which are quite fixed in their feature sets, Windows Embedded CE is heavily customisable by the OEM who choices to “install” it. By using a product called Platform Builder an OEM can pick and match which features of the operating system should be built into their device (from a catalog of 1000’s of components). In many cases if a feature doesn’t operate exactly how an OEM desires they have the option within Platform Builder to alter it’s behaviour and/or to replace the component completely with a custom one. This is quite a different process from the process you go through to install a copy of Windows XP on a desktop PC.

On the other hand Windows Mobile is a platform designed by Microsoft for smartphones and PDAs. A big part of this platform is a specialised operating system designed for use on smart devices (PDAs). Windows Mobile devices at their core are running the Windows Embedded CE operating system. In very simplistic terms someone within Microsoft has gone through the Platform Builder IDE and configured all the options until they came up with an operating system that all Windows Mobile devices will be based upon. Some parts of Windows Embedded CE have been replaced completely (for example the GUI shell which looks like Windows 95 complete with the desktop by default), and other components have been added (for example the Connection Manager APIs).

So in summary Windows Mobile devices run a variant of the Windows Embedded CE operating system. So it would make sense that Windows Mobile 6 would at it’s core have the Windows Embedded CE 6.0 operating system, right? Well if you answered yes to this question you would be wrong….

Windows Embedded CE 6.0 was released officially on the 1st of November 2006. It included a vast range of changes and additions, but the most talked about within the Windows Mobile space at least was the redesigned kernel which removes some long standing limitations. Rather than a 32 process limit, there is now support for up to 32,768 processes (in theory at least) and instead of a 32MB virtual address space, applications now have access to a 2GB address space.

So within Microsoft both developement efforts were going on internally at the same time. The Windows Mobile team decided that it was too risky to use the new version of Windows Embedded CE as the basis of what became Windows Mobile 6.0 so stuck with their current version and made a few alterations to it (in some cases back porting changes from Windows Embedded CE 6.0).

So we will have to wait until the next version of Windows Mobile (code named Photon and due for release in 2008) to get a Windows Mobile device which is powered by the Windows Embedded CE 6.0 operating system.

Some may have noticed that I have referred to Windows CE 6.0 as “Windows Embedded CE 6.0″ through out this blog entry. Windows CE and Windows Mobile have gone through minor naming nomenclature changes with the recently released versions to help further align related products. This will be the topic of my next posting.

On an initial flick through the handbooks there doesn’t appear to be many significant changes. However Microsoft has got more perscriptive in some areas such as deployment options for MFC based applications (which must be statically linked for logo certification).

If you’re starting out in Windows Mobile development these handbooks are a great guide for creating applications which have a native look and feel to them.

I encourage every developer to strive (where possible) to make their applications as compatible with the “Designed For Windows Mobile” certification requirements as possible. Your users will have an easier time utilising your application and will already be familiar with it’s basic operation. It’s also easier to pass the tests some time down the track if your application has been designed within them in mind from it’s inception.