Wednesday, September 3, 2008

Get Name of Executing *.EXE

The Compact Framework doesn't support Assembly.GetEntryAssembly to determine the launching .exe. You can instead P/Invoke the native GetModuleFileName function like so:-

byte[] buffer = new byte[MAX_PATH * 2];

int chars = GetModuleFileName(IntPtr.Zero, buffer, MAX_PATH);

if (chars > 0)

{

string assemblyPath = System.Text.Encoding.Unicode.GetString(buffer, 0, chars * 2);

}

Where MAX_PATH is defined in the Windows CE headers as 260. The P/Invoke declaration for GetModuleFileName looks like this:-

[DllImport("coredll.dll", SetLastError = true)]

private static extern int GetModuleFileName(IntPtr hModule, byte[] lpFilename, int nSize);

The function expects a HMODULE - a handle to a native module. However passing IntPtr.Zero here indicates we want the module which created the process which is our .exe. This code will always return the path of the calling .exe regardless of if it is in a utility dll, or even a GAC assembly located in the \Windows folder.

Source: Peter Foot

Friday, August 22, 2008

Creation Of NK.NB0 File

The nk.bin file is the Windows CE binary image that is usually transfered from Platform Builder to the Windows CE device, but for platforms you need to provide the nk.nb0 files. The nb0 files is a raw version of an bin file, that means that this file can be directly loaded in the SDRAM and executed from there.

Manual generation of an nb0 :
Platform builder environment provide two tools for the generation of the nb0 files. The first one Viewbin used to see the properties of the bin file, the second one Cvrtbin used to convert the bin file into an nb0 file using the information provided by viewbin.
So open your OSDesign and go to Build -> Open Release Directory in Build Window, it will show up a command line window setup for your project.
Use : viewbin nk.bin
ViewBin... nk.bin
Image Start = 0x00220000, length = 0x00AC136C
Start address = 0x0023D618
Checking record #72 for potential TOC (ROMOFFSET = 0x80000000)
Found pTOC = 0x80ce02c0
ROMOFFSET = 0x80000000
Done.

Using this output, the following code example shows the syntax used to create an nk.nb0 file, using the values found in the Image Start and length lines:
cvrtbin -r -a 00220000 -l 00ac136c -w 32 nk.bin

Values may vary for your nk.bin as those information are related to the settings of your BSP and OSDesign.

Source: Nicolas Besson

Tuesday, April 22, 2008

Microsoft Visual Studio & Microsoft Windows CE Development

Developers building Windows CE based devices fall into one of two groups, you are either an operating system developer, or an application developer (and yes, you could be both).

1. Operating System Developer.

For the operating system developer, the CE 6.0 development tools are a plug in to Visual Studio 2005 - the Full CE 6.0 product ships with a full version of Visual Studio 2005 - The CE 6.0 development tool (Platform Builder) gives you the ability to configure, build, download, and debug your custom operating system image. Platform Builder also gives you the ability to write Win32 (C/C++) applications, or DLLs (where the DLL can export functions shared between applications, resource only DLLs, or the DLL could be a device driver in the operating system image).

Operating system developers need Visual Studio 2005, and the CE 6.0 development tools.

2. Application Developer.

Application developers typically don't need access to the underlying operating system development tools, the application developer codes against a "platform". For native code developers (Win32, MFC, *TL), this means that you code against a Windows CE Platform SDK - since you are a native code developer this means that you are calling the Win32 APIs on the operating system directly (MFC is a thin wrapper over Win32) - Since Windows CE is a componentized operating system the exact APIs exposed from a customized "platform" are determined by the embedded operating system developer.

Once a Windows CE configuration is complete, the embedded o/s developer builds a custom SDK (Software Development Kit) that defines the exposed APIs for that specific platform (through header files and libraries). This SDK can then be shared with application developers who install the SDK into Visual Studio 2005 and/or Visual Studio 2008.

The native code developer codes against the custom platform SDK.

Managed code developers have a slightly easier time - the .NET Compact Framework *defines* the underlying platform APIs, when you add the compact framework to a platform configuration a set of operating system dependencies automatically gets added to the platform - as a managed application developer you know that the .NET class libraries are there - if you want to escape the box (platform invoke) then you need to know which native code APIs exist for your specific platform.

Application developers can choose to develop using Visual Studio 2005 OR Visual Studio 2008.

Source: Mike Hall

Detect Windows Mobile Version – Adaptation Kit Update (A.K.U.)


If you want to know which version of known Adaptation Kit Update (AKU) releases you have in your device, check out this link.

To see the AKU of your device, you can :
type : Start / Settings / System Tab / About
Using a C# application, the OSVersion.Version method returns build information.
Using the Registry : HKLM\SYSTEM\Versions\Aku

Source: Fabien Decret

Create Custom Animated Cursor

Most .NET Compact Framework developers will be familiar with the Cursor.Current property and how to display the standard Wait Cursor, but did you know that you could easily display your own custom cursor? This blog entry discusses how you can replace the standard wait cursor with your own application specific cursor. This is an ideal way to brand kiosk style applications for example.

Creating a custom cursor

Recent versions of the Windows CE operating system (and hence Windows Mobile) support an OS API called LoadAnimatedCursor. This API enables you to specify a sequence of individual bitmap frames and will convert them into an animated cursor. For example an animated cursor of a rotating monkey could be made up of the following 4 bitmaps, for example, bitmap value 101, 102, 103 and 104.

The more frames the cursor consists of the smoother the animation will be. Individual frames within the animation should be 48×48 pixel bitmap resources within a *.dll or *.exe file. The bitmap resources are identified by a numeric ID and must be in sequential order (such as the values 101, 102, 103 and 104 used in the example above).
The id of the first bitmap, the total number of frames and the period of time to delay between frames is then passed into the LoadAnimatedCursor API which will return a handle to the newly created cursor (an HCURSOR). Passing this handle to the SetCursor API will then make the cursor visible on the screen.

Unfortunately the LoadAnimatedCursor function is not as easy to use from managed code as it should be. The API expects the bitmap images to be native bitmap resources meaning you can not store them within a *.resx resource file within your .NET Compact Framework application. The easiest way to store the bitmaps in the correct format is to create a native C++ DLL project. You can then remove all the C++ source files, leaving a sole Win32 *.rc resource file to which you can add the bitmaps to (as will be demonstrated later).

Sample Application

[Download animatedcursortest.zip - 37KB]

The sample application available for download consists of two projects. The first (called AnimatedCursors) demonstrates how to create a resource only DLL that contains the bitmap images required for the two custom cursors shown above.
The second project is a C# example demonstrating how to use Platform Invoke to access theLoadAnimatedCursor and SetCursor APIs to display the custom cursors. This second project loads the custom cursors from the AnimatedCursors.dll file built by the first project.

The C# sample wraps up the required Platform Invoke code within a class called AnimatedWaitCursor. This class implements the IDisposable interface so that the following syntax can be used to display a custom cursor. This code structure should be familiar to anyone who has used MFC's CWaitCursor class.

// Use the animated cursor that has 4 frames starting with
// bitmap id 101, delaying 125 milliseconds between each frame.
string dll = @"\path\to\some.dll";
using (AnimatedWaitCursor cursor = new AnimatedWaitCursor(dll, 101, 4, 125))
{
// do some long running task
}
Source: Christopher Fairbairn

Using Delegates (i.e. Function Pointers)

Ever since learning how to use function pointers in C, I've always been a fan of using them to help make code a bit more usable, especially when you've got a state machine. Today, as I'm working on a Wizard UI for a desktop application I came across a typical scenario for using a function pointer. Depending on the stage of the Wizard you're in, a button will have to do separate things.

That got me to thinking that most managed developers simply don't understand the power and utility of delegates, but instead simply consider them a necessity when using Control.Invoke or creating custom events. Sure, in my case I could have a switch statement in the click handler and do logic there, or I could unhook the click handler from one method and hook it to another, but those all seem ugly and a pain in the ass to me. A simple function pointer change is all you need. So I decided I'd throw together a really simple example of how you would use a delegate to change the behavior of a Button click.

Let's assume that we have a button that we want to click, and when it's clicked it will do one of 4 things, depending on the state of our application. We'll just use a messagebox here to give you the idea - what it does is up to you- it's a function after all.

public
void FunctionA()
{
MessageBox.Show(
"FunctionA");
}

public
void FunctionB()
{
MessageBox.Show(
"FunctionB");
}

public
void FunctionC()
{
MessageBox.Show(
"FunctionC");
}

public
void FunctionD()
{
MessageBox.Show(
"FunctionD");
}

To simulate the different "states" I simply added a ListBox (called functionList) to the Form and manually added the function names to it in the Form's constructor. Sure, I could have used Reflection to be clever and populate the list, but I'm tryiong to keep it simple and show delegates.

functionList.Items.Add("FunctionA");
functionList.Items.Add(
"FunctionB");
functionList.Items.Add(
"FunctionC");
functionList.Items.Add(
"FunctionD");

Alright, so now we know that depending on which item is selected, we want to call one of our four functions. Since they all have the same interface (and they have to to use a delegate) we simply define a delegate that matches them. This delegate can be privately scoped inside your class.

delegate
void FunctionDelegate();

And then we create an instance variable to hold the current function pointer we want to use:

private FunctionDelegate m_functionPointer =
null;

We add an event handler for the SelectedIndexChanged event of the ListBox (in the Form constructor)

functionList.SelectedIndexChanged += new EventHandler(functionList_SelectedIndexChanged);

And implement the event handler. It simply looks at the newly selected index in the list and changes the value stored in m_functionPointer appropriately.

void functionList_SelectedIndexChanged(object sender, EventArgs e)
{
// determine which function pointer to store based on selection
switch (functionList.SelectedIndex)
{
case 0:
m_functionPointer
= FunctionA;
break;
case 1:
m_functionPointer
= FunctionB;
break;
case 2:
m_functionPointer
= FunctionC;
break;
case 3:
m_functionPointer
= FunctionD;
break;
default:
m_functionPointer
=
null;
break;
}
}

Next we wire up an event handler for our button (again the the Form constructor):

callButton.Click += new EventHandler(callButton_Click);

And finally the magic and simplicity of the state-dependent call

void callButton_Click(object sender, EventArgs e)
{
// call our function (as long as it's not null)
if (m_functionPointer !=
null)
{
m_functionPointer();
}
}

That's all there is to it. Run the application, select a function and click the button.


Get the full source here.

Source: Chris Tacke

Monday, April 21, 2008

Exception Messages on Microsoft .NET Compact Framework 3.5

Exception Messages on .NETCF 3.5

Martijn Hoogendoorn provides a description of how to avoid the message:-

"An error message is available for this exception but cannot be displayed because these messages are optional and are not currently installed on this device. Please install 'NETCFv35.Messages.EN.wm.cab' for Windows Mobile 5.0 and above or 'NETCFv35.Messages.EN.cab' for other platforms. Restart the application to see the message."

Even if you have installed the cab file with message resources.

Source: Peter Foot

Fixing Exception Messages on the .NET Compact Framework 3.5

I recently ran into trouble while developing for the .NET Compact Framework, v3.5. Upon all exceptions, the framework would tell me:

"An error message is available for this exception but cannot be displayed because these messages are optional and are not currently installed on this device. Please install 'NETCFv35.Messages.EN.wm.cab' for Windows Mobile 5.0 and above or 'NETCFv35.Messages.EN.cab' for other platforms. Restart the application to see the message."

Interpreting the message as 'I have to run the NETCFv35.Messages.EN.wm.cab (I'm developing an application for WM6) on my device', I copied the file from C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\Diagnostics onto my mobile device and ran the installation.

To no avail, nothing changed and I was stuck. After installing the 'Power Toys for .NET Compact Framework 3.5', however, I configured logging using the '.NETCF Logging Configuration' application and found the following error for the loader log:

'Attempt to load [\Program Files\SomeApp\System.SR.dll] has failed (err 0x80001000).'

Renaming the file 'SYCCFA~1.001', included in the aforementioned CAB file into System.SR.dll and adding it as a reference in my application proved to fix the issue. I now had readable exception messages.

Just jotting this down as there's nothing to be found on the web regarding the issue that I could find.

Source: Martijn Hoogendoorn

Skills Measured by Exam 70-571: Microsoft Windows Embedded CE 6.0 Application Development

This exam measures your ability to accomplish the technical tasks listed in the following table. The percentages indicate the relative weight of each major topic area on the exam.

Customizing the Operating System Design (12 percent)

Configure the operating system (OS) design.
May include but is not limited to: Create initial OS design for given board support package (BSP)/hardware; set the environment variables, build options, and regional settings; manage multiple configurations (e.g., release/debug); identify appropriate catalog items; modify a build configuration to add a new catalog item to OS design

Configure Windows Embedded CE projects.

Clone a component.

Generate a software development kit (SDK).
May include but is not limited to: Create an SDK; configure an SDK; build an SDK

Manage catalog items.
May include but is not limited to: Integrate an existing driver into a Windows Embedded CE development environment; create a catalog item; verify and correct contents of a catalog file

Building and Deploying the Runtime Image (9 percent)

Build the runtime image.
May include but is not limited to: Build from the IDE; build from the command line

Analyze build results.
May include but is not limited to: Interpret build failures; check build status; identify hidden failures (those not identified by IDE as build failures)

Deploy the runtime image to target hardware.
May include but is not limited to: Configure Platform Builder options; download operating system to the target hardware; connect to a target hardware

Performing System Programming (22 percent)

Monitor and optimize system performance.

Implement system applications.
May include but is not limited to: Implement control panel applet; launch a custom shell

Implement threads and thread synchronization.

Implement exception handling.

Implement power management at the system level.
May include but is not limited to: Application-level power management; power management scheme; Power Manager configuration

Debugging and Testing the System (17 percent)

Detect software-related errors.
May include but is not limited to: Detect driver memory leaks; detect deadlocks; detect race conditions

Configure the runtime image to enable debugging.
May include but is not limited to: Entire image or individual module; enable profiling in the OEM Abstraction Layer (OAL)

Test a system by using Microsoft Windows Embedded CE 6.0 Test Kit (CETK).
May include but is not limited to: Use existing CETK tests, including Stress test; create custom tests

Test a boot loader.

Customizing a Board Support Package (BSP)(17 percent)

Configure a BSP.
May include but is not limited to: Modify parameter files (bib, reg, dat files); modify build files

Add power management support to an OEM Abstraction Layer (OAL).

Configure memory mapping of a BSP.

Implement a boot loader from existing libraries.

Share driver resources between hardware and an OAL.
May include but is not limited to: Shared memory; shared interrupts; shared I/O

Developing Device Drivers (23 percent)

Marshall data across boundaries.
May include but is not limited to: Implement a data exchange mechanism between a driver and an application; implement communication between drivers and hardware; load a driver

Implement an interrupt mechanism in a device driver.
May include but is not limited to: Implement an interrupt service thread (IST); communication between interrupt service routine (ISR) and IST; IRQ vs. SYSINTR; Installable ISR

Implement a stream interface driver.

Enhance driver portability.
May include but is not limited to: Package should be hardware-target independent; BUS-agnostic hardware access

Note This preparation guide is subject to change at any time without prior notice and at the sole discretion of Microsoft. Microsoft exams might include adaptive testing technology and simulation items. Microsoft does not identify the format in which exams are presented. Please use this preparation guide to prepare for the exam, regardless of its format.

Source: Microsoft Learning

Microsoft Charts Its Road Map for Windows Embedded Business

Company announces strategy for product renaming outlines plan for new solutions in key device categories and unveils first developer certification.

SAN JOSE, Calif. — April 15, 2008 — Today at Embedded Systems Conference Silicon Valley 2008 in San Jose, Microsoft Corp. laid out the next phase in its strategy for the Windows Embedded Business, providing a strategic road map outlining the renaming of its family of products and plans for new solutions in key device categories. The new key device category solutions will be offered under the Windows Embedded Ready name and will ship as preconfigured toolkits providing device-makers with in-demand market-specific features that allow them to build and ship next-generation smart, connected, service-oriented devices in an accelerated fashion.

"With today's strategic road map announcement, our aim is to present the evolving Windows Embedded product family in an intuitive fashion, making it easier for our customers to choose the right platforms and tools for their needs," said Kevin Dallas, general manager of the Windows Embedded Business at Microsoft. "Windows Embedded solutions for key device categories will energize our partner ecosystem by enabling new business scenarios and help lay the foundation for partners to successfully fulfill our vision of a new generation of smart, connected, service-oriented devices."

The first product release under the new naming strategy will be Windows Embedded Standard, the next generation of Windows XP Embedded, and will be launched simultaneously at Tech•Ed North America and through a global webcast event on June 3. All presently available Windows Embedded products will be marketed under their current names until their next scheduled product release and will remain available for purchase in line with the standard Microsoft Support Lifecycle policy. The Windows Embedded Ready product line for key device categories will include the next generation of Windows Embedded for Point of Service, Windows Embedded POSReady. The Windows Embedded Business plans to further detail its strategy for the Windows Embedded Ready products later this calendar year.

The Windows Embedded family of products includes the following:

Windows Embedded Standard. The next generation of Windows XP Embedded. The next product release is currently forecast for 2008.

Windows Embedded Compact. The next generation of Windows Embedded CE. The next product release is currently forecast for 2009.

Windows Embedded Enterprise. A fully application-compatible embedded operating system that over time will gain a broader set of embedded enabling features. Today this product group is composed of Windows Vista and Windows XP for Embedded Systems and is licensed exclusively for embedded device development.

Windows Embedded POSReady. The next generation of Windows Embedded for Point of Service. The next product release is currently forecast for 2009.









Windows Embedded CE 6.0 Developer Certification and Free Training

Furthering its commitment to growing and empowering the developer community, Microsoft also announced the establishment of Windows Embedded CE 6.0 Certification, the first certification included in the Microsoft Certification Program for the Windows Embedded product family. A key element of the Windows Embedded business strategy, the certification will provide a common reference point on the skills and technical expertise that Microsoft recommends for all Windows Embedded CE 6.0 developers.

Customers developing projects on Windows Embedded CE will now be able to identify partners and distributors based on Windows Embedded technical knowledge. In addition, companies building devices on the Windows Embedded platform and wanting to hire Windows Embedded CE developers will now be able to better differentiate between candidates. In support of the certification, Microsoft is offering a free exam preparation kit for Windows Embedded CE developers. The kit can be downloaded or viewed online and is localized in English, Japanese, Simplified Chinese, Korean, German and French.

The certification exam will be available on May 5, 2008; the official name of the exam is Exam 70-571: TS: Microsoft Windows Embedded CE 6.0 Application Development. It costs $125 (U.S.) and is administered by Prometric testing centers worldwide. Local testing centers can be found at http://www.register.prometric.com/ClientInformation.asp. The free preparation guide will be available on the MSDN Embedded Developer Center at http://www.microsoft.com/learning/exams/70-571.mspx.

Founded in 1975, Microsoft (Nasdaq "MSFT") is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at http://www.microsoft.com/presspass on Microsoft's corporate information pages. Web links, telephone numbers and titles were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may contact Microsoft's Rapid Response Team or other appropriate contacts listed at http://www.microsoft.com/presspass/contactpr.mspx.

Source: Microsoft PressPass