Introduction
Windows Mobile software is designed to be easily adapted for a wide variety of hardware devices and for a large number of manufactures, mobile operators, and integrators. To create a platform which has a consistent set of features for developers to target, the Windows Mobile platform provides two defined platforms: the Windows Mobile-based Pocket PC and Windows Mobile-based Smartphone. Within these categories the Windows Mobile platform enables OEM and operator customization that creates unique and compelling devices in the market. Our goal at Microsoft is to ensure a consistent experience for developers across all of these devices, such that applications you build on one device and platform (Pocket PC and Smartphone) will work with little to no modification on the next device. Even though we emphasize this goal, there are occasional variations across products and platforms that can cause applications to behave differently between some devices.
To ensure we are providing maximum information to our developer community, this article addresses a few of the most common issues and frequently asked questions
(FAQs) around migrating between devices and platforms. We also provide an e-mail alias at the end of this article that you can use to report commonly-occurring issues so that we can add them to this FAQ.
This FAQ is targeted toward developers migrating from a previous version of Windows Mobile software or working to establish a single code base for all Windows Mobile-based devices.
User Interface
Why does an error reporting dialog box appear while my application is running on a Windows Mobile 5.0-based device? The device worked fine before...
Windows Mobile 5.0 includes a new feature called "Pocket Watson," which detects unhandled exceptions and prompts the user to send error reports to Microsoft. Microsoft uses this anonymous data to measure and improve the quality of Windows Mobile software and third-party software running on the Windows Mobile platform.
Earlier versions of Windows Mobile software did not report unhandled exceptions in third-party applications. If your application previously had an unhandled exception, Windows Mobile 5.0 may now report it to the user so that they can submit an error report.
Why does my Smartphone homescreen no longer work on Windows Mobile 5.0?
The XML parser in Windows Mobile 5.0 is more strict than in previous versions. If the parser considers the XML for the homescreen XML to be invalid, the homescreen does not load.
The most common cause for homescreens to be considered invalid on Windows Mobile 5.0, but not previous versions, is the whitespace at the beginning of the file.
Why do I have duplicate numeric accelerators on my Smartphone menus?
When you create a menu on Windows Mobile 2003-based Smartphone, the operating system automatically adds numeric accelerators to the menu. Because the operating system automatically does this for you, the Designed for Windows Mobile Software Application Handbook for Smartphone states that you should not add numbers to the menus to denote their keypad accelerator. This change was made when moving from Smartphone 2002 to Smartphone 2003, so applications that manually add accelerators obtain duplicates on the 2003 platform.
Why don't keypad accelerators work with list boxes on Smartphone 2003?
When the Smartphone UI presents a list or menu, you can typically use the keypad to accelerate to the desired item by pressing the equivalent keypad item. For example, display your list of sounds or ringtones and pressing the "3" key advances you to the first item that starts with "d". This functionality works fine with ROM applications on the phone, but you may find that applications you develop with Microsoft eMbedded Visual C++ or Microsoft Visual Studio do not honor these keypad combinations with list boxes. (These keypad combinations will be corrected in a future version of Smartphone.) You can also work around this issue by subclassing the target window and filtering the WM
IMECOMPOSITION to manually select your list item.
Why don't progress bars display correctly?
Some Windows Mobile-based devices have been released with both the system colors for COLOR
BTNFACE and COLORHIGHLIGHT set to the same color. Typically, these values differ; therefore, when COLOR
BTNFACE and COLORHIGHLIGHT are set to the same color, some UI elements may not distinctly display as you expect. You should compare the values for BTNFACE and HIGHLIGHT and adjust the color values for COLOR
BTNFACE and COLORHIGHLIGHT if the same values are being used.
My Pocket PC used to indicate certain events by the way the LED "flashed". This seems to have changed between 2002 and 2003. What changed?
Pocket PC 2002 provides options under "Sounds & Notifications" to set a "Display message on screen" and "Flash light for" a period of time. These choices are not available in Windows Mobile 2003 for Pocket PC. For more information, see Differences in LED flashing functionality between Pocket PC 2002 and Pocket PC 2003.
Files and Storage
My CAB file installed fine on Windows Mobile 2003 Second Edition. Why doesn't it work on Windows Mobile 5.0?
Starting with Windows Mobile 5.0, the installers for Pocket PC and Smartphone were merged for consistency purposes. As a result, the install behavior across both platforms is now more uniform, and a common set of command line options is supported. Command line options for wceload.exe are fully documented in the platform
SDKs. On Windows Mobile 5.0, any attempt to reinstall an application will prompt the user to remove the existing installation first. This prompt is a change from previous versions of Pocket PC that left the existing installation intact during reinstallation. If you build a .cab file to patch or upgrade an application, be sure to package a .cab file that maintains its own unique install information (for example, unique
AppName) to avoid removing the existing program components.
INF files that list anything other than
DLLs (such as
EXEs) in the
CESelfRegister section fails on Windows Mobile 5.0.
INF files that set registry values to numbers outside of the range of signed integers fail on Windows Mobile 5.0.
CABs that need to set a registry value to a number outside of this range can do so within a custom setup DLL.
Starting with Windows Mobile 5.0, only one instance of the installer (wceload.exe) can be running at a time on Pocket PC devices. This restriction has always been in place on Smartphone. As a result, CAB files that start other CAB files from a custom setup DLL may not work on Windows Mobile 5.0. The workaround for this is to have a small executable in the CAB that a custom setup.dll starts in its Install_Exit entry point. This executable can get a handle to the running wceload.exe process, wait for wceload.exe to exit, and then restart wceload.exe on the additional
CABs.
How can I tell what has been installed on a device?
On Pocket PC devices prior to Windows Mobile 5.0, developers should look in the HKLM\Software\Apps registry key to see what applications have been installed. This registry key will not be supported in future versions of Windows Mobile.
For all versions of Smartphone and versions of Pocket PC starting with Windows Mobile 5.0, developers should query the
UnInstall Configuration Service Provider feature to determine what applications have been installed. You can use
DMProcessConfigXML for native developers or
Microsoft.WindowsMobile.Configuration for managed developers.
Why are CAB files no longer deleted after they are installed on Windows Mobile 5.0?
Prior to Windows Mobile 5.0, CAB files were automatically deleted after being executed unless the read-only flag was set on them. This action was done to save spac,e but it resulted in end-user confusion.
Starting with Windows Mobile 5.0, CAB files are never automatically deleted.
What is EDB? What is the future of CEDB?
Windows Mobile 5.0 includes a new database engine called EDB that is faster, more flexible, and more secure than its predecessor, CEDB. CEDB is now deprecated and will not be supported in future versions of Windows Mobile, so developers are advised to target EDB or SQL Mobile 3.0 for applications running on Windows Mobile 5.0 or later.
For the list of known issues when porting to EDB see
CedbToEdbMigrationIssues
Why does my application, which uses msgstore.dll, tell users to acquire a new version on Windows Mobile 5.0?
Msgstore.dll was deprecated in the Pocket PC 2003 SDK and replaced with CEMAPI. Windows Mobile 5.0 detects when an application attempts to load msgstore.dll and displays a message box prompting the user to contact the developer of the application for acquire an updated version.
Why is my application unable to access Contacts, Calendar, Tasks, or Call Log information on Windows Mobile 5.0?
Prior to Windows Mobile 5.0, Call Log, Calendar, Contacts, and Tasks data were stored in a CEDB database. The Pocket Outlook Object Model (POOM) API provided access to that data. However, some applications accessed the data directly through CEDB rather than through POOM. Starting with Windows Mobile 5.0, this data is no longer stored in CEDB databases and, as a result, those applications that do not use POOM will no longer be able to access Contact, Calendar, Tasks, and Call Log data. Applications previously using POOM and the call log
APIs will run correctly on Windows Mobile 5.0.
POOM performance has been improved and new features, such as events and named properties, have been added that address the most common reasons for developers previously by using CEDB instead of POOM.
How can I consistently identify storage locations on devices?
Smartphone 2002 and Smartphone 2003 have both a persistent and volatile store. The volatile store is reset each time you turn off the phone. Any data that needs to persist when the phone is switched off is saved to the persistent store. The persistent store is mounted as a directory off the root in Windows Mobile 2003 software for Smartphones and Windows Mobile 2003 Second Edition software for Smartphones.
Most Smartphone 2002 devices used an IPSM folder to represent their persistent storage locations. With Smartphone 2003, the default location is typically "Storage". To ensure that your application can always detect the correct storage path, you should take advantage of the
SHGetSpecialFolderPath API to determine the location of common storage locations like My Documents.
The persistent store is mounted directly to root in Windows Mobile 5.0 software for Pocket PC and Windows Mobile 5.0 software for Smartphone — there is no longer a volatile store. For backwards compatibility, the homescreen plug-ins from Microsoft automatically translate references to background images hardcoded to be in paths under \IPSM\ or \Storage\ to the respective location under \. In all other instances, it is the developer's responsibility to determine correct persistent storage paths.
Additionally, the name of storage card locations on Smartphone and Pocket PC devices can also vary among manufacturers. Because a device can have multiple storage cards with various names, your application cannot make any assumptions about the naming or path to a particular card. Use the
FindFirstFlashCard and
FindNextFlashCard functions to allow programmatic enumeration of storage cards.
Why are some changes to the registry lost when a device is reset?
For optimal performance on devices with persistent storage, the registry is not immediately flushed to persistent storage when changes are made. If the device is unexpectedly reset, recent changes to the registry may be lost. Call
RegFlushKey to force immediate flushing of the registry.
Why does my application fail after a suspend/resume?
Why are my file handles invalid on a storage card after a Pocket PC is switched off and back on?
With the 2003 platform, the default time delay that can affect loading and unloading some drivers in response to a suspend/resume event was decreased. This time delay may have an effect on applications that expect file handles associated with SD cards to be preserved during a short suspend/resume event. If you have problems migrating to Windows Mobile 2003 with applications that expect files to remain open on SD cards between suspend/resume events, you should try increasing the following registry value to 4096 if it is currently lower:
HKEY_LOCAL_MACHINE\System\StorageManager
[PNPUnloadDelay] : 4096
Why can't I install software on some devices?
All versions of Windows Mobile software for Smartphone and Windows Mobile software for Pocket PC starting with Windows Mobile 5.0 have an application security model that is configurable by the device maker or mobile operator. This security model is covered in detail in A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers.
In addition to the standard security configurations Microsoft recommends, the security model allows a mobile operator or device maker to customize the device to protect mobile operator or device maker assets. In most cases, you need only review the shipping security configurations of each operator to understand what level of signing is required to install and execute on your device. You should be mindful that attempts to modify protected areas of the registry or data on the device during installation or execution can be denied. Because of the transactional nature of installation, an attempt to modify a protected registry key can cause the entire installation to fail. For example, some Samsung i600 model phones initially secured the HKCR registry key, which caused some install failures for applications that attempted to register a file association under HKCR. Samsung released a patch to expose this key. For more information, please review the following resources:
Mobile2Market Frequently Asked Questions
Build Applications for Windows Mobile-based Smartphones
Samsung SCH-i600 Smartphone Portal
I'm seeing unpredictable behavior in my application on certain devices. What might be the cause?
My application runs up but gets terminated by the system. What's up?
The Windows Mobile platform is designed to run on devices with little memory. In general, you should ensure that whenever you request new memory, be it through malloc() or the use of the new operator, you successfully allocate the memory before using it. Failing to do this can cause you to try to use memory that is not allocated to you, which will cause an access violation.
Devices ship with different configurations of built-in and available memory on first use. When storage space becomes critically low, applications that write data to storage and new installations may begin to fail. If your application is affected by either of these conditions, be sure to check the available memory and storage on your test device. If your application has aggressive memory requirements, you should consider checking the amount of available memory on install and advising users to uninstall software that they do not use.
To check memory and storage on your device on Pocket PC devices, tap Start, Settings, and then tap Memory.
To check memory and storage on your device on Smartphone devices, tap Programs, Settings, and then tap About.
Another factor that can influence the available memory for applications is "addressable" memory space. Addressable memory space is the logical memory mapping that processes, executable components, and allocated memory must fit into to execute. Addressable memory space can contribute to a number of memory issues because you can have plenty of available system memory and yet have an exhausted addressable memory area.
The Windows CE operating system that sits underneath Windows Mobile software also shares addressable memory areas when you load
DLLs to conserve memory across multiple processes. It is important to first understand how the operating system handles memory. This is covered in the MSDN article Windows CE .NET Advanced Memory Management.
Why is COREDLL.DLL located in Slot 0 on Windows Mobile 2003-based devices?
Starting with Windows Mobile 2003 software, coredll.dll was moved from Slot 1 to Slot 0 to provide better memory management with the Compact Framework. Even though Slot 0 is typically a read/write area of memory, coredll.dll is still an XIP (Execute In Place) DLL and hence does not need to be copied into RAM to run.
Sometimes Autorun.exe may not launch as expected on devices that contain more than one Storage Card. Why?
Windows Mobile provides a mechanism to automatically launch an executable named "autorun.exe" when placed on a storage card and in a special directory named for the processor type (that is, – \storage card\2577\autorun.exe). Some devices support multiple storage cards or use internal, non-removable storage cards to self configure the device. Autorun.exe may not launch as expected on devices that contain more than one storage card containing an autorun.exe file. This will corrected in future versions of Windows Mobile.
Why do my CEDB databases no longer work after migrating to Windows Mobile 2003?
The internal format of databases changed in the Windows Mobile 2003-based Pocket PC and Smartphone. This change causes some third-party applications to hang or display an error message when they attempt to access data. Applications that install databases from files, along with the program itself, are affected. If you have or use an application that uses CEDB and that worked on Pocket PC or Smartphone 2002 and does not work correctly on Windows Mobile 2003-based Pocket PC or Smartphone, there is a wizard to assist with migrating databases. This tool is also useful for users that have entered data into applications on a previous release of Pocket PC or Smartphone, are upgrading to the 2003 release, and want to migrate their data.
Database Conversion Wizard Power Toy
Security
Why does my device driver or service fail to load on Windows Mobile 5.0 devices?
Drivers or services may be loaded very early in the boot process — before the device's security policy has been loaded. Because of this, only drivers signed with a privileged certificate (regardless of the device's security policy) can be loaded during the boot process. You can modify drivers and services to start later in the boot process by creating shortcuts in the
\Windows\StartUp folder or by going through the Mobile2Market privileged signing process.
Why does my CPF file not work on some devices?
Unlike CAB files, CPF files are run without a user interface. Because of this, there is no prompt to allow the user to escalate a CPF file's permissions based on the device's security policy. Any CPF files that modify restricted files, registry values, or settings may need to be signed with a privileged a certificate.
How can I retrieve a unique device identifier, or how can I soft-reset the device, without calling a privileged API?
Windows Mobile 5.0 includes new
APIs to retrieve unique device identifiers and to soft reset the device without using the privileged
KernelIoCtl API. Respectively, these
APIs are
GetDeviceUniqueID and
ExitWindowsEx.
Why can't I use RAPI with my Windows Mobile device?
The use of RAPI
APIs provides a convenient way to access device resources from a desktop computer. The Windows Mobile security model in all versions of Smartphone and versions of Pocket PC starting with Windows Mobile 5.0 can be configured to prohibit and restrict RAPI. Windows Mobile honors a RAPI security policy (4097) that can be configured to completely allow RAPI, entirely prohibit RAPI, or allow RAPI under a restricted role (SECROLE
USERAUTH). If RAPI is configured to execute under a restricted role, you will not have access to some types of calls that are prohibited. Windows Mobile devices can be configured to allow all types of RAPI calls, but it is up to the mobile operator or device maker to set this policy when they build the device.
When RAPI is configured to be restricted,
CeRapiInvoke can only be used with
DLLs on the device that are trusted (signed with the appropriate certificate) or listed in the metabase for
RapiInvoke. A DLL can be added to the metabase by using the Metabase Configuration Service Provider, as the following code sample shows.
<wap-provisioningdoc>
<characteristic type="Metabase">
<characteristic type="RAPI\full_path_to_the_dll.dll\*">|
<parm name="rw-access" value="3"/>
<parm name="access-role" value="152"/>
</characteristic>
</characteristic>
</wap-provisioningdoc>
Most Windows Mobile 5.0-based Pocket PC devices (with the exception of Pocket PC Phone Edition) will come preconfigured with a wildcard in the metabase that allows any device DLL to be used with
CeRapiInvoke.
Do I need to sign MUI files?
On Smartphone 2002, MUI files did not require signing. With Smartphone 2003 and moving forward, MUI files need to be signed along with the other required binaries (EXE,
DLLs, and
CABs).
As part of our security initiatives, we are starting to sign all of our CABs, but after we sign a Pocket PC CAB, it no longer works. Why?
Unlike the Smartphone, Pocket PC platforms through 2003 Second Edition do not support signing of
CABs. If you sign a Pocket PC CAB on any of these platforms, they will report that the file is corrupt upon install. This will be supported with future platform implementations.
Windows Mobile 5.0 software for Pocket PC supports signed CABS. Additionally, when users use
ActiveSync version 4.0 to install an application on older Pocket PC devices that do not support signed
CABs, ActiveSync removes the CAB file's signature before transferring the file to the device in order for the installation complete successfully.
Hardware
What directional pad capabilities should I target with my application?
Microsoft currently requires that manufactures implement a five-way directional pad on Windows Mobile devices. Some manufactures have extended the baseline requirements to provide enhanced control pads. Eight-way directional pads are not uncommon. You should keep in mind that while enhanced devices may offer more capabilities to their applications, these capabilities may not be supported across all devices in the market. Applications should be designed to work well on against baselines hardware specifications to provide the best user experience and provide broad device support.
Browsing and Internet Connectivity
Why do HTTP posts larger than 16K fail on Windows Mobile 2003?
When you move from Windows Mobile 2002 to Windows Mobile 2003 platform, HTTP posts larger than 16KB may fail. After posting 16KB worth of data, the transactions may timeout and report an error. To work around this issue, break the data up into small chunks less than 16KB.
Why do Web pages look and behave differently on 2003 devices?
On Windows Mobile 2003-based devices, Microsoft Pocket Internet Explorer automatically resizes some Web content to display better inside the browser area. This resizing capability is a change from the 2002 platform. If you have optimized your content for mobile devices and you want to override automatic resizing, you can override this feature by using the following meta tag to disable it on 2003 devices with a build 13252 and later:
<meta name="MobileOptimized" content="240">
Why do I see the prompt "Press OK to continue loading the content of this page," when I load a page using Pocket Explorer that contains an ActiveX control?
Windows Mobile 2003 Second Edition software for Pocket
PCs and Smartphones may display a prompt when loading ActiveX controls in a Web page. This prompt does not appear on previous versions of Windows Mobile platforms. This prompt will be removed from future builds of Windows Mobile 2003 Second Edition software to work as it did before the change.
This problem will affect active content coded using <object>, <embed>, or <applet> tags that are inline in an HTML file. However, HTML pages that use tags generated by external script files (like
JavaScript) should continue to work normally with no changes. As an example, you could start with an embedded HTML object that causes the following prompt.
<OBJECT
ID="MonthCalCtl"
CLASSID="CLSID:88D13D17-0704-48A9-80EE-D6DDC73F162A"
WIDTH=220
HEIGHT=160
>
The previous
MonthCalCtl object could be dynamically generated from an external file, "foo.js".
function [RunFoo()]
{
document.write('<OBJECT ID="MonthCalCtl" CLASSID="CLSID:88D13D17-0704-48A9-80EE-D6DDC73F162A" WIDTH=220 HEIGHT=160 >\n');
document.write('<PARAM NAME="MultiSelect" VALUE="TRUE">\n');
document.write('</object>\n');
}
The external file could then be referenced, and the object used as shown in the following example to avoid any prompt on affected devices.
<script src="./foo.js" language="JavaScript" type="text/javascript"></script>
<script language="JavaScript" type="text/javascript">RunFoo();</script>
My code that uses the HTML control no longer displays images correctly. Why?
If you use the HTML Control and manually process images, please note that this behavior has changed in the 2003 platform.
With Pocket PC 2002, the file pointed to by the IMG SRC tag will be passed in its current state to the NM
INLINEIMAGE notification handler. (For example, "file://\\My Documents\\logo.bmp" will be passed in its current state without any modification to WM
NOTIFY handler.) With Pocket PC 2003, the control changes the URL to "file:///My Documents/logo.bmp." If you are accustomed to handling the image in your application, the NMHTMLVIEW::szTarget string should be appropriately converted to load the image.
If you are using MFC and you want to custom handle the images, with Pocket PC 2002 you had to return a nonzero value in the NM
INLINEIMAGE handler. The 2002 platform also ignores the value in the third parameter of
OnNotify. With the 2003 platform, you must set the LRESULT parameter of
OnNotify to a nonzero value to tell the control that you have handled the event yourself. Note that in both the platforms, you need to send DTM_SETIMAGE and also return a nonzero value from the notification handler.
What do I need to do to make my Pocket PC resolve "localhost" correctly?
If you have problems using the Pocket PC HTTP server or connecting to "localhost" with a Windows Mobile 2003-based device, you may have to provision your device as follows:
Create a file called _setup.xml with the following contents:
<wap-provisioningdoc>
<characteristic type="CM_Mappings">
<characteristic type="536870911">
<parm name="Pattern" value="*://localhost/*" />
<parm name="Network" value="{e8e89f5a-d3bb-4c58-9b4e-08279d31044e}" />
</characteristic>
</characteristic>
<characteristic type="Registry">
<characteristic
type="HKLM\Software\Microsoft\ConnMgr\Providers\{EF097F4C-DC4B-4c98-8FF6-AEF
805DC0E8E}\localhost-null">
<parm name="DestId"
value="{e8e89f5a-d3bb-4c58-9b4e-08279d31044e}" datatype="string" />
<parm name="Type" value="0" datatype="integer" />
<parm name="Enable" value="1" datatype="integer" />
</characteristic>
</characteristic>
<characteristic type="CM_Mappings">
<characteristic type="536870911">
<parm name="Pattern" value="*://127.0.0.1/*" />
<parm name="Network" value="{e8e89f5a-d3bb-4c58-9b4e-08279d31044e}" />
</characteristic>
</characteristic>
<characteristic type="Registry">
<characteristic type="HKLM\Software\Microsoft\ConnMgr\Providers\{EF097F4C-DC4B-4c98-8FF6-AEF805DC0E8E}\localhost-null">
<parm name="DestId" value="{e8e89f5a-d3bb-4c58-9b4e-08279d31044e}" datatype="string" />
<parm name="Type" value="0" datatype="integer" />
<parm name="Enable" value="1" datatype="integer" />
</characteristic>
</characteristic>
</wap-provisioningdoc>
Create a CAB provisioning format file as outlined on MSDN.
Place the CPF file on your device and tap it in File Explorer. The CAB installer will process it and delete the file. There is no visual feedback but at this point, you should be able to use http://localhost to access the local Web server without a network connection.
Why do I receive errors like 12029, 12031 and 12007 when I establish my connection by using
InternetOpen with INTERNET
OPENTYPE_PRECONFIG?
When you use INTERNET
OPENTYPE
PRECONFIG, InternetOpen will attempt to honor whatever proxy information is configured on the device. Many Smartphones are configured to route through operator specific proxies which can affect certain types of network communications. INTERNETOPEN
TYPEPRECONFIG retrieves its proxy information from the registry, which can be changed by the configuration of Pocket Internet Explorer. One quick way to verify if you are dealing with a proxy issue to test with INTERNET
OPENTYPE
DIRECT and use INTERNETOPEN
TYPEPROXY and pass the proxy info directly to
InternetOpen.
My Javascript code no longer works. What changed?
When referencing objects in Javascript with Windows Mobile 2003, you may be required to use a fully-qualified object reference. For example, if you had a button contained inside an HTML <FORM> tag, with Pocket PC 2002, you could access the button <OBJECT> by the ID attribute anywhere in the script. With Pocket PC 2003, it has to be fully qualified with window.form
name.objectid.ButtonGo.Disabled = 1, for example:
[Window.form1.ButtonGo.Disabled] = 1
I can't load an XML document in Javascript on Windows Mobile 2003.
Using Microsoft.XMLDOM to load a local XML file in Javascript will result in an "Access Denied" error on Windows Mobile 2003, but this method works the 2002 platform. This new error is caused by security changes made to the 2003 platform. To work around this issue, you can load the data through an ActiveX object, which can successfully be created in Javascript.
Why are my URLs not resolving correctly on 2003 devices?
Pocket Internet Explorer may improperly encode POST/GET data containing some the HTML character entities. For example, any URL that contains &or, &lang, or & would be improperly converted. A list of the affected entities can be found at http://www.w3.org/TR/html401/sgml/entities.html. This issue only affects the 2003 platform-based devices and will be corrected in future platform updates.
Display
Why does text look smaller on Windows Mobile 5.0-based Smartphones?
Windows Mobile 5.0 software for Smartphone includes a new font that is optimized for reading on small screens but is slightly smaller in both height and width.
How do I handle devices with High DPI, Rotation, and Landscape support?
Windows Mobile 2003 Second Edition software introduces new display capabilities to the Windows Mobile platform. If you've made assumptions about screen resolution and orientation, you may need to take action to ensure your applications work across all Windows Mobile 2003 Second Edition-based devices. The first step is to test your applications to ensure that they work as expected on high-resolution devices and in landscape or square modes.
You will also find a new warning when installing older application to Windows Mobile 2003 Second Edition-based devices. Information about the new capabilities and instructions about how to package your application for support on this platform can be found in the Developer Resources for Windows Mobile 2003 Second Edition.
I recompiled my Pocket PC application by using Visual Studio 2005. Why does my application no longer look correct on Pocket
PCs that support landscape, square, or VGA resolutions?
Applications compiled with Visual Studio 2005 are assumed to be resolution- and orientation-aware; therefore, they do not get the "legacy screen emulation mode" that adds scroll bars and performs automatic pixel-doubling for older applications that run on new device form factors. When migrating to Visual Studio 2005, developers need to update their applications to handle multiple orientations and resolutions including landscape, square screen, and high resolution.
The Windows Mobile 2003 Second Edition Developer Resource Kit includes whitepapers and sample code describing techniques for implementing orientation and resolution awareness.
The new docking and anchoring features in the .NET Compact Framework version 2.0 makes this task much easier for C# and Visual Basic .NET developers.
Why do the toolbar images seem to disappear from my application when running Windows Mobile 2003 Second Edition?
Toolbar images that seem to disappear are caused by a change in behavior under Windows Mobile 2003 Second Edition that can cause the images to be deleted when the toolbar is modified or removed from the form. For example, disappearing toolbar images can occur in response to a change from
MinimizeBox, WindowState or
FormBorderStyle properties of the form because changing these causes recreation of the form on the native level, resulting into removal of the toolbar from the form. To workaround this, set the
ImageList property of the toolbar after performing the operations previously mentioned.
If you use Visual Studio to create a toolbar with button images at the time of design, you may experience this problem. The code that is generated in the
InitializeComponent routine adds the control after the
ImageList is assigned. To work around this issue, you can change the order of the Controls.Add statement to occur before the
ImageList is assigned to the toolbar.
When running in landscape mode under Windows Mobile 2003 Second Edition, all of my dialogs have scroll bars even though they don't have controls positioned below the bottom of the screen. Why?
Scroll bars appear even though the dialogs don't have controls positioned below the bottom of the screen because a change in behavior under Windows Mobile 2003 Second Edition causes unneeded scroll bars to appear. Because the automatic scrollbar feature does not occur if a tab control is on the dialog at all, a workaround would be to create a tab control (class
SysTabControl32), place it off the screen area (using negative coordinates), and turn off its WS_VISIBLE property. This workaround ensures that a vertical scrollbar will never be automatically introduced when the device switches to landscape.
Should I use GETRAWFRAMEBUFFER, GAPI, GDI, DirectDraw, or Direct3d Mobile?
Developers often ask what approach they should take to develop graphics and games on Windows Mobile platforms to support the widest variety of display capabilities and take advantage of the most efficient interfaces available to them. Capabilities can vary from device to device.
As of Windows Mobile 5, all new 2D graphics applications should use either GDI or
DirectDraw, and applications requiring 3D may use Direct3d Mobile (D3DM).
GAPI is deprecated and may not be supported in future Windows Mobile releases beyond Windows Mobile 6. GETRAWFRAMEBUFFER is also deprecated and will not be supported on future Windows Mobile releases past Windows Mobile 6. Note that GETRAWFRAMEBUFFER is not supported on a number of current Window Mobile devices.
Audio
Why is my audio stream "choppy"?
You may find that the output of your sound servicing routine is "choppy" on some Pocket PC and Smartphone 2003 devices. This most commonly occurs when the CPU usage approaches 100 percent and a high bit rate is used. This problem usually occurs due to small delays in the callback request from the operating system or sound driver introduced in certain Windows Mobile 2003-based devices.
In game development, it is common to create a separate thread to service the sound driver's request for additional sound data; however, this approach may contribute to the delay that causes this problem. To work around this issue, you can integrate your sound servicing routines into your main thread (the one achieving nearly 100 percent CPU usage). In addition, you may include a Sleep(0) in the main loop, which may improve the latency of the callbacks.
If you still experience problems when your game is loading graphics or doing anything that takes longer than the time it takes to play the queued sound buffers, you should consider moving the graphics load to an earlier point of the program execution to avoid the load during sound execution.
Why is my recording blank?
Recording of sound on some Smartphone 2002 devices may be delayed or suspended during periods of UDP network activity. You may see this problem if you begin to record by using an application that relies on a stream of UDP traffic and then stop the recording. The period of time that UDP network activity occurred may cause an empty record stream. This empty record stream is caused by a driver issue on some devices.
Compiler and Development Environments
What's up with ATL and MFC?
Visual Studio 2005 includes new versions of both MFC and ATL, which are compatible with Pocket PC 2003 and all Windows Mobile 5.0 devices (including Smartphone). These new runtimes do not appear in ROM on any devices. Developers should either statically link to these runtimes or install the DLL files to the same directory as the EXE that uses them.
The runtimes for prior versions of ATL and MFC are in ROM on Windows Mobile 5.0-based Pocket PC devices for backwards compatibility but will be removed in future versions of Windows Mobile. Therefore, developers should either migrate to MFC 8.0, ATL 8.0, or redistribute the older runtimes with their applications.
Why does my code behave differently after compiling with eMbedded Visual C++ 4.0?
Microsoft eMbedded Visual C++ 4.0 changed the way some code optimizations were performed. If you find behavioral differences in highly-optimized areas of your code, consider temporarily turning off optimizations to help you determine if compiler changes may be a factor. To turn off optimizations, simply open Project, choose Settings, and then turn off optimizations on the C++ tab. If you are migrating projects from eMbedded Visual C++ 3.0 to eMbedded Visual C++ 4.0, be sure to review the MSDN article, Migrating to the eVC 4.0 Environment.
What has changed with ActiveX controls?
Starting with Window Mobile 2003 software, newly created ActiveX controls require that the threading model for the component be declared as Free or Both when they are registered. In earlier versions of Windows Mobile, the system ignored this registration setting, but it is now required.
Why do applications that use ADOCE fail on Windows Mobile 5.0?
ADOCE was deprecated in the Pocket PC 2003 SDK and is no longer supported or included in the ROM of Pocket PC devices. For backwards compatibility, the ADOCE runtime and
ActiveSync service provider will be made available as a download. However, this runtime is not expected to be compatible with future versions of Windows Mobile, so developers are advised to target EDB or SQL Mobile 3.0 for applications that run on Windows Mobile 2003 or later.
Why do applications that use eMbedded Visual Basic fail on Windows Mobile 5.0 devices?
The eMbedded Visual Basic runtime for Pocket PC 2003 is not supported on Windows Mobile 5.0. Microsoft provides a series of technical articles to assist developers in migrating from eMbedded Visual Basic to Visual Basic .NET Microsoft:
Moving from eMbedded Visual Basic to Visual Basic .NET
Learn how to move Microsoft Windows Pocket PC 2002 software development from Microsoft eMbedded Visual Basic to the .NET Compact Framework and Visual Basic .NET. The release of the .NET Compact Framework enables mobile application developers to make use of the same tools and languages used in server and desktop application development.
Migrating eVB File Controls to Visual Basic .NET
This article provides information to help you port the eMbedded Visual Basic file controls (File System and File control) to Visual Basic .NET when migrating your applications from eMbedded Visual Basic to Visual Basic .NET.
Migrating eVB Forms to Visual Basic .NET
This article looks at the considerations involved in porting the GUI part of an eMbedded Visual Basic application to the .NET Compact Framework by using Visual Basic .NET. The article provides an example of how a simple application is created in each environment and explains the basic differences between eMbedded Visual Basic and Visual Basic .NET in the developer controls and code you will use.
Why do applications that use eMbedded Visual Basic or ADOCE fail on Windows Mobile 2003-based devices?
With Windows Mobile 2003-based devices, ADOCE and the eMbedded Visual Basic runtime are no longer included in ROM. They can be installed, downloaded, and installed manually. Please note though that developing code by using eMbedded Visual Basic on 2003 is not supported; it is simply provided to allow customers to run Pocket PC 2002 applications unmodified on 2003.
Download eMbedded Visual Basic Runtime for Pocket PC 2003.
An alternative is to port your application to NS Basic/CE. It supports Windows Mobile 5 and Windows Mobile 2003, as well as many other versions of Windows CE. NS Basic/CE is highly compatible with eVB and continues to be supported and enhanced. For a comparison of eVB and NSB, see this
comparison . For information on converting eVB to NS Basic/CE, see this
Tech Note .
What happened to imgdecmp.dll? How can I programmatically load common image formats directly?
Windows Mobile devices have traditionally included a ROM library called imgdecmp.dll for Microsoft applications to use. This library exported an API that was not documented in the SDK, but it has been used by developers to load image files. Starting with Windows Mobile 2003 Second Edition,
SHLoadImageFile and
SHLoadImageResource were added into the headers for aygshell.h. These
APIs should be used in place of imaging support previously provided by imgdecmp.dll. Alternatively, advanced imaging
APIs are provided by imaging.h for applications targeting Windows Mobile 5.0 or later.
On Windows Mobile 5.0, applications may get caught in an infinite loop if they call the
DecompressImageIndirect function with a
DecompressImageInfo structure with a prepopulated buffer and without specifying a correct non-zero value for
dwBufferCurrent. Note Imgdecmp.dll will be removed from a future version of the Windows Mobile platform.
Why am I unable to search for (enumerate) Bluetooth devices using WSALookupService/WSALookupServiceNext?
Device manufactures have the ability to load Windows Mobile devices with their choice of Bluetooth stacks. Starting with Windows Mobile 2003, Microsoft provides a Bluetooth stack that is compatible with our Bluetooth and socket
APIs. If a device manufacturer chooses to use an alternate Bluetooth stack, then you may need to use the SDK or API set provided on conjunction with that third-party vendor. For example, many iPaq products use a Widcomm Bluetooth stack. Widcomm provides their own SDK for developers to develop Bluetooth applications on these devices.
Why does my Today Plugin sometimes disappear on Windows Mobile 2003 Second Edition devices?
The code for the sample Today Screen plugin that ships with the Pocket PC 2003 SDK does not behave as it should do. The code calls
DefWindowProc after handling WM_PAINT, which it should not do. It should simply return zero after doing its painting.
This bug can result in incorrect painting; specifically, you will get a WM
ERASEBACKGROUND without a subsequent WMPAINT, which will cause your plugin to disappear.
If your Today Screen plugin was built based on the sample code you should correct this behavior to fix your problem.
Pocket Outlook and Pocket Outlook Object Model
The list of known migration issues for Pocket Outlook and the Pocket Outlook Object Model can be found on the
PocketOutlookObjectModelMigrationIssues page.
WindowsClient: Concluding "New WPF Features" Series
TechNet Edge: Windows Server 2008 R2 : New Power Management Features
