Thursday, July 2, 2009

Change the Screen Rotation in your application

Windows Mobile devices allows user to rotate the screen orientation, on some devices, this rotation is automatically done while sliding keyboard is opened to provide the good orientation to user to get a chance to type text using the hardware keyboard. More advanced devices get an accelerometer and can automatically rotate the screen while the user physically rotate the device from portrait to landscape and vice versa.
Windows Embedded CE devices on their side can also have screen rotation enabled, but as they are usually for industrial purposes, this feature is not necessarily enabled.

On both version, when user have to do screen rotation the ChangeDisplaySettingsEx function is used. The sample code below shows up the steps to perform screen rotation.

 
BOOL RotateScreen(int iRotationAngle)
{
int iAngle;

// Check if rotation angle is a multiple of 90 degres
if ((iRotationAngle % 90) != 0)
{
return FALSE;
}

// Screen rotation is a bit field value
// 0 = 0, 1 = 90, 2 = 180, 4 = 270
iAngle = iRotationAngle / 90;
if( iAngle == 3 )
iAngle = 0x4;

//
DEVMODE devMode;
memset (&devMode, 0, sizeof (devMode));
devMode.dmSize = sizeof (devMode);
devMode.dmFields = DM_DISPLAYQUERYORIENTATION;

// Retrieve the supported screen rotation angles
if (DISP_CHANGE_SUCCESSFUL != ChangeDisplaySettingsEx(NULL, &devMode, NULL, CDS_TEST, NULL))
{
return FALSE;
}

// Check if required screen rotation is supported
if (iAngle == 0 || iAngle & devMode.dmDisplayOrientation)
{
memset(&devMode, 0, sizeof (devMode));
devMode.dmSize = sizeof (devMode);
devMode.dmFields = DM_DISPLAYORIENTATION;
devMode.dmDisplayOrientation = iAngle;

if (DISP_CHANGE_SUCCESSFUL != ChangeDisplaySettingsEx(NULL, &devMode, NULL, CDS_RESET, NULL))
{
return FALSE;
}
else return TRUE;
}

return FALSE;
}


Thanks to Alban for his help.

- Nicolas

State and Notifications Broker API

The State and Notification Broker API provide an easy way to get notified while system state changed or registry content changed. This API is available for both Windows Embedded and Windows Mobile operating systems, and works with a provider and client.

The Provider:
The provider create in registry one entry per state managed, and is in charge of the update of those entries when states changed. Usually system states are defined in HKEY_CURRENT_USER\System\State and HKEY_LOCAL_MACHINE\System\State, and user defined (or applicative) states are located in HKEY_CURRENT_USER\Software\State and HKEY_LOCAL_MACHINE\Software\State. The snapi.h header file defines most of the system states notifications for various system functionalities like Phone, Mails, SMS Appointment, Battery, Screen Rotation ... and custom entries should be managed by your own.

The Client:
The client register to a state defined in registry by the Provider, and get notified by the operating system while value changed. Different notifications mechanism can be used :
  • Application activation : can start a client application while registry content changed (or state changed)
  • Message Queue : signal a state notification through a Message Queue
  • Window message : signal a state notification via a Windows Message loop (WindowProc)
  • Callback : signal a state notification using a call back function

The client should register for state notification using one of the following function depending on the type of notification required (RegistryNotifyApp, RegistryNotifyWindow, RegistryNotifyCallback or RegistryNotifyMsgQueue). When state change notification is received the client should read the value using the regular regsitry functions access, or RegistryGetDWORD or RegistryGetString. While notification is no longer required, the client have to call RegistryCloseNotification to close the notification.

No specific action is required by the provider except to update the registry values while internal application transition should generate external state notifications.

You can find a usage sample in the Windows Mobile SDK sample source code of the Battery Statistic :
%ProgramFiles%\Windows Mobile 6 SDK\Samples\PocketPC\CPP\win32\battstat

- Nicolas

Tuesday, June 16, 2009

Windows Mobile Local Authentication PlugIn

The Local Authentication Plugin (LAP) is a way to identify the user of a mobile phone, while applications need special rights to access features or perform actions. Basically user is prompted for authentication through a password that he previously configure on his mobile. The default LAP provided by Microsoft (see below), is a single PIN password, but you can implement your own if you need.




LAP Implementation
A LAP is a signed DLL share the following entry points :
  • InitLAP : Call by the system to initialise the LAP while loaded.
  • DeinitLAP : Call while LAP is unloaded
  • VerifyUserStart : Call to start the GUI of the LAP
  • VerifyUser : Call to validate the user, with or without a GUI. This functions returns while the user has been authenticated successfully or fails. Multiple calls to this function can be done by the system. Options parameter specifies how the user have to be validated.
    • VU_NO_UI : while the system needs to validate the user, without displaying a window to the user.
  • VerifyUserStop : Call to destroy the GUI and clean up.
  • VerifyUserToTop : Call to bring to top the LAP Window.
  • LAPCreateEnrollmentConfigDialog : Used to display configuration window to configure the pass-phrase of the LAP

To implement your own LAP you can start from scratch or use the sample LAP provided with the Windows Mobile SDK :
  • for pocket PC : %ProgramFiles%\Windows Mobile 6 SDK\Samples\PocketPC\CPP\win32\LAP
  • for smart phone : %ProgramFiles%\Windows Mobile 6 SDK\Samples\Smartphone\CPP\win32\LAP
LAP Installation
The Local Authentication Subsystem (LASS) is in charge of the management of the LAP display and user validation.
To define a new LAP, add a new key in the registry :
[HKEY_LOCAL_MACHINE\Comm\Security\LASSD\LAP\myLAP]
"Dll"="myLAPDll.dll"

To select the current active LAP set the
[HKEY_LOCAL_MACHINE\Comm\Security\LASSD\LAP]
"ActiveLap"="myLAP"

LAP Configuration
The LAP Configuration should be done by the user through the Enrollment window accessible form the Parameter Menu using the Lock icon. In this window the user should be able to change its pass-phrase (or other if the LAP is not based on pass-phrase authentication).
For security reason this pass-phrase should not be saved in the registry as a clear string, but should be encrypted using a custom algorithm or the Windows MobileCryptoAPI.

Validate a User in your application
To check if user has been authenticated on the device you have two possibilities :
  • ValidateUser is a blocking call to the LASS service, and give a way to provide parameters to the LAP, like an AE Key (specific security policy id), options (like VU_NO_UI to check the user without prompting any Window). Functions will return only after user authentication.
APP A;
HWND hMyWindow;

VerifyAndCallSecureFunction()
{
DWORD LastError;
GUID AEKeyForFoo = ...;
if (VerifyUser(&AEKeyForFoo,"App A",hMyWindow,
VU_UNTIL_SUCCESS,0)) // Call into LASS;
// This will
CallSecureFunction() // call into active LAP
// and show LAP-specific UI
else
TellUserVerificationFailed(GetLastError()));
// display your own UI
}

  • SHDeviceLockAndPrompt is a non blocking call, but will require user authentication for any activity on the device.

- Nicolas

Tuesday, June 9, 2009

CERegEditor : an alternative to Remote Registry Editor

Found a great atlternative to the Remote Registry Editor, without the requirement of the installation of a Visual Studio Smart Device component. Useful for non developper's guys...
One of my favorite feature is the registry comparison, between two snapshots.
Check out this cool application here.
- Nicolas

Easy way to componentize modules

Since Windows CE 4.2, Mike Hall is maintaining a power toy application helping to componentize your applications, drivers to integrate them inside your catalog views. This application is now available under the MSDN Code Gallery.

Big thanks to Mike for this CEFileWiz application helping beginners for an easy and quick understanding of the requirements for a componentized module.
- Nicolas

Wednesday, June 3, 2009

Get Ready for Windows Mobile 6.5


Microsoft announced last month the Windows Mobile 6.5 Release, and provide today an access to the Windows Mobile 6.5 Tool Kit to get your softwares ready for new coming mobile devices runnning this version of the operating system.



- Nicolas

Tuesday, June 2, 2009

WES 2009, Virtual PC and Windows PE [Updated]

When experiencing Windows Embedded Standard, you need an x86 device to boot the OS. The first solution is to use a spare computer and deploy the Runtime image to the hard drive at every OS re-generation. Except if you are a skew driver fan, but mounting and unmounting the hard-drive to push the new binaries on the target, is quite painful after two or three manipulations. So another solution could be to use the current hard drive of your development computer, and reserve a partition for WES. In this case no screw driver is required, as the partition is visible directly under the OS of you development computer. The only restriction, in this case, is too reboot the development machine to get the WES OS booted. But this solution is also painful, as booting the development OS can take a while, and all development tools have to be reloaded. The ultimate solution is to use an x86 virtualizer, like Virtual PC or other. When using the virtualizer, the way to reboot the WES OS is by launching the virtualizer software.

Use a Virtual PC :
First you need to create a new virtual machine and a hard drive, you can find all the details in the Virtual PC blog.
Then you have to prepare the hard drive to receive the WES files. And for this, you have to create a partition.... and at this point you are locked, except if you have in your drawer, an old booting floppy disk and a floppy disk reader...
Microsoft is providing for IT's a Windows Automated Installation Kit, available for free from their website. This kit provides cool applications, called WinPE, and ways to easily have a booting CD-ROM iso that can be customised to integrate all the applications that can be useful to deploy an OS, like Windows XP, Vista, and WES.

Prepare your booting CD-ROM :
After downloading and installing the AIK package, launch Startup Menu->Microsoft Windows AIK->Windows PE Tools Command Prompt.
1) Initial Folder Creation
copype x86 [Destination_Folder_Path]

2) Add custom Files
Copy required custom files to the ISO folder in \ISO. Like bootsect.exe available in "Windows AIK\Tools\PETools\x86".

3) Build the customized ISO
oscdimg -n -b[path to etfsboot.com file]\efsboot.com [path to the ISO folder] [path and name of the iso to generate]


Boot the ISO :
When the iso image is generated, then you have to boot it under Virutual PC, by launching the Configuration done previously and going to the CD menu. Then attach the iso file, and Virutal PC should boot on the virutal CD-ROM drive.

Partitions creations :
When WinPE 2.0 boot up, it initialize a shell from where you can launch batch scripts or single comands. >e gonna use diskpart to create, format partition.
Launch dispart from the shell window (PERFORM ALL THOSE COMMANDS FROM THE VIRTUAL PC COMMAND WINDOW ONLY).


1) List the available disks :
list disk

2) Select the disk
select disk 0

3) Clean Up the disk
clean

4) Create a partition
create partition primary size=XXXXX

5) Assigne a letter to the partition
assign letter=C

6) Format the partition
format fs=ntfs quick

7) Activate the partition to be bootable by the Virutal PC BIOS
active

8) Exit diskpart
exit

Then you have to store the boot sector on the partition, diskpart provided with WinPE 2.0 store by default the Vista boot sector, that is not compatible with WES 2009.
9) Prepare boot sector
bootsect /NT52 C:
Note : bootsect.exe can be found in the AIK installation folder and pushed into the CD-ROM Iso

Push files to the target :
The hard drive is now ready to receive the WES runtime files, and the easy way to push those files from the development machine to the virtual hard drive is using the network and the sharing capabilities of Windows.
Share the folder used for the generation of the WES image on the development computer, and use netuse from the Virtual PC to access it.
Then use xcopy to get the files onto the virtual hard drive.

Conclusion :
Using the Virtual PC is fairly easy to get and experiment WES.

- Nicolas