Welcome to MSDN Blogs Sign in | Join | Help
TDLite (CMIExplorer)

Note:
This document is a work in progress, we're posting it in it's present (and workable) state to help unblock customers ASAP, your feedback via the blog's contact link at the top of the page would be greatly appreciated.

TDLite (aka CMIExplorer) comes as a tool in the Value Add folder on your XP Embedded tool kit. For the purpose of this document it will be assumed that CMIExplorer is already installed on your XP Embedded build machine in the  %ProgramFiles%\windows Embedded\utilities folder. You can use this tool to perform a lot of the core actions you can with Target Designer and DBMgr: Create a config, add/remove components to the config, import/delete components from the DB, resolve dependencies and build the configuration.

TDLite is a command line tool used to interact with CMI. It provides a simple shell that executes commands entered either on the command-line, interactively, or read from a response file.

This document covers a couple of the commands that can be used with cmiexp.wsf to perform operations such as build a runtime, check dependencies, check the dependency tree of a component etc. More to come later.

Usage:
The typical usage pattern for CMIExplorer looks like
CMIExp [macros] ["cmd" | @respfile ] ... [switches]

More information regarding each of these arguments can be found in the CMIExplorer help. To check this, you can run the command cmiexp.wsf /? at your command prompt.

If no command-line commands are specified, CMI Explorer will enter interactive mode, and read commands from the console. Each command is prompted for with a "*"  prompt and executed immediately. For ex:, at the command prompt type cmiexp.wsf , you will see:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved

CMI Explorer version 3.14.620 (CMI revision 578)
Copyright (C) 1999-2001 Microsoft Corp. All Rights Reserved.
Platform GUID       : {B784E719-C196-4DDB-B358-D9254426C38D}
Platform            : (not in database)
*

You can now type your CMI commands at the “*” prompt.

CMI Explorer Response file
CMIExplorer  can accept a response file as an input. This response file can contain the commands you want CMIExplorer to execute. It typically ends with a “res” extension. Each of these commands should appear on a single line in the response file. The CMIExplorer command to use with response file is...

cmiexp.wsf @myResponseFile.res

...where myResponseFile.res is the response file containing the commands that need to be executed.

Example of how a myResponseFile.res looks like is shown below (in the scripts below, 'myDatabasename' refers to your own DB Server name):

dbopen myDatabaseName
new c1 = 'comp:Fujitsu DL 5600'
deptree /2 c1
dbclose
quit

Note that you can also enter each of the commands interactively at the CMIExplorer   * prompt to achieve the same results.

More information on each of these commands can be found in the later sections of the document.

The typical sequence of commands to be used with CMIExplorer is:

1) Open a database connection
2) Execute CMI commands
3) Activate the configuration, if you want to build, check dependency, or add a new component to an existing slx. This is a very important step which commonly gets missed.
4) Execute CMI commands if any
5) Close the Database connection
6) Quit

Note: Outlined below are a couple of sample CMIExplorer response files.

Finding the dependency tree of a component

dbopen myDatabaseName
new c1 = 'comp:Fujitsu DL 5600'
deptree /2 c1

Description of the above .res file:
Dbopen opens a database connection to myDatabaseName. The next command is basically creating a new CMI object of type comp which holds the name of the component I want to check the dependency . deptree is the command used to check the component dependency tree.

Notes:
You can control the level of dependency information you want to be dumped by changing the number from 2 to higher number. The numbers supported are 0 -7. More information on this command can be found by typing deptree /?


Building an image form an SLX file

dbopen myDatabaseName
new cfg Config
cfg=CMI.CreateFromFile("pathToMySLXFile")
cfg.activate
cfg.build 0, "pathToBuildImage"
dbclose
quit

Description:
An SLX file in CMI terms is nothing but a configuration. So to build an image, you first create a CMI Config object and point it to your SLX file. pathToMySLXFile looks like c:\winlon.slx. This path can also be on a  network share. Cfg.Activate activates the configuration. Cfg.build builds the image in the folder you specified within the double quotes “ “. For ex:, pathToBuildImage can look like c:\buildfolder. Make sure this buildfolder is empty.

Notes:
1) Ensure that the build folder you specify is empty. CMIExplorer won’t clean up the folder if it is non-empty at this point. It will bail out with the following error
Error 1003 (0x3EB) in "Config::cmiOnBuild": Destination folder for build not empty
2) Do not forget to activate the configuration with cfg.activate before you try to build the image


Add a new component, Check dependency and Build image

dbopen myDatabaseName
NEW cfg Config
cfg=CMI.CreateFromFile("pathToMySLXFile")
cfg.activate
new newinst Instance
newinst = 'inst:.Net Framework 1.1’
cfg.instances.add(newinst)
cfg.checkdependencies(2)
cfg.resolvedependencies(2)
cfg.build 0, "pathToMyBuildFolder
"


Dump Config info

dbopen myDatabaseName
NEW cfg Config
cfg=CMI.CreateFromFile("pathToMySLXFile")
dump cfg

Posted: Monday, July 18, 2005 1:17 PM by Embedded

Comments

Windows XP Embedded Team said:

Less than a month ago we met with some partners in Redmond as part of the Windows Embedded Design Review...
# July 18, 2005 9:12 PM

Ruediger Jungbeck said:

Wow, now (after several years) we have at least a bit of documentation (1 page of paper) of how we could automate XPe image building. Why had it taken so long? (CMIEXP on the very first XPe CD I had seen).

One mystery remains: How could we mount and dismount a SDI file from a script?

ruediger.jungbeck@rsj.de
# July 27, 2005 4:38 PM

Ruediger Jungbeck said:

One of the problems we are having with scriping the build process is, that we need a way to mount and dismount the target device (a SDI file) from that script, because we are creating multiple images. Another problem that we have in this context of course is, that we need to bring all generated images to the target devices (yes we have more than one type), reboot several times and than bring back the resealed images onto our development system. This makes automation very complex.

About the documentation:
I wouldn't call it "CMI Explorer Handbook" because it's just a few starting point for automating builds. Maybe like an technical article.
It is VERY HELPFULL in automating a build.

But it's not a documentation by itself. It's only 766 words (according to MS Word) to describe the complete infrastructure below the GUI, whereas the XPe documenation on MSDN uses 318 words alone to describe just the intuitive user interface of SDI Loader (without describing a way to automate it).
A documentation in my view describes ALL commands, ALL arguments and ALL return codes, as well as the neccessary context to understand the bigger picture.
There is no description of CMI at all (what objects are there, what do they do, how do they relate to each other). What is the concept (not from GUI point of view as in the XPe docs, but from the CMI view) of the complete product.

So yes, it helps us a lot that you finally released that information (I would normally expect every developer tool to come the neccesary information to automate it's usage), but it does not help us with understanding the inner workings.

One example:
If you expect outside vendors to distribute SLDs and repositories for there components (beeing HW or SW), there must be an automatable way to generate these in the build process of that component. Maybe one can do this with CMIEXP.WSF, but certainly not with the information currently provided in the "CMI Explorer Handbook".

Regards

Ruediger Jungbeck

# July 28, 2005 4:08 AM

Windows XP Embedded Team said:

Less than a month ago we met with some partners in Redmond as part of the Windows Embedded Design Review...
# July 30, 2005 5:19 PM

Windows XP Embedded Team said:

It's Thursday morning, 9am, at MEDC 2006 here in Las Vegas. I am at the Cabana checking e-mail and on-hand...
# May 11, 2006 3:35 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker