In the past week I’ve seen several post on the MSDN Smart Device forums asking essentially the same question.  Some one has developed (or will develop) a program for one platform (Windows Mobile, Blackberry, iPhone) and wants to make the program run on the other.  I’ve answered the questions as I’ve encountered them, but since it is a frequent question I decided to write a post about it so that I can refer people back to an answer as the question comes up.

What is a Platform?

A platform is a collection of functionality along with the methods for accessing that functionality provided to support an application. Traditionally platforms have been viewed as a combination of hardware and software; a software application would require a certain software platform (the operating system) running on a certain hardware platform (the physical computer with a certain processor).  While that definition is still applicable presently we also have what would be considered pure software platforms; a developer targeting a browser can target a specific web standard as their platform with little to no concern for the hardware on which it is run.  It is important to also note that platforms can be layered; one platform can exists on top of another. For mobile devices I can name 5 platforms; Windows Mobile, iPhone OS X, Blackberry, Android, and Symbian.  As I type this

How do I make this program developed on platform X run on platform Y.

Unfortunately in most cases the answer to this question is “you don’t.”  You will need to rewrite your application for the other platforms on which you need for it to run. What’s the workaround for this?  Well, as I mentioned in my definition for a platform, “platforms can be layered; one platform can exists on top of another.”  If you have two dissimilar platforms and if those two platforms can support the same software platform then you can target that common platform and end up with a single application that runs on multiple platforms.

Web browsers are going to be the most common platform that you can target.  But browser applications have their limitations (those limitations are diminishing).  The two most populate virtual machine platforms are .Net and Java, but you will find that presently different devices have different levels of support for these two platforms.

So What are you Saying

After reading the above you should be able to infer what I am about to conclude.  IF you need to run a single application for multiple platforms make it a web app and adapt it to the browsers (or browser standards) that you wish to support.  If it absolutely has to be a native application then you will not be able to create a single application that runs on Windows Mobile, iPhone, Symbian, Blackberry, and OS X.

/www.j2i.net.html

Looks that a lot of people are interested in Power Management.  In the next 24 Hours of Windows Mobile webcast the top is “Developing Battery Friendly Programs.”   The following week covers “Interoperability between Managed and Native Code.”

The Windows Embeded Blog had a post about a .Net Micro framework development solution that cost under 100.00 USD. For the pricepoint and the functionality this is an incredible package!  I may have to pull out my notebooks for some of the automotive projects I wanted to do (I had been considering a Windows CE device for those projects but I think this package should be more than adaquate).  If you are interested you can grab one of these from GHI Electronics.

Update [2008-09-18 23:20 UTC] – feeling that this is such a power product I’ve already submitted an order for one for myself.

The Tilt firmware update was welcomed with open arms.  I installed it, and after a few failed attempts I figured out how to prevent the bloatware from installing.   But the 6.1 firmware for the Tilt is not working as well as I had hoped.  The most annoying problem is that if the device is suspended for more than a certain amount of time upon turning it on the device turns off again.  I just found out that I am not the only one experiencing problems.  Over at Tilt Site (a subsite of the Mobility Site) users are reporting many of the same problems that I have experienced since the upgrade.  I’m not optimistic that another firmware update is forthcoming since AT&T must approve all firmware updates and they are planning to EOL (End of Life) the device. I may end up returning to the previous Windows Mobile 6.0 firmware image (so long threaded messages).

Several times in the past two weeks I’ve seen users on the MSDN forum ask what software tools are needed to develop for Windows Mobile.   It’s possible to develop for Windows Mobile devices using the .Net Compact Framework SDK and the command line compiler.  I would never suggest that some one do that; IDEs provide a much better debugging and development experience. The chart collowing this paragraph will let you know what versions of Visual Studio that you can use for each Windows Mobile and .Net version.  Note that no Visual Studio express version is lited here.

Programs that you cannot presently use for Windows Mobile development include the express editions of Visual Studio and Visual Studio 2008 Standard.

I was thinking of making a Windows Mobile multiplayer game using SMS.  One of the considerations is that not all of those playing will have an unlimited SMS plan so one must be thoughtful in minimizing the amount of SMS traffic that is generated by the game.

Let us assume for a moment that the 160 character limit is more than sufficient for transmitting all of the status information that needs to be known for the people playing in the game (I’t may not be, but I will address this later on. But ignore the message’s capacity for now).  One non-centralize method of ensuring that every one knows every one elses status is to have all the devices communicate with each other.  The number of messages needed to do this is dependent on the number of players.  Games ranging from 1 player to 5 players would require the following number of messages (note that the arrows represent a message being sent).

Number of Players	Number of Messages	Nodes and Arcs
1	0
2	2
3	6
4	12
5	20

The number of messages is increasing at a rather alarming rate. For n number of playeyers the number of messages needed can be calculated from the following equation.

At such an astronomical rate of cost growth the number of people allowed in a game will quickly become cost prohibitive. For a turned base game these would be the collective cost of each turn. A better model is needed.  Let’s consider a centralized model in which one player is designated the leader and all other players only communicate with the leader.  The leader will collect information from all players, accumulate it, then broadcast it to all players.

This organization looks deceptively better. The rate of growth for the messages is 2n and the total cost of the messages is n.Now if you consider the cost distribution you will see something unfair.  The leader takes on a large chunk of the cst.  50% of the cost to be exact.  Each one of the other players will only have a cost of 1.00 USD per turn.  Who would want to be leader under such an imbalanced Better balance may be achievable with a rotating leader assignment.

If the game being written for the phone is a turned based and thus the players are not taking their turns simultaneously then an even more economic SMS graph can be created.  Organize the players in a circuit.  Player one sends a message to player to, player to on to the next player, and continue this pathway until all players have received a message.  At the end of this pathway send a message back to player one. The cost per turn is finally capped!

Notice that across all three models the communication in two player games is exactly the same.  For that reason I will suspend the idea of supporting more than two players (I may revisit it later).

I earlier mentioned that we are assuming that any data transmitted would fit in one message.  If we find that 2 or 3 messages are required to transmit a chunk of data then our message count and cost will increase linearly.  Being the last significant and the less complex part of the calculation I find it easier to leave that out until the end.

Next time around I will consider how much it cost to have a game with players that have no unlimited data plan.

Another area when programming on Windows CE/Mobile devices is “How do I find the current directory?”  CE devices don’t have a concept of a current directory.  This means that relative paths don’t have meaning on a CE device (all paths are absolute).  Because of the lack or relative paths  some files (such as help files) are loaded to the Windows directory (personally I absolutely hate copying anything specific to an application to the Windows Directory).

It follows that since there is no concept of a current directory on a Windows Mobile device how would one locate a resource for which only a relative path is known?  A .Net program always has access to the modules of which it is composed (usually a .Net component is composed of one module packaged in a DLL or EXE file). The following line will return the absolute path to the currently executing assembly.

string modulePath = this.GetType().Assembly.GetModules()[0].FullyQualifiedName;

To get the absolute path to the folder that contains the assembly simple string manipulation is required.  The assembly name appears after the last directory seperator. While the directory seperator is usually the backslash (\) character, for better compatibility across other operating systems that may run .Net (ex: Mono[^] on Linux, OS X, or Solaris) use System.IO.Path.DirectorySeparator to represent the directory separator charactor.

string solutionFolder = modulePath.Substring(0, modulePath.LastIndexOf(Path.DirectorySeparatorChar) );

Once the folder to your program is known use Path.Combine to build the fully qualified file name for files in your folder.  Path.Combine takes into account the directory separator for the operating system on which your program is run.  So if you had data in a file named MyFile.txt you would use

string myFilePath = Path.Combine(solutionFolder,”MyFile.txt”);

Update 1 : I received a simpler way to accomplish the same thing from John Spraul in the comment section.  Thanks. John!

Update 2: If you are developing using the native APIS use the following:
GetModuleFileName(GetModuleHandle(NULL),    pszFullPath, MAX_PATH);

WE-DIG (Windows Embeded Developer Interest Group) was looking at power management this past month and had a few tibits of information that I need to add to my power management FAQ.  You can read more about WE-DIG’s finding at the Windows Embeded Blog.  They did some of their test using an AT&T Tilt (my current phone).  Changing the backlight settings on the Tilt had a huge difference on the devices battery life.  Depending on the settings the devices life ranged from 11 to 34 hours. They also mentioned that writing a file to a memory card uses 32 times the power of writing it to the built in memory.

This month Microsoft is providing 24 hours of webcast on Windows Mobile Development. The first webcast has already occurred, but the next one is in less than a week on how to use the Windows Mobile Emulator.  Having so many Windows Mobile devices one would think that I would have no need for the emulator, but this is far from the truth.  Developping without the emulator can potentially be expensive.  I’m developing some SMS based games at given that it cost $0.20 per message per device (which means $.40 for each message sent) debugging using real hardware starts to quickly have an impact on my pocket.

The following week there is a web cast on developing for different form factors.  I plan to register for that webcast too.  If you would like to register too here are the links to the registration page.

According to WMPowerUser and IStartedSometing.com there may be a Windows Mobile store coming to WM7 devices.  If you are a developer now would be the time to begin writing programs for such a store.  If it comes into existence then you’ll have apps ready to be first to market.  If not then you can still sell them through other online sites.

I see this time and time again.  It’s a practice that you don’t want to do in a a mobile program or any other program for that matter. In multithread programming a deveoper will sometimes want to stop execution of a thread until a certain event occurs or some other task is complete and will write something like the following to halt execution.

while(taskNotDone)
{
//Do nothing here
}

The problem with this code is it unnecessarily uses CPU bandwidth.  Most desktop applications spend a majority of their time waiting on some event to occur (waiting on a user to press a key, waiting on a file to load, waiting on a network event to happen).  When the above code is used the CPU is burning cycles when it could have been halted waiting for something to occur or giving up those cycles to another more constructive task.  On a Windows Mobile device this type of coding pattern will lead to the CPU not going into a lower power state when it could and unnecessarily causes power to be asserted across the memory bus.

Instead of using the above pattern you could join threads (which will cause one thread to wait for another to finish executing) or use events, mutexes, and semaphores to block a thread until it is signaled by another thread to continue.  Within the course of the next few weeks I will cover some of these techniques.  In the mean time you may wish to read the article I published on Power Management.