Building Windows CE

Platform Builder: Sources.cmn

Bruce Eitman — Sun, 24 Aug 2008 02:56:33 GMT

Sources.cmn is a build configuration system file that allows you to set common variables. This can be useful if more than one directory in the build tree need the a variable set to the same value because it can reduce your maintenance efforts.

Each build tree can use one sources.cmn file. When build.exe runs, it will determine the root of the build tree by looking for the top most folder with a Dirs file. Build.exe then sets BUILDROOT to the top most folder with a Dirs files. Makefile.def in Public\Common\OAK\Misc will include $(BUILDROOT)\sources.cmn if it exists.

Some of the variables that are commonly set in sources.cmn include CDEFINES, ADEFINES and INCLUDES.

CDEFINES and ADEFINES are used to set macros that are common to multiple build folders. These might include RAM and ROM sizes, but might also include OEM and CPU specific macros.

The include path, INCLUDES, can be set in sources.cmn which is very helpful, especially if and when you change the directory structure.

The Platform directory tree should have WINCEOEM set to 1, so sources.cmn is a good place to do this rather than setting it in each sources file.

Note: Starting with Windows CE 5.0, sources.cmn is no longer really an option. It is required because sources.cmn needs to at least set _COMMONPUBROOT, _ISVINCPATH, and _OEMINCPATH. These were set by build.exe in prior versions.

For more on sources files take a look at: Platform Builder: Sources Files and Platform Builder: Sources Files 2

Go to Summary of Building Windows CE

Tags: Build.exe, Sources

Platform Builder: Sources Files 2

Bruce Eitman — Fri, 22 Aug 2008 22:22:36 GMT

I was looking over my original post about sources files (Platform Builder: Sources Files) today and it occurred to me that there is room to improve. That post provided basic information to create a sources file that will build a driver. The following are other things that you can do within a sources file:

Set CFLAGS and AFLAGS

CFLAGS and AFLAGS cannot be set in a sources file. Instead, you will need to set CDEFINES and ADEFINES to set compiler and assembler command line flags.

Set CDEFINES, LDEFINES and ADEFINES

These variables are used to change the command line parameters to the compiler (CDEFINES), assembler (ADEFINES) and linker (LDEFINES).

As with all variables in a sources file the way to set the variable is <VAR NAME>=<DATA>. So, using CDEFINES for an example:

CDEFINES=-DMY_MACRO –DOTHER_MACRO=5

Which causes the compiler command line to define MY_MACRO and to define OTHER_MACRO=5. The –D is the compiler command line flag to define a macro. But wait, setting CDEFINES this way will cause any previous settings to be lost. This is exactly why we cannot use CFLAGS and AFLAGS, it is set this way in makefile.def. So a better way to set a variable is:

CDEFINES=$(CDEFINES) -DMY_MACRO –DOTHER_MACRO=5

By doing so, we are setting CDEFINES equal to the current value in CDEFINES plus defining MY_MACRO and OTHER_MACRO=5.

Skip Building

You can skip building a directory in the build tree by checking the component environment variable and setting SKIPBUILD. SKIPBUILD tells build to skip building the directory.

!if "$(BSP_NOTHISDRIVER)" == "1"

SKIPBUILD=1

!endif

This checks to see if the environment variable BSP_NOTHISDRIVER is set to “1”. If it is then sets SKIPBUILD=1. For those of us that don’t like variable with “NO” in them, you can use:

!if "$( BSP_THISDRIVER)" == ""

SKIPBUILD=1

!endif

This checks to see if BSP_THISDRIVER is not set. If it is not then sets SKIPBUILD=1.

Build Something Before or After Building the Directory

WINCETARGETFILE0 can be used to tell the build system to build a target before building the current directory. WINCETARGFILES tells the build system to build a target after building the current directory. I have given an example of using WINCETARGETFILES in Windows CE Platform Builder: Automatically putting files in the SDK during build so let’s look at WINCETARGETFILE0.

In this example, I have a DLL that is built in a different directory tree and want to extend the DLL by adding some new functions. The original DLL is built in two directories, one that creates a LIB file and the other that links the LIB to create a DLL. In this directory there is source code that adds some functions and a def file that exports the functions. For maintainability, I want to use the def file from the original DLL folder, but extend it to add new definitions. To do this, use WINCETARGETFILE0 set equal to DEFFILE:

WINCETARGETFILE0=$(DEFFILE)

Create or edit makefile.inc in the same folder as the sources file. Add a target to makefile.inc and build instructions. In this case the target is $(DEFFILE) and the instructions will copy the original def file to this directory and append the contents of Custome.def to it:

$(DEFFILE): Custom.def

xcopy ..\Original\BuildDll\Original.def .

type Custom.def >> Original.def

So the new def file will be created before building this directory and the def file will be available when the DLL is linked.

Tell the Solution Explorer about files to Display

The Solutions Explorer window uses sources files to determine which files to display and how to display them.

SOURCES not only tells build.exe which files should be built in the directory, but tells the Solutions Explorer which files to list in the “Source files” folder. The following will cause serial.cpp to display in the Source Files folder:

SOURCES=serial.cpp

FILE_VIEW_ROOT_FOLDER tells the Solutions Explorer window to which files to show in the root folder of the directory. The following will cause sources and makefile to display in the root folder:

FILE_VIEW_ROOT_FOLDER=Sources Makefile

FILE_VIEW_RESOURCE_FOLDER tells the Solutions Explorer window which files to display in the “Resource files” folder.

FILE_VIEW_RESOURCE_FOLDER=serial.rc

FILE_VIEW_INCLUDES_FOLDER tells the Solutions Explorer windows which files to display in the “Include files” folder.

FILE_VIEW_INCLUDES_FOLDER=serial.h

FILE_VIEW_PARAMETER_FOLDER tells the Solutions Explorer window which files to display in the “Paramter files” folder.

FILE_VIEW_PARAMETER_FOLDER=serial.bib serial.reg

Go to Summary of Building Windows CE

Tags: Build.exe, Sources

Platform Builder: Cloning an MDD Lib

Bruce Eitman — Thu, 21 Aug 2008 04:10:04 GMT

I have written about cloning code from the Public tree to a platform in the past, but someone recently asked about cloning an MDD lib build directory. More specifically the question was about cloning ufnmdd.lib in Windows CE 5.0, which is actually created by linking three separate libs together. In this article, I will walk through the process by cloning one of those libs.

Ufnmdd.lib is created by linking ufnmddbase.lib, ceosutil.lib and defbuslib.lib. I suspect that most people don’t really need to clone ceosutils.lib and defbuslib.lib, but instead really need to just clone ufnmddbase.lib for debugging purposes. So I will clone ufnmddbase.lib and show two different ways to then link the new lib with a USB function driver.

Cloning UFNMDDDBase.LIB

Because this is a statically linked library, the easiest way to clone it is to simply copy the folder to the platform and then make some changes to the sources file. For this example, I will clone ufnmddbase.lib into the MainstoneII platform. I point this out because you can refer to the MainstoneII platform in the WINCE500 build tree. The USB function driver in MainstoneII is a single directory that builds some source code and links with ufnmdd.lib among other libs.

The steps to add ufnmddbase.lib to the MainstoneII:

1. Move the current code down a folder from Drivers\USBFN to Drivers\USBFN\DLL (or any name you choose.) This makes way for us to add a new folder under USBFN for ufnmddbase.lib to build in.

2. Create a Dirs file in Drivers\USBFN and add the following to it:
DIRS =DLL

3. Test building the driver just to be sure that this didn’t break it already

4. Copy PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to Drivers\USBFN\MDD

5. Add MDD to the Drivers\USBFN\Dirs before DLL:
DIRS=MDD DLL

6. Add RELEASETYPE=PLATFORM to the Drivers\USBFN\MDD\sources file

7. Test build again and check that ufnmddbase.lib is in MainstoneII\Lib sub folders

Now that ufnmddbase.lib has been cloned to the platform, there are two choices for using it within the USB function driver; link directly with the three libs in ufnmdd.lib or create a new folder to link the libs and create a new ufnmdd.lib.

Link Directly with UFNMDDBase.lib

For this option, edit Drivers\USBFN\DLL\sources to change the from linking with ufnmdd.lib to linking with the three separate libraries. Change the SOURCELIBS from:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

To:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceosutil.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\defbuslib.lib \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmddbase.lib

Then rebuild the driver.

Create a New UFNMDD.LIB

For this option, create a new folder to link the three libraries to create a new ufnmdd.lib. The steps are:

1. Create a new folder: Drivers\USBFN\UFNMDD

2. Create a sources file in the new folder and include:

TARGETNAME=UFNMDD

TARGETTYPE=LIBRARY

RELEASETYPE=PLATFORM

SOURCELIBS= \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmddbase.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceosutil.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\defbuslib.lib

SOURCES=

3. Change the SOURCELIBS from:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

To:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

4. Add UFNMDD to Drivers\USBFN\Dirs after MDD and before DLL:
DIRS=MDD UFNMDD DLL

This should give the bases for cloning an MDD lib file for a driver. If you wanted to also clone the other libraries, the technique is the same.

Tags: Build.exe

Platform Builder: Sources Files

Bruce Eitman — Tue, 05 Aug 2008 00:48:02 GMT

Earlier I posted about dirs files and stated that dirs files are the direction signs for build.exe. Sources files are the destinations. When build.exe finds a sources file, it stops and runs nmake to build the source code in the directory. Sources files set environment variables that are then used by nmake when interpreting the makefile. Of course if you have looked at the makefiles, you see that they typically only include the makefile.def in Public\Common\Oak\Misc.

Setting variables in a sources file is simple, it is just variable equals value; example TARGETNAME=DrivverShell. You can also dereference variables using the same syntax as in the bib files and reg files, wrap the variable in $(); example $( _COMMONSDKROOT).

Sources files use the same syntax as makefiles, so a # starts a comment which extends to the end of the line.

Let’s examine the simple sources file in my Driver Shell post:

#This is a sources comment

TARGETNAME=DriverShell

RELEASETYPE=PLATFORM

TARGETTYPE=DYNLINK

TARGETLIBS= \

$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib

DEFFILE=DriverShell.def

DLLENTRY=DllEntry

SOURCES=DriverShell.c

Hint: To fully understand what the variables in a sources file do, refer to Makefile.def in Public\Common\Oak\Misc

This sources file tells nmake to build in Platform\<BSP>\Target\<CPU Independent Path>\DriverShell.dll, link with coredll.lib, use DriverShell.def to define the exported symbols, that the entry point of the dll is DllEntry and that the source code to compile is DriverShell.c.

That was a lot, so let’s take it one step at a time:

TARTGETNAME defines the base name of the output file, this is defined by the developer of the sources file
RELEASETYPE defines where to put the output file, the choices are: DEFAULT, SDK, OAK, DDK, MANAGED, PLATFORM, LOCAL, CETK, CUSTOM. I could easily tell you where the output file ends up in each case, but it would be better for you to go look yourself. The output file in each case is defined in Public\Common\Oak\Misc\sources.Releasetype_%RELEASETYPE% or in makefile.def itself for versions prior to CE 5.0.
TARGETTYPE defines the type of output file that is being build. The options are:
DYNLINK – creates a dynamically linked library, MUI or control panel applet. If MUI is set to 1, the file extension is changed from dll to mui. If CPL is set to 1, the file extension is changed from dll to cpl.
PROGRAM – creates an native exe
LIBRARY – creates a static linked library
MANAGED_EXE – creates a managed exe from
MANAGED_WINEXE – creates a managed exe of target winexe, quite frankly, I don’t know what this means.
MANAGED_MODULE – and again, I don’t know what this means
MANAGED_DLL – creates a managed dll
EXPLIB – creates an exp file
NOTARGET - cause nmake to skip over linking a target
TARGETLIBS lists the .lib files to link with.
SOURCELIBS (not shown) lists .lib files to link with.
DEFFILE sets the name of the DEF file to link with. If this is not defined, $(TARGENAME).def will be used
DLLENTRY sets the entry point function name
SOURCE sets the source code files to build, which also sets that the obj files are linked

NOTES on TARGETLIBS and SOURCELIBS:

If TARGETTYPE is LIBRARY TARGETLIBS is ignored
If TARGETTYPE is PROGRAM TARGETLIBS is linked before SOURCELIBS
If TARGETTYPE is DYNLINK, SOURCLIBS is linked before TARGETLIBS

Those are the basic variables set in a sources file. There are many more available, some documented and some not. The best documentation is the makefile.def file, but to read and understand it well you will need to understand makefiles. Makefile.def is a very sophisticated makefile, so be prepared that you may not fully understand it on the first pass. You may need to refer to makefile documentation, over and over until all of the details of makefile.def become clear.

Build.exe does not support conditional expressions in sources files. You may find examples of conditional expressions in sources files, but officially they are not supported, which means that if you use them they could break in the future. A known problem with conditional expressions is that since build.exe doesn’t use them, and build.exe processes dependencies, conditional expressions cause problems for the dependency checking.

For more on sources files take a look at: Platform Builder: Sources Files 2

Go to Summary of Building Windows CE

Tags: Build.exe, Sources

Platform Builder: IXP46x, 128 MB RAM, CEBaseCESysgen.bat - System Fails to Boot

Bruce Eitman — Wed, 23 Jul 2008 01:02:07 GMT

It has been another one of those days. Several months ago we discovered that one of our systems wouldn’t boot if we did a clean build, but if we built the kernel separately and then ran makeimg the system would boot. What a mystery, that just didn’t make any sense.

So, the engineer on the project modified PreMakeimg.bat to rebuild the kernel when we run makeimg. All was good, but this increases build time. If you have followed this blog, you know that I don’t like long build times but we all tolerated this because there were more important issues for us to address.

Then a second platform had the same problem. I made it a priority to figure out what was wrong this time though because now we were losing time in trouble shooting and in building.

Since the first build is a full build of the system, there is a build.log file in %_WINCEROOT% that I could look at for clues. And the second build was just in the kernel folder, so there was a build.log there as well. I diffed the two files. At first didn’t seem too interesting. That is until I scrolled to the right and could see the command line calls to compile and assemble. At that point it became clear that during the full build of the system that the RAM size was being defined twice, once setting the RAM size to 64MB and the other to 128MB. Our boards have 128MB of RAM so clearly the setting of 64MB was wrong, and of course having both sizes set was a problem.

Now to figure out why this was happening only when we did the full build. I will leave out the details of my search other than that I ruled out sources.cmn, sources, platform.bat and the project’s PBXML file as the cause. Then I noticed that in the root of the platform there was a CEBaseCESysgen.bat file. I had previously ignored it, but now it was beginning to make me curious.

When I opened CEBaseCESysgen.bat, what I found was that it set the RAM size to 64 MB if it is not set to 16, 64 or 256MB, but these platforms are 128MB. Apparently, someone had added support for 128MB, but not noticed this file.

So, what is happening with this CEBaseCESysgen.bat? During the sysgen of the project the platform is built with CEBuild.bat, which runs CESysgen.bat during the build of the platform. CESysgen.bat in turn runs CEBaseCESysgen.bat during the different phases of the build process. But, when we build the kernel separately we just run build.exe which doesn’t run CEBaseCESysgen.bat.

Summary of When Things Go Wrong

Tags: Build.exe, CEBuild.bat

Platform Builder: Dirs Files

Bruce Eitman — Thu, 17 Jul 2008 01:31:56 GMT

Dirs files are the direction signs for building your platform. They show the way for build.exe to find your code to build it. Dirs files are probably the best named files in the build system because what they do is tell build.exe which sub directories to descend into to build. If you have looked around at the files in your platform, then you probably are familiar with the basic form of a dirs file, here is an example:

DIRS=\

Serial \

USB \

Wave

This dirs file tells build to descend into three folders; Serial, USB and Wave. Notice that like macro definition (#define) the dirs file uses line continuation using ‘\’ followed by a newline. So build.exe sees this as “DIRS=Serial USB Wave” and you could just as easily write it in the dirs file that way. I prefer separate lines because it makes it easier to edit the file later.

DIRS can also be set to build all sub directories using ‘*’; example

DIRS=*

I could stop here, but there is another powerful feature of dirs files, the OPTIONAL_DIRS setting. OPTIONAL_DIRS lets you have directories that are built sometimes and other times they are not built. The OPTIONAL_DIRS are list in the dirs files similar to the DIRS setting:

OPTIONAL_DIRS=\

PXA \

SMI

This tells build.exe that it may need to build the directories PXA and/or SMI. Build.exe will then build the folders if it has one of them listed in the environment variable BUILD_OPTIONS. So if we want to build SMI, we can add the following to <platform>.bat:

Set BUILD_OPTIONS=%BUILD_OPTIONS SMI

One key rule for Dirs files is that they cannot coexist in a directory that contains a sources files.

Go to Summary of Building Windows CE

Tags: Build.exe, DIRS File

Platform Builder: Using STR Files

Bruce Eitman — Wed, 09 Jul 2008 00:22:45 GMT

One way to customize your project configuration files is to use string replacement with STR files. Technically, the STR files are for language localization, but that doesn’t exclude using them for customization. In fact, when you create a new project using Platform Builder for Windows CE 6.0, your project will contain a cebase.str for you to set your device name in.

STR files are plain text files stored in your FILES\INTLTRNS\<Local> folder. If you aren’t sure which folder you are using, open a build window and check the setting for LOCALE:

_FLATRELEASEDIR>set LOCAL

LOCALE=0409

STR files contain #define statements similar to C/C++ macro definitions, but different. The syntax is:

#define <String to replace> “<String to insert>”

String to replace is a string that will be replaced in the configuration files.

String to insert is a string to insert into the configuration files. This must be in quotes. NOTE: The string to replace will be replaced with the quotes and everything on the line up to the carriage return.

The STR files are read in by makeimg using FindFirstFile() and FindNextFile() so the name of your STR file is important. If you want to replace defines in other files, then you need to name your file so it read in after the other file(s). For example, platform.str will be read in after common.str, but before wceshellfe.str.

To create an example, let’s create a file named ZProject.str. I want to override some of the strings in common.str and create a string for my customer’s company name to use in HKEY_LOCAL_MACHINE\Software. Here is my file:

// Paths for SHGetSpecialFolderPath

#define LOC_PATH_WINDOWS "\\Windows"

#define LOC_PATH_DESKTOP "\\Windows\\Desktop"

#define LOC_PATH_STARTUP "\\Windows\\StartUp"

#define LOC_PATH_RECENT "\\Windows\\Recent Documents"

#define LOC_PATH_PROGRAMS "\\Windows\\Program Files"

#define LOC_PATH_FAVORITES "\\Windows\\Favorites Files"

#define LOC_PATH_FONTS "\\Windows\\Fonts"

#define LOC_PATH_MYDOCUMENTS "\\Documents"

#define LOC_PATH_PROGRAMFILES "\\Program Files"

#define LOC_PATH_APPDATA "\\Application Data"

#define LOC_CUSTOMER_NAME "Company A"

Note that I copied the LOC_PATH defines from common.str and modified some of them, then added LOC_CUSTOMER_NAME.

In Common.reg and wceappsfe.dat files, the LOC_PATH variables are used:

Common.reg:

; The path lookups for SHGetSpecialFolderPath

; @CESYSGEN IF COREDLL_FILEINFO

[HKEY_LOCAL_MACHINE\SYSTEM\Explorer\Shell Folders]

"Application Data"=LOC_PATH_APPDATA

"Desktop"=LOC_PATH_DESKTOP

"Favorites"=LOC_PATH_FAVORITES

"Fonts"=LOC_PATH_FONTS

"My Documents"=LOC_PATH_MYDOCUMENTS

"Program Files"=LOC_PATH_PROGRAMFILES

"Programs"=LOC_PATH_PROGRAMS

"Recent"=LOC_PATH_RECENT

"StartUp"=LOC_PATH_STARTUP

"Windows"=LOC_PATH_WINDOWS

; @CESYSGEN ENDIF

Which after processing can be found in reginit.ini:

; The path lookups for SHGetSpecialFolderPath

; @CESYSGEN IF COREDLL_FILEINFO

[HKEY_LOCAL_MACHINE\SYSTEM\Explorer\Shell Folders]

"Application Data"="\\Application Data"

"Desktop"="\\Windows\\Desktop"

"Favorites"="\\Windows\\Favorites Files"

"Fonts"="\\Windows\\Fonts"

"My Documents"="\\Documents"

"Program Files"="\\Program Files"

"Programs"="\\Windows\\Program Files"

"Recent"="\\Windows\\Recent Documents"

"StartUp"="\\Windows\\StartUp"

"Windows"="\\Windows"

; @CESYSGEN ENDIF

Note that the strings were replace by the strings in ZProject.str instead of the strings in common.str. Looking at the makeimg output we can see why:

makeimg: Moving files from usasnap to release...

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\cebase.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\common.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\datasync.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\directx.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\ie.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\odo.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\shell.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\viewers.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\wceappsfe.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\wceshellfe.str

makeimg: Read string substitutions from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intltrns\0409\ZProject.str

makeimg: Copy files from C:\WINCE500\PBWorkspaces\AUTOMARKIA\RelDir\AUTOMARK_ARMV4I_Release\intlfile\0409\ to release directory.

You can use a different file name and see where it ends up in the makeimg output.

In my Project.reg, I added:

[HKEY_LOCAL_MACHINE\Software\LOC_CUSTOMER_NAME]

"SomeData"=dword:1

Which ends up as:

[HKEY_LOCAL_MACHINE\Software\"Company A"]

"SomeData"=dword:1

The same works for wceappsfe.dat:

root:-Directory("LOC_PROGRAMFILES_DIR")

root:-Directory("LOC_MYDOCUMENTS_DIR")

Directory("\Windows"):-Directory("LOC_DESKTOP_DIR")

Directory("\Windows"):-Directory("LOC_PROGRAMS_DIR")

Directory("\Windows"):-Directory("LOC_RECENT_DIR")

Which ends up in InitObj.dat as:

root:-Directory("Program Files")

root:-Directory("My Documents")

Directory("\Windows"):-Directory("Desktop")

Directory("\Windows"):-Directory("Programs")

Directory("\Windows"):-Directory("Recent")

So you can see that STR files can be used by you to make changes to both your configuration files as well as the Public configuration files.

Go to Summary of Building Windows CE

Tags: Makeimg, BIB File, REG File, STR File

Platform Builder: Your Changes aren’t in the OS Image

Bruce Eitman — Wed, 02 Jul 2008 18:33:26 GMT

Another engineer just called me for help to figure out why her changes to a dll were not reflected in the nk.bin. I have always found this to a user error problem and started to list the causes that I could think of, but in the end she found a new one.

Causes that we came up with are listed below. You may know of others, if you do please share those with us in a comment.

· You didn’t build your code before running makeimg

· The build failed, but you didn’t notice and ran makeimg anyway

· You didn’t copy the file(s) to the _FLATRELEASEDIR prior to running makeimg

· You didn’t run makeimg

· Makeimg failed

· You didn’t download the new image to the device (and there are lots of variations of this depending on how you download images to you device)

· You have an old copy of the dll in the same folder as the exe that calls LoadLibrary(), this is the new

Summary of When Things Go Wrong

Platform Builder: Clone Public Code

Bruce Eitman — Wed, 02 Jul 2008 18:32:13 GMT

I recently wrote an article about modifying the behavior of KernelIoControl when called by User Mode code. In that article, I stated that you need to clone the Public oemioctl code to your platform. Sounds so simple doesn’t it, and really it isn’t that difficult if you know what you are doing, but for the rest of you I thought that I would walk through the process of cloning code.

Many of us use the term “clone code” but what does it really mean? Cloning code means to copy the code to another build tree and modify the build environment to build the code under the new tree. In the old days of Windows CE development, that meant reverse engineering how Microsoft builds the code to apply your knowledge of the build system to it. Today we have sysgen_capture.bat to do most of the hard work for us.

Here is how I would clone oemioctl:

1. Create a new folder in my platform to build oemoctl.dll, I will call mine OALIoctlDir. This folder will be a holding place for two new folders; one will build the lib that is built in Public\Common\OAK\oalioctl, and the other will link the lib to create the dll. You certainly can create the dll with one folder, but that is more involved that the discussion here.

2. Copy the %_WINCEROOT%\Public\Common\OAK\OEMICTL folder and paste it as a new subfolder of OALIoctlDir. This is the folder that creates OALIoctl.lib.

3. Create an new folder in OALIoctlDir named BuildDll; this is the folder that will do the linking to create OALIoctl.dll.

4. Create a dirs file OALIoctlDir that contains

DIRS=oalicotl BuildDll
This tells build to go into OALIoctl first to build the lib, then go to BuildDll to link the dll.

5. Add OEMIocltDir to its parent folder’s dirs file, which tells build to build our clone of OALIoctl.dll.

6. Modify OALIoctlDir\OALIoctl\sources to add RELEASETYPE=PLATFORM, this tells build to put the lib in the platform build tree

7. Open a build window and change directories to OALIocltDir\BuildDll

8. Run “sysgen_capture OALIoctl” which will create a file named sources.OALIoctl. This new file contains the information that Microsoft uses to link OALIoctl.lib to create OALIoctl.dll, we need that information to build.

9. Rename souces.OALIoctl to sources, so that build.exe can use it.

10. Modify OALIoctlDir\BuildDll\sources to

a. change $(_PUBLICROOT)\common\oak\lib\$(_CPUINDPATH)\OALIoctl.lib to $(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\OALIoctl.lib

b. Change the DEFFILE to DEFFILE=OALIoctl.def

11. Copy OALIoctl.def from OALIoctlDir\oalioclt to OALIoctlDir\BuildDll, this is necessary so that when BuildDll is built it can find the def file. There are alternative solutions for this, but this one is easy.

12. Copy a makefile from one another folder to BuildDll, this is necessary because build.exe needs the makefile when it calls nmake.

13. Change directories to OALIocltDir and run build

14. Now you have an OALIoctl.dll in your Platform’s Target folder. When you run buildrel, this OALIoctl.dll will overwrite the one created in the Public folder.

Now you have a clone of OALIoctl that you can modify to suit the needs of your platform.

Tags: Sysgen_Capture, Clone

Platform Builder: Using Your Developr Batch File

Bruce Eitman — Thu, 26 Jun 2008 02:13:53 GMT

Spell checker is going to hate this post, because the ‘e’ is missing in the folder name Developr. One of the things that you can do to customize the build environment in Platform Builder is to add a batch file to the Developr folder.

To use the Developr batch file, you must first create a sub folder named with your system username. The fact is that I am thinking about this right now because my username just changed from beitman to bruce.eitman, so my Developr batch file isn’t working anymore. So I changed my %_WINCEROOT%\Developr\beitman folder name to %_WINCEROOT%\Developr\bruce.eitman.

Now that you have a folder, create a new file named setenv.bat. Now you can set environment variables that you want in the setenv.bat. Be careful though, you should not set any variables that will affect the outcome of the build of your OS image. But, you can set variables like WINCECOD.

Here is my setenv.bat:

set WINCEREL=1

set WINCECOD=1

set BUILDREL_USE_COPY=1

set PATH=%PATH%;%_WINCEROOT%\Developr\bruce.eitman\Bin

Note that this even adds a path to the PATH variable that includes some useful batch files that I use during my work to simplify the command line.

The Developr batch file is run by wince.bat when it is setting all the other environment variables. It is called with all of the parameters passed to wince.bat, so you can get more complex and use those variables, but I haven’t found a need to do that.

Go to Summary of Building Windows CE