Comparing workspaces is simple, command prompt, pipe sysgens to a text file, use WinDiff or similar to compare the sysgen list - it would be nice to have a graphical tool to do this, but text/windiff works well enough for this to be a workable solution.

So that's the simple one out of the way, what about determining the difference between a base platform configuration and an existing workspace - there's some work to do here.

Windows CE ships with a number of design templates, these can be considered to be starting points for your Windows CE operating system design, once you've created your base platform image you are free to customize the platform by removing items from your workspace, adding items from the catalog, or adding new projects (applictions, DLL's, or drivers) to your workspace.

The design templates for Windows CE 5.0 can be found here C:\WINCE500\PUBLIC\COMMON\OAK\CATALOG\NEWPLATFORMWIZARDS (assuming a default install of Windows CE 5.0).

The templates are simply XML files - you can break the template into two logical parts, the first being fixed operating system components which are known as DefaultSettings, and the second being optional components.

Here's an extract from the Internet Appliance platform wizard XML file showing the fixed components - Note that I've removed a number of GUIDs from the example.

    <Component IncludeComponent="0246E582-3544-446B-8F7B-8FAA0C399410" />
    <Component IncludeComponent="271CFC2D-D13D-4931-8349-C4B549EAD1E3" />
    <Component IncludeComponent="3DB27231-B662-46B2-9A20-BCDB9672F10B" />
    <Component IncludeComponent="C79B8B9A-2FA9-4A14-89FD-843DD3361DC3" />
    <Component IncludeComponent="8AE70F33-3B0C-4F59-AFB8-637CE51613C5" />
    <Component IncludeComponent="9429FF7D-40E0-4169-8523-FF7DB19CDE0C" />
    <Component IncludeComponent="D341D78A-48D4-4957-82EC-C4EB296BC6F8" />

The DefaultSettings block within the XML file defines the core, or fixed operating system components that are expected to be in the operating system image - but how do you determine what 'actual component' the GUID represents ?

One of the XML files in the NEWPLATFORMWIZARDS folder is Custom_Device.xml - this wizard file wraps all the components found in the standard catalog.

You notice that I highlighted one of the GUIDs in the DefaultSettings section of the Internet Appliance platform wizard file, if we open the Custom_Device.xml file in Notepad or other similar editor and search on the GUID we find the following item.

        <Name>Standard Shell</Name>
        <Description>Standard Shell</Description>
        <Component IncludeComponent="
8AE70F33-3B0C-4F59-AFB8-637CE51613C5" />

The component from the Platform Wizard file is obviously the Windows CE Standard Shell (start button, task bar, icons on the desktop type shell).

The second part of the Platform XML file is the optional section - Each wizard starts with a base set of components (shell for example) and then prompts the user to select optional components, for example the .NET Compact Framework (more on this later).

If we search the Custom_Device.xml file for ".NET Compact Framework 1.0" we find the following.

        <Name>.NET Compact Framework 1.0</Name>
        <Description>.NET Compact Framework 1.0</Description>
        <Component IncludeComponent="272A74B5-989A-4361-9FE2-6C35063A373B" />

Now lets examine the Internet Appliance XML file and see if we can locate the NETCF 1.0 GUID.

After the DefaultSettings section of the XML File there are typically one or more Selection Pages, these translate to wizard dialogs you see on screen when running the Platform Builder new platform wizard - in the section below we can see the Selection Page for Applications and Media, this includes the .NET Compact Framework 1.0 component (highlighted).

    <Title>Applications &amp; Media</Title>
    <Comment>Select items for applications and media to include in your OS design.</Comment>
    <Description>Select items for applications and media to include in your OS design.</Description>
      <Option OptionDefault="YES">
        <Name>.NET Compact Framework</Name>
        <Description>Support for applications and services designed for the .NET Compact Framework.</Description>
        <Component IncludeComponent="C57F5E2B-DCD5-4D00-8C8B-7EAC20ADA502" />
        <Component IncludeComponent="
272A74B5-989A-4361-9FE2-6C35063A373B" />
        <Name>Standard SDK for Windows CE</Name>
        <Description>A minimum standard set of APIs. A software development kit (SDK) created from an OS design that contains this set of APIs qualifies as a Windows CE Standard SDK.</Description>
        <Component IncludeComponent="C0159835-AD47-41C9-A473-7AA85EF01D8D" />

So far so good, to determine the features included in a base Windows CE operating system image, we can examine one of the Windows CE template files and determine the feature names from the Custom_Device.xml file.

So how does that map to a Platform Builder workspace? - Workspaces are typically stored in the C:\WINCE500\PBWorkspaces folder - lets examine my "MyPlatform" workspace file this is here on my development PC -  C:\WINCE500\PBWorkspaces\MyPlatform\MyPlatform.pbxml - this is another XML file.

The list of features used in a platform workspace are exposed through an XML section in the platform workspace file called FeatureCollection - here's a cut down version of MyPlatform FeatureCollection.

  <FeatureCollection Name="AnchoredFeatures" EnforceUniqueItems="True">
    <Feature Name="Item" FeatureVariable="SYSGEN_HELP" Anchored="True" />
    <Feature Name="Item" FeatureVariable="SYSGEN_IABASE" Anchored="True" />
    <Feature Name="Item" FeatureVariable="
    <Feature Name="Item" FeatureVariable="SYSGEN_DOTNETV2" Anchored="True" />

Now the issue becomes how to map the SYSGENS from the PBPXML file back to the IncludeComponent GUID in the default platform XML file, this is where things become interesting.

The GUID/IncludeComponent map is contained in an MDB file (Access Database file) C:\WINCE500\PUBLIC\COMMON\OAK\CATALOG\DATABASE\pbdb.mdb – this is a password secured database, so we can't go any further with this route to map the SYSGENs to GUIDs.

It would be useful to have an XML file that links GUIDS to SYSGENS, this is something I will take a look at over the next few days (I need to brush up on database programming though!). The next step would be to create a tool that uses the GUID/SYSGEN information from the PBPXML (workspace) and XML Design Templates to determine what's been added/removed from your workspace file.

Oh, nearly forgot... I was going to talk about the .NET Compact Framework, why? Because the .NET Compact Framework v2.0 has recently been released, this updates the catalog through a new .CEC (Windows CE Catalog) file - so the GUID for this component (or any other 3rd party component) won't be found in the Custom_Device.xml file - so we need a way to also deal with non-standard CEC files that update the catalog and therefore also update available SYSGENs for Windows CE.

- Mike