MSDN Home > MSDN Library > Mobile and Embedded Development > Embedded Operating System Development > Windows CE > Technical Articles |
Mike Hall June 2003 Applies to: AbstractBeginning with Windows CE .NET 4.2, original equipment manufacturers can include API compatibility support for the Pocket PC 2002 shell in their Windows CE-based platforms. This paper describes the APIs exposed through AYGShell and application compatibility between Pocket PC 2002-based applications and Windows CE .NET 4.2-based devices. (7 printed pages) ContentsIntroduction IntroductionBeginning with Microsoft® Windows® CE .NET 4.2, original equipment manufacturers (OEMs) can include application programming interface (API) compatibility support for the Microsoft Windows Powered Pocket PC 2002 shell in their Windows CE-based platforms. These extensions to the standard Windows CE .NET shell are known as the AYGShell APIs. AYGShell support allows most Pocket PC 2002-based applications to run on the Windows CE-based device after being recompiled for an OEM's Windows CE-based platform. This paper describes the APIs exposed through AYGShell and application compatibility between Windows Powered Pocket PC 2002-based applications and Windows CE .NET 4.2-based devices. There are two levels of application portability, the first being binary compatibility, the ability to take existing Pocket PC 2002-based applications and run these on Windows CE .NET 4.2-based devices, and the second being source-level portability. Source-level compatibility is, to some extent, a design/development decision that should be made before development of an application takes place. There are literally hundreds of Pocket PC 2002-based applications available to download and run on Pocket PC 2002-based devices. Take a look at http://www.pocketpc.com for a list of available software. Applications developed for Pocket PC 2002 are typically created using Microsoft eMbedded Visual C++® 3.0, which generates processor-specific binaries. All Pocket PC 2002-based devices use ARM processors; therefore, to achieve binary application portability, your Windows CE .NET 4.2-based devices must also be running on an ARM processor. If your device uses x86, MIPS, or SHx, you will need (at a minimum) to recompile the application source code to match the appropriate processor type for your device. This is of course only possible if you have access to the source code for the application. Pocket PC 2002-based applications can take advantage of device-specific APIs such as GAPI (the Games API). Applications that take advantage of Pocket PC 2002 specific APIs will not run on Windows CE .NET 4.2-based devices, so application developers who want to target both Windows CE .NET 4.2 and Pocket PC 2002 should determine the device type at run time and make appropriate API calls to take advantage of the device specific APIs. Application developers can choose to develop their eMbedded Visual C++ applications using Microsoft Win32®, or Microsoft Foundation Classes (MFC), binary compatibility of each is discussed below. Win32 ApplicationsApplications developed using Win32 have the ability to call any or all of the exposed APIs on a Pocket PC 2002 or Windows CE .NET-based device. It is already known that applications will not be portable to Windows CE .NET 4.2 if certain device specific APIs are called. Pocket PC applications tend to follow certain rules; for example, application windows, dialog boxes, and message boxes are typically full screen. Application developers are careful about the placement of controls within an application's client area so that the Soft Input Panel (SIP) does not hide controls when activated. Screen real estate is limited on Pocket PC devices. The hardware design guide states that Pocket PC devices must have screens of 240 X 320 resolution. This restriction does not apply to Windows CE .NET 4.2-based devices; therefore, application windows and layout should scale appropriately. To show binary application portability, a simple Win32 application using eMbedded Visual C++ 3.0 has been built. The code is based on the Pocket PC 2002 SDK Win32 Application. The application supports Pocket PC device and Pocket PC Emulator. In this case, the Windows CE Emulator will be used to test the application. The following illustration shows the Pocket PC application running in the emulator. Figure 1. You can use Dumpbin.exe, which is installed with eMbedded Visual C++, Visual Studio® .NET or Windows CE .NET development tools, or Depends.exe, which ships with eMbedded Visual C++, to view the applications imports. This will show the required dynamic-link libraries (DLLs) for the application; Most of the Coredll.dll imports have been removed from the listing since they are not important for this paper. Note that applications can also load DLLs at run time by calling LoadLibrary, Dumpbin will not list any dynamically loaded DLLs, this means that a Pocket PC 2002-based application may still fail to run on a Windows CE .NET 4.2-based device. Dump of file foo.exe File Type: EXECUTABLE IMAGE Section contains the following imports: COREDLL.dll 13014 Import Address Table 1205C Import Name Table 0 time date stamp 0 Index of first forwarder reference Ordinal 95 Ordinal 86 AYGSHELL.dll 13000 Import Address Table 12048 Import Name Table 0 time date stamp 0 Index of first forwarder reference Ordinal 34 Ordinal 84 Ordinal 83 Ordinal 56 Notice that a basic Win32 Pocket PC application is importing four functions from AYGSHELL.dll. These are ordinals 34, 56, 83, and 84. You can discover which functions are being imported by using the shared source that ships with Windows CE .NET 4.2. DLL functions are exported through a projects .def file, described in the following extract from aygshell.def. This shows that the Win32 application is calling SHCreateMenuBar, SHInitDialog, SHHandleWMSettingChange, and SHHandleWMActivate. C:\WINCE420\PUBLIC\SHELLSDK\OAK\LIB\ARMV4\DEBUG\aygshell.def ; AYGShell.def LIBRARY AYGSHELL EXPORTS SHCreateMenuBar @34 SHInitDialog @56 SHHandleWMSettingChange @83 NONAME SHHandleWMActivate @84 NONAME To test out binary application portability, a Windows CE .NET 4.2 debug operating system image has been built. The image is based on the Internet Appliance platform configuration. We can use the Remote File Viewer application to upload the Pocket PC 2002-based application to the running operating system image. You can execute the application through the Windows CE .NET explorer shell; interestingly, the application fails to run. You can use the debug output window within Platform Builder to determine the cause of the failure. Here is the output from Platform Builder. 0x83e0d800: DoImport Failed! Unable to import Library 'AYGSHELL.dll' for '\Foo.exe' 0x83e0d800: CreateNewProc failure on \Foo.exe! The debug output shows that the application failed to launch because AYGSHELL.dll was not found on the device. Windows CE .NET ships AYGShell as a component in the Platform Builder catalog. As a system builder, you get to decide whether to add AYGShell support for your platform; Platform Builder reports that AYGShell adds approx 58 KB to a platform. AYGShell support can be added to a platform either by adding the AYGShell component from the catalog, or by setting the SYSGEN_AYGSHELL sysgen variable. After AYGShell support has been added to the Windows CE .NET 4.2 platform, the application runs as expected. Here is the same application binary running in the Windows CE .NET 4.2 emulator. Notice that the applications menu is displayed at the bottom of the screen. This is of course default behavior for Pocket PC applications. Figure 2. Using Platform Builder Dependency Information (right-click a component, and then click Dependencies). You can see that AYGShell will be added to a platform if you include any of the following components into a platform: Help, Microsoft Pocket Internet Explorer, Standard SDK for Windows CE .NET, and Pocket Internet Explorer HTML View. Figure 3. MFC ApplicationsWindows CE .NET 4.2 ships with MFC support through an MFC catalog component; this component adds MFCCE400.dll to an embedded device image, which is a retail build of MFC for Windows CE. Note that eMbedded Visual C++ 4.0 SP2 will download a debug build of MFC (MFCCE400D.dll) to a platform when testing a debug build of an application. Pocket PC 2002-based devices contain MFCCE300.dll in read-only memory (ROM), applications developed for Pocket PC 2002 using Microsoft Foundation Classes require MFCCE300.dll, Windows CE .NET 4.2 ships with MFCCE400.dll; therefore, MFC applications developed for Pocket PC 2002 will fail to run on Windows CE .NET 4.2-based devices. In addition, MFCCE300.dll for Pocket PC 2002 imports DocList.dll, a Pocket PC 2002 specific DLL which is not available with Windows CE .NET 4.2; therefore, Pocket PC 2002 MFC applications will not run "as is" on Windows CE .NET 4.2. At a minimum, you must rebuild the application source code. The following APIs are exposed through AYGShell.
ConclusionThe addition of AYGShell support to Windows CE .NET 4.2 provides a way for developers of Pocket PC 2002-based applications to also target embedded systems based on Windows CE .NET 4.2. Developers should be aware of the APIs being called by their application in order to provide source-level or binary-level compatibility between Pocket PC and Windows CE .NET-based applications. Additional ResourcesFor more information about Windows CE .NET, see the Windows Embedded Web site. For online documentation and context-sensitive Help included with Windows CE .NET, see the Windows CE .NET product documentation. For more information about Microsoft Visual Studio® .NET, see the Visual Studio Web site. |
![]() |