Native Code Application Development
Windows Embedded Compact native code programs are structured as dirs and sources projects. This mechanism is a recursive mechanism and permeates the whole of Windows Embedded Compact build process and the OS folders it navigates through in a build process. A build will start in a folder with a dirs. file. A dirs file is a text file of that name (no extension) that exists in a folder to tell build.exe which folders to enter to build. Build will exit a folder (up one level) when all of the folders have been navigated. If a folder has a sources file (again of that name with no extension) it builds the target specified in the file according to the specifications in the file and then exits back up the tree one level to the calling folder. When a native code application is generated by Platform Build, a sources file along with a project file (.pbxml) are generated. If an application requires static or dynamic link libraries, then the whole project can be configured using dirs. and sources to build the libraries first, then build the application that depends upon them.
Windows Native Code application can be a Console application or a Windows Form app. A Console application runs from a command line and will typically do some processing and generate some output text and finish. It may take some inputs from the command line or from inputs such as a keyboard. In running it can access Windows and other resources through APIs. A Console application can be built using static link libraries or use DLLs. Windows Forms applications present a Forms based user interface and implement the UI event handlers. Such an application will continue to run until the user exits it. These applications can also use Windows and other resources as well as be implemented using static and dynamic linked libraries.
As with the operating system development, application development for WEC2013 must be done in in Visual Studio 2012 with Update 2. You can install Platform Builder and build native applications from there, add Application Builder to the PB installation and use that, or alternatively just install Application Builder in Visual Studio 2012 (with the Update 2). Building applications directly with PB involves creating them as OS Subprojects as with previous versions of PB.
App Builder involves using a Visual Studio project template from an SDK developed from the OS. With previous versions of Windows Embedded Compact/CE, you could install the Windows CE 5 SDK and create applications to run on the OS using the SDK installed Smart Device project templates in Visual studio. Alternatively you could create an SDK for the specific OS install that and use its template, although that wasn’t necessary. With WEC2013, no general SDK is currently available. You must build one first from the OS and install it.
Whether you develop a native application as an OS component or use an SDK template, you can debug the code. This includes deployment, break points, step through code, debug message, watch values etc. The advantage of such development in a PB OS solution is that the OS can be configured to include the application in the OS build. If it is an OS subproject you just include its BIB file in the OS build. If it is a separate project of the OS solution you create an OSDesign BIB entry for it, set its compilation output to the release directory, and set its project as a dependency of the OS so it gets built first. The advantage of using Application Builder is that you don’t need PB installed. The SDK would be developed by the OS developer and made available to application builders such as purchasers of the target system. Hopefully Application Builder will be a publically available.
NEXT: Native Application Development with Platform Builder
Click here to provide feedback and input