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.