understanding the launch and dependancy indices
from
austech[dot]info/gps/31080-gps-launching-program-6.html
source is
blogs[dot]msdn[dot]com/b/mikehall/archive/2007/01/04/ce-6-0-booting-processes-with-command-line-options.aspx
==================================================================================
CE based devices have a couple of options for booting applications at startup.
1. The Registry.
The first option is to use the registry to launch processes during the boot process of the device, the registry key for launching applications is HKEY_LOCAL_MACHINE\Init - the registry approach has a couple of drawbacks - the first issue is that there is a dependency chain within the boot process, processes are started and need to signal back to the o/s that the process has launched (using the SignalStarted API) so that other dependent processes can also start - here's how this looks in a snippet from a device registry.
[HKEY_LOCAL_MACHINE\init]
"Launch20"="device.dll"
"Depend20"=hex:0a,00
"Launch30"="gwes.dll"
"Depend30"=hex:14,00
"Launch50"="explorer.exe"
"Depend50"=hex:14,00, 1e,00
Take a look at the "Launch50" line, this launches "explorer.exe", the standard Windows CE shell that looks somewhat similar to the Windows desktop shell - The Explorer process has dependencies on hex:14 (20 decimal) and hex:1e (30 decimal), this maps directly to the Launch20 and Launch30 processes - explorer.exe will not be started until the processes associated with Launch20 and Launch30 are started and have signaled the o/s that that have started, an application started through the registry must call SignalStarted to allow any dependent applications to also launch - an application launched through the registry gets its launch number (50 in the case of the Explorer shell) passed as a command line parameter - this is of course passed as a string, not a number, the SignalStarted API needs to pass a DWORD value as its parameter, so a process would use SignalStarted similar to the following.
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
// Do some work here...
SignalStarted(_wtol(lpCmdLine));
The second drawback is that processes launched through the HKLM\init registry key cannot be passed any additional command line options beyond the launch key value which is then passed to SignalStarted by the launched application.
2. Startup Folder
The second option is to drop your application (or a shortcut to an application) in the operating system Startup folder (this is only implemented in the Windows Explorer shell) - The code that walks the Startup folder looking for processes to start can be found here - C:\WINCE600\PUBLIC\SHELL\OAK\HPC\EXPLORER\MAIN\exp lorer.cpp - take a look at the ProcessStartupFolder() function, it should be fairly easy to lift this code and implement your own startup folder code.
The advantage of using the Startup folder is that the applications don't need to know about the boot sequence of the o/s, don't need to be aware of the launch dependency chain, and could (if a shortcut is used) be passed command line options.
The downside of using the Startup folder is that all processes within the startup folder are launched at the same time - there isn't a dependency chain, or time delta betweeen processes launching - this could be an issue in some circumstances - let me give you an example - you may want to boot a CE device image and then connect to that device image from VS 2005 (so you can deploy/debug some managed or native applications), if you were to launch ConManClient2 and CmAccept from the startup folder you would have three minutes to configure VS 2005 with the correct IP address and then connect VS 2005 to the device - you might want to delay the launch of ConmanClient2 and CmAccept until the device has a valid and active IP address.
3. (did I say there were a couple of options?) SvcStart Services Sample.
John Spaith posted on the launch issue back in December 2004 - John wrote a sample called SVCSTART whose sole purpose in life is to start other applications with a delay period that can be configured through the registry - this sample was initially added to the CE product back at CE 4.1 and is still available today in CE 6.0 - C:\WINCE600\PUBLIC\SERVERS\SDK\SAMPLES\SERVICES\SV CSTART - it could be a little fiddly to get this built/added to your o/s image if you are just getting started with CE 6.0 development.
4. Project Socrates - AutoLaunch
To assist students taking part in the ImagineCup 2007 competition (and also to make it easier for any developer to launch applications on their device with delay, command line options, and also waiting until the device has a valid IP address) Jim Wilson and I have developed a simple application called AutoLaunch - the AutoLaunch application comes in a handy Sub-Project form so can easily be added to an existing CE 6.0 workspace. The functionality is similar to the SvcStart sample written by John Spaith but does have a couple of minor differences - the first is that the AutoLaunch program is launched through the HKLM\Init registry keys (much like any typical startup process) - the registry keys for adding AutoLaunch to the startup sequence are included in the sub-project .reg file, so you don't need to worry about this.
The second difference is that the AutoLaunch process waits until the device has a valid IP address before launching any processes - the reason why this is useful is that we wanted students to use their reference boards without needing a second monitor, keyboard or mouse (in effect the device is booting headless even though the CE desktop or launch application is being displayed) - in this case we want to launch the CE Remote Display application (CERdisp.exe) on the device with the command line "-c" (connect) which then broadcasts the device IP address/name to a listening desktop CE Remote Display application.
The CE Remote Display application can be found in the CE 6.0 catalog by searching for "cerdisp", the SYSGEN for the component is (strangely enough) SYSGEN_CERDISP. The desktop CE Remote Display application can be found here - C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386\cerhost.exe [NOTE: The CE Remote Display application is not the same as RDP/Remote Desktop, although RDP is supported as a client side application on CE 6.0 (SYSGEN_RDP)].
In the sample below we're launching the CE device side Remote Display application (cerdisp) with the command line "-c" to start connected, with a timeout of 0x1388 (5000ms, 5 seconds), and also starting the CE command prompt (cmd.exe) with a delay of 0x1f40 (8000ms, 8 seconds) - it would of course be trivial to also add ConmanClient2 and CmAccept to the launch process list.
[HKEY_LOCAL_MACHINE\Startup]
"Process1"="cerdisp -c"
"Process1Delay"=dword:00001388
"Process2"="cmd"
"Process2Delay"=dword:00001f40
Here's how the desktop CERHost.exe application looks when the device boots and runs the "cerdisp -c" command - notice the name of the device and the device IP address are both displayed in the Remote Host application (the IP address being displayed here is very useful for plugging into the VS 2005 Device Properties dialog!).
And to round off the blog post here's the Remote Display application running on my Vista desktop showing the CE 6.0 desktop - note that I can now use my desktop mouse and keyboard to remotely control the CE 6.0 device!
Using AutoLaunch and the CE Remote Display for hands on labs/training that use reference boards instead of the Device Emulator may be quite useful!
