Native code applications and resources (DLLs and static libs) as well as device drives can be developed as part of the operating system project. They are created as subprojects of the OS and can be configured to be in debug or release mode separate from the OS’s configuration. They can also be configured to be built with the OS and to be included in eth OS image. In development phase it is simplest though to not include them in the image as they can then be modified and rebuilt whilst the OS is running.
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 app that depends upon them.
A Windows Native Code application can be a Console app or a Windows Form app. A Console app 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 app can be built using static link libraries or use DLLs. Windows Forms apps present a Forms based user interface and implement the UI event handlers. Such an app will continue to run until the user exits it. These apps 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 apps directly with PB involves creating them as OS Subprojects as with previous versions of PB.
Whether you develop a native app 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 app 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: SDK Application Development
Click here to provide feedback and input