What Tools do I Need to Develop for Windows Mobile?

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.

Visual Studio Version Supported Windows Mobile Versions
Visual Studio .Net 2003 Supports .Net Compact Framework 1.0 for Pocket PC 2002 and Windows Mobile 2003
Visual Studio 2005 Standard Edition or Better .Net 1.0 and .Net 2.0 from Windows Mobile 2003 to Windows Mobile 6
Visual Studio 2008 Professional .Net 2.0 and 3.5 from Windows Mobile 5 to Windows Mobile 6

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


SMS Economics

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.

Presently in the United States the price of a text message is 0.20 USD to 0.30 USD dependong on ones carrier.  I will use the midway point of 0.25 USD for calculating total cost.  Games written in this manner can quickly cost some one a significant amount of money.  When we calculate the total cost of these messages we must take into account that both the sender and the receiver of a message are charged.  So a message is collectivly costing the parties 0.50 USD.
Number of Players Cost of all messages
1 0.00 USD
2 1.00 USD
3 3.00 USD
4 6.00 USD
5 10.00 USD
6 15.00 USD
7 21.00 USD

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.

Number of Players Number of Messages Cost
1 0 0.00 USD
2 2 1.00 USD
3 6 3.00 USD
4 8 4.00 USD
5 10 5.00 USD
6 12 6.00 USD
7 14 7.00 USD

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!

Number of Players Messages Cost
1 0 0.00 USD
2 1 1.00 USD
3 1 1.00 USD
4 1 1.00 USD
5 1 1.00 USD
6 1 1.00 USD
7 1 1.00 USD

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.


Windows Mobile Current Directory

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);




if you do not want to load the type.


WE-DIG Power Management

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.


A Month of Windows Mobile

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.


To Kill a Battery

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.

//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.


Power Management Article Published

I’ve taken the discussion of the power button and have expanded upon it in the form of an article on power management in Widnows Mobile devices.  I’ve published it at my favorite online dev community site, codeproject.com.  Go over to http://www.codeproject.com/script/Articles/Article.aspx?aid=28886 and take a look at the article.  If you find the information useful then please log in and rate it!


My CE Devices

I had to pull out one of my older Pocket PCs for testing something and while I was at it I decided to round up my Windows CE devices and take a picture of them together.  I seem to have quite a bit.  Missing from the history of devices that I’ve owned are an i-mate Jam and the ViewSonic V37.  Regretably I sold one and gave the other to some one that wanted a PocketPC.  I hope to get a Windows Mobile 6 standard device and a Windows CE development kit in the coming months.


My Windows CD Devices


What Does the Power Button Dp

The impact of unobservable events has long been a subject over which humans have pondered.    Some questions are either well known or commonly shared.

  • If a tree falls in the forest and no one hears it then does it make a sound?
  • When I close the door on the fridge does the light go out?
  • Is Schrodinger’s cat dead or alive?
  • When I press the power button on my Windows Mobile phone do the programs stop running?

These are all questions will all be answered by the end of this blog post. Thanks to the availability of inexpensive electronics such as digital video and audio recorders we can show that falling tress make noises and that the lights in the fridge do go out.  Figuring out what happens when the power button is pressed on Windows Mobile was a little more difficult.

My first attempt at answering this question was based on programs that changed what they were displaying  over their execute cycles.  If the Windows Mobile device suspends when I press the power button then after pressing the button, waiting a few seconds, and pressing it again the program’s display should show the same thing that it did before I pressed the button.  If the device continues to run when I press the power button then after the test I should see something that is noticeably different. I ran my test and concluded that the processor continued to run after the power button was pressed.  As it turned out my initial conclusion was wrong.

After performing much more research on the matter I found that my conclusion contradicted other material I found such as the “Power to the Programmers” post on the Windows Mobile Team Blog. I performed my tests again and increased the amount of time that I left the device in its alleged suspended state.  After successive test I achieved enlightenment.   Pressing the power button on a Windows Mobile Professional device powers down the display and some other hardware, but the processor continues to run.  After a certain amount of time has passed unless a program has indicated a desire to do otherwise the device’s processor will halt until something wakes it up.  When the device is in this state it’s not off; the programs are still in memory.  Windows Mobile Standard devices are always on, there’s no questioning that.

In a forthcoming post I’ll cover the details of power control on Windows Mobile devices.

So the only question that leaves open is whether or not Schrodinger’s cat is alive. I will leave that question unanswered and hope for the best for his cat.


MFC and Windows Mobile

One of the things that I love about Microsoft is that once you learn a Microsoft technology parts of it are transferable to other Microsoft Platforms. The .Net technologies are an excellent example of this. There’s also DirectX (portions of which can be used on Windows Mobile devices) and MFC.

Another such technology is MFC (Microsoft Foundation Classes).  MFC is a library of C++ application framework library for creating Windows applications.  It is a native code library, so you have full access to the native API without the need of platform invoke declarations or re-declaring structures for making native calls.  But it also provides several high level classes for creating UI elements and responding to windows messages. I would say that MFC lives half way between .Net based programs and traditional native non-MFC applications.

I am engaging in a project for which it will be easier to use native code.  The project is going to rely on some third party native code libraries with a massive amount structures.  For the first phase of this project I plan to use MFC so that I can make a prototype with the third party library.  Later on I will make an abstraction layer that gives simpler access to the functionality that I need and then I will create a .Net wrapper for it.  In the coming weeks once the project reaches a certain level of functionality, stability, and presentability I’ll be posting the code on CodeProject.com.  I don’t want to say anything about the nature of the project just yet, but I’m sure it will be very popular!


Windows Mobile 6.1 Upgrade for the Tilt?

HTC’s support site is in a state of flux for the AT&T Tilt (a version of the HTC TyTn II).  The page is fluctuating between having a description for the Windows Mobile 6.0 ROM and the Windows Mobile 6.1 ROM.  Regardless of which page is displayed the Windows Mobile 6.0 rom is always the target of the download link.  I sent a question to their support department about this and they say the firmware update will be available by the end of the month.  Happy Days are Coming.


Teaching the Teachers

If I were to describe my goal with this site it would be summed in one word, “teach.”  I created this site for the purpose of communicating to other developers that have interest in Windows Mobile. My actions thus far have been centered around writing articles for developers. But some times developers are also teachers. I think that others could better take advantage of the information I post here if I make my target audience the developer-teacher.  This means that in addition to the articles I will be including Power Point slides with notes so that a developer-teacher will have information in a presentable form with minimal effort; all they would need to do is add their name to the first slide and optionally apply a theme to the power point slide deck.  I won’t be able to do this for every article because of time constraints (priority is given to my day job) but articles that contain slide will be marked with the “Presentation” tag.


Looking for Visible Devices

In a post a few days ago (Your Device is Showing) I mentioned the concerns that a few users had about their devices being visible to other people on their respective phone networks through Resco Explorer. Using a network packet monitoring tool I was able to write some code that performed netbios queries and was able to obtain the same names that Resco Explorer had received.  Requesting the name of a device is straight forward.  Just send a request to the device to be queried into UDP port 137 and extract the name from the response.  The byte stream to send is as follows.

NameRequest = new byte[]{
0x80, 0x94, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x20, 0x43, 0x4b, 0x41,
0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41,
0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41,
0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41,
0x41, 0x41, 0x41, 0x41, 0x41, 0x00, 0x00, 0x21,
0x00, 0x01 };

In the response byte stream you can extract the name from the 57th byte of the response to the 75th byte.  The name will be padded with spaces if it is less than 16 characters.  I did run into a problem in implementing this.  Many Windows CE builds don’t contain an implementation for timeout functionality on ports when listening and there doesn’t seem to be way to abort listening for a response without introducing a resource leak.  This is something worth revisiting once I have more information.