C# code to soft reset a Windows Mobile device
Here is the C# code to soft reset a Windows Mobile device (using P/Invoke)
[DllImport("coredll.dll", SetLastError = true)]
static extern int SetSystemPowerState(string psState, int StateFlags, int Options);
const int POWER_FORCE = 4096;
const int POWER_STATE_RESET = 0x00800000;
private void SoftReset()
{
SetSystemPowerState(null, POWER_STATE_RESET, POWER_FORCE);
}
Microsoft to continue support for Ruggedized Handheld market
Ruggedized handhelds are a class of mobile devices that are designed to run mission critical applications while withstanding the harsh environments. Several OEM like Motorola/Symbol, Intermec, Psion Teklogix, Honeywell have been building ruggedized handhelds for several years now. Most of these devices are based on Micrsoft Windows CE and Windows Mobile operating systems. Recent whitepaper from VDC Research says that Microsoft has 87% share in this market. All these OEMs together shipped around 2.3 million devices in 2009, which is projected to reach 4.3 million by 2014. Besides that there already are around 12 million ruggedized devices in use.
Since Windows Phone 7 has been announced there was a growing concern among OEMs regarding future support from Microsoft for its existing Windows CE (latest version 6.0) and Windows Mobile (latest version 6.5) platforms. Note that Windows Phone 7 is a very different platform with almost no similarity with the CE and Windows Mobile and is targeted towards consumers and to lure back iPhone users :).
Enterprises and Consumers have different needs and both are important. Microsoft has started a new program Windows Embedded Handheld to protect the existing enterprise investments and to continue to releasing newer mobile platforms with minimum porting requirements.
Microsoft's commitment to the future of enteprise mobile devices will be a welcome news for OEMs, System Integrators, ISVs and Enterprise customers.
How to get information about softwares installed on Windows Mobile devices?
Best method is to ask the configuration service provider (CSP).
Step 1: Add Reference to Microsoft.WindowsMobile.Configuration
Step 2: Add the following statements at the top of the c# code file.
using System.Xml;
using Microsoft.WindowsMobile.Configuration;
Step 3: Prepare a csp string (xml format) and pass it to ProcessConfiguration method of ConfigurationManager. Return value is the xml string which contains all currently installed softwares on the device.
private void ListInstalledSoftwares()
{
string cspString = "<wap-provisioningdoc><characteristic-query type=\"UnInstall\"></characteristic-query></wap-provisioningdoc>";
XmlDocument xmlResult = null;// Use CSP to get list of installed applications
try
{
XmlDocument configDoc = new XmlDocument();
configDoc.LoadXml(cspString);
xmlResult = ConfigurationManager.ProcessConfiguration(configDoc, false);
Debug.WriteLine(xmlResult.InnerXml);
}
catch (Exception ex)
{
Debug.WriteLine("Failed to get list of installed applications. CSP failure. [Exception: " + ex.Message + "]");
}
}
How to disable “Unsigned Prompt Policy” on Windows Mobile?
Many Windows Mobile (Pocket PC) devices ship with one-tier security configuration enabled. That means if an unsigned application is started, then the user is prompted whether to allow the unsigned application to run or not. If the user based on his/her judgment allows the application to run, the application runs in privileged mode whereby it can access all system APIs and protected registry keys.
Now this feature can be very annoying during development. So rather than signing the executable the developer can temporarily disable the Unsigned Prompt Policy by making some registry changes.
Steps to disable Unsigned Prompt Policy on Windows Mobile:
- Use Remote Registry Editor or a third-party tool such as PHM Registry Editor.
- Set the following registry value to 1 to disable Unsigned Prompt Policy. (Default value is 0).
; Unsigned Prompt Policy
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]
"0000101a"=dword:1Note: Create the above registry entry if it does not already exist.
How to get process id and thread id from a Window Handle in .NET CF?
Specify the namespace for doing P/Invoke stuff i.e. calling Win32 API functions from managed code.
using System.Runtime.InteropServices;
GetWindowThreadProcessId Win32 function retrieves the identifiers of the process and thread that created the specified window.
Here is how we declare GetWindowThreadProcessId for use in managed code (c#).
[DllImport("coredll.dll")]
private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);
Description:
- hWnd is the window handle
- lpdwProcessId stores the process identifier after the method returns
- return value of the function is the id of the thread that created the window
Calling GetWindowThreadProcessId via P/Invoke:
// Set the hWnd value below with window handle of your interest
IntPtr hWnd = this.Handle;
uint processid = 0;
uint threadid = GetWindowThreadProcessId((IntPtr)hWnd, out processid);
And there you go....
How to display Settings screens or Control Panel Applets in Windows Mobile?
Windows Mobile Control Panel applets are normal dlls renamed with special extension .cpl. They are actually loaded by ctlpnl.exe process.
Following code snipped is what you need if you want to show a Control Panel applet from your program. This way you make it easy for your user to change desired settings, without any “complex” navigation.
BOOL ShowControlPanelApplet(int id)
{
TCHAR szParams[32];
SHELLEXECUTEINFO execinfo = {0};
memset(&execinfo, 0, sizeof(execinfo));
execinfo.cbSize=sizeof(execinfo);
execinfo.lpFile=TEXT(“\\windows\\ctlpnl.exe”);
execinfo.lpVerb=TEXT(“open”);
// Id value determines which control applet will be launched
// For e.g. 23 for bluetooth applet
wsprintf(szParams, L”cplmain.cpl,%d”, id);
execinfo.lpParameters = szParams;
BOOL bRet=ShellExecuteEx(&execinfo);
return bRet;
}
The parameter id refers to the control panel applet that you want to show. Below is the table of id values and the corresponding applet names.
Control Panel Applet Id Values
1 Password
2 Owner Information
3 Power
4 Memory
5 About
6 Brightness
7 Screen
8 Input
9 Sounds & Notifications
10 Remove Programs
11 Menus
12 Buttons
13 Today
14
15 Beam
16 Clocks & Alarms
17 Configure Network Adapters
18 Regional Settings
19 Connections
20
21
22 Manage Certificates
23 Bluetooth
24 Error Reporting
25 GPS Settings
26
27 USB to PC
Follow us on Twitter http://twitter.com/42gears
Feature Checklist of Mobile Device Management tools
Mobile Device Management (MDM) refers to the approaches or solutions used by companies to remotely manage their mobile devices (PDAs, Smartphones, Laptops, Netbooks). Variety of devices involved pose a big challenge for anyone who intends to implement a Mobile Device Management Solution. In fact, a single solution may never fully satisfy the all the requirements. Hybrid solutions (multiple solutions from different vendors doing complimentary tasks) is a common approach that is used to solve this problem.
Here is a checklist of features that a typical Mobile Device Management solution should have:
* Remotely initiated Software Installation
* Remotely initiated Software Un-installation
* Device Inventory tracking (Including Firmware versions and information about various hardware components)
* Software Inventory tracking (Including OS versions and versions of installed third-party applications)
* Backup and Restore of critical business data
* Control user access to certain approved applications and features only
* Physical Device Tracking with GPS (View the device location on a map)
* Remote locking in case of attempts for unauthorized access
* Remote Wipe in case of attempts for unauthorized access
* Remote Control for administrative purposes (Remotely view device screen and perform user actions like mouse clicks or stylus taps).
* Device Health Check (Alerts and manual detection of issues)
* Gather Device Data for Audit purposes (e.g. Call Log Information, Information regarding SMS and Network usage etc.)
* Capability to send Alerts and Messages to mobile users
* Generate Reports
All of the above features can be further classified into various sub-features. That makes it really hard for any one solution to solve the Mobile Device Management problem. 42Gears is also attempting to solve this problem by developing multiple tools such as SureLock Studio, AirLink and WipeMyDevice.
42Gears develops mobile device management tools for enterprises. Read more information about our products here.
Can Microsoft get back its Mojo with Windows Mobile 7?
There have been speculations as to whether Microsoft will remain an important player in the mobile phone market with their Windows Mobile operating system. Numerous news articles and blog posts have “declared” the imminent death of Windows Mobile. This article lists a few reasons why these speculations might not eventually turn out to be true.
It is generally agreed that Windows Mobile has problems. We can compare it to Windows Vista which was not accepted very well by the market. Microsoft came back with Windows 7 which has turned out to be successful even after Vista’s debacle. They have learned from the problems and fixed them in Windows 7. Though the desktop and mobile platforms belong to different worlds, we must recognize the approach Microsoft took. The point is; Microsoft can certainly fix what is currently broken in Windows Mobile.
Microsoft rules desktop OS market with over 90% market share and it will make sense if Microsoft uses it to their advantage in mobile space as well.
Windows Mobile also rules the rugged handheld device market. Companies have tried various alternatives, including free “Linux” and failed. They went back to using Windows Mobile based devices for their day-to-day business activities related to mobility. For anything more than email access, companies still prefer Windows Mobile.
Windows Mobile is built on a solid platform. People have been cribbing about its “bad” and outdated “look and feel”. But this “look and feel” was a well-thought-of decision when Windows Mobile or Pocket PC (as it was called earlier) was designed. Microsoft did not want anyone to put any effort in learning how to use their new operating system. Infact, almost no learning was required if you already knew how to use Windows on the PC. They added a Start button on Windows Mobile taskbar!
WM 7 screenshots are available on the internet like here. Not sure if they are true, but if they are real, then surely MS is up to something great. The release has been delayed and MS had to release a stop-gap WM 6.5 version which has received fairly good reviews. WM 6.5 might hold-off the attack till WM 7 starts the counter attack.
iPhone and new devices running Android have tasted initial success by having a nice “look and feel” and jazziness. Their next challenge would be to get better integrated with the desktop environment, where Windows has complete domination. You think its going to be easy! Nope. That is where they will struggle. Microsoft has already solved that problem; the only thing they have to do is to “modernize” the look and feel of their operating system (WM) and they will be good.
It remains to be seen if Microsoft will really get their Mojo back with the release of WM 7. Until then let’s see what the industry analysts write about Microsoft’s departure from the mobile arena.
42Gears develops mobile device management tools for enterprises. Read more information about our products here.
Simulating key presses in your program with keybd_event function
Out of need or curiosity you might want to know how to send key presses from your native application. The core of the solution involves calling keybd_event() function which has the following prototype.
VOID keybd_event(BYTE bVk, BYTE bScan, DWORD dwFlags, DWORD dwExtraInfo);
bVk is the virtual-key code of the character. bScan is the hardware scan code. dwFlags is an important field. If KEYEVENTF_KEYUP is specified in dwFlags field, the key is being released. If not specified, the key is being pressed.
Here is a function which simulates pressing of alphanumeric characters. See winuser.h for all available virtual key codes.
void SendStringKeys(char* pszChars)
{
while (*pszChars != NULL)
{
if ( (*pszChars >= 'A') && (*pszChars <= 'Z') )
keybd_event(VK_SHIFT, 0, KEYEVENTF_SILENT, 0);keybd_event(toupper(*pszChars), 0, KEYEVENTF_SILENT, 0);
keybd_event(toupper(*pszChars), 0, KEYEVENTF_KEYUP|KEYEVENTF_SILENT, 0);if ( (*pszChars >= 'A') && (*pszChars <= 'Z') )
keybd_event(VK_SHIFT, 0, KEYEVENTF_KEYUP|KEYEVENTF_SILENT, 0);pszChars++;
}
}
And here is an example of how to call SendStringKeys function.
int _tmain(int argc, _TCHAR* argv[])
{
SendStringKeys("Hello World.");
return 0;
}
Determining IP Address of a Windows Mobile device
Code to determine IP addresses of adapters on a Windows Mobile device, using IPHelper APIs.
Add Iphlpapi.lib to linker settings.
#include "Iphlpapi.h"
PIP_ADAPTER_INFO pinfo = NULL;
ULONG OutBufLen = 0;
DWORD dwRet = GetAdaptersInfo(NULL, &OutBufLen);
if (dwRet == ERROR_BUFFER_OVERFLOW)
{
pinfo = (PIP_ADAPTER_INFO)malloc(OutBufLen);
dwRet = GetAdaptersInfo(pinfo,&OutBufLen);
while (pinfo != NULL)
{
if (dwRet==ERROR_SUCCESS)
{
PIP_ADDR_STRING pAddressList = &(pinfo->IpAddressList);
do
{
printf(pAddressList->IpAddress.String);
pAddressList = pAddressList->Next;
} while (pAddressList != NULL);
}
pinfo = pinfo->Next;
}
free(pinfo);
}