CE 6.0: Don’t add Platform Manager to your OSDesign

Adding the Platform Manager component to a CE 6.0 operating system design will generate build errors for a platform – the error will read something like:

Error: Could not find file ‘C:\WINCE600\OSDesigns\<Release Dir Path>\cemgrc.exe’ on disk

The image below shows the Platform Manager component in the CE 6.0 catalog (more information on Platform Manager can be found in this MSDN Article

Take a look at the contents of C:\WINCE600\PUBLIC\COMMON\CESYSGEN\makefile – line 1187, “Platman Stuff” – this tries to copy files from $(OTHERS_ROOT)\platman\target\$(_TGTCPU)\ – this resolves (for a default install) to C:\WINCE600\OTHERS\platman\ (etc…) – the Platman folder doesn’t exist in the CE 6.0 install, so the files cannot be copied and therefore the build fails. For the RTM build Platform Manager should have been removed from the catalog, the underlying files were removed from the \WINCE600 folder structure but the catalog item was somehow overlooked.

With the introduction of CE 6.0 the underlying connection betweeen Visual Studio 2005 and your embedded target is CoreCon, to deploy and debug an application you need to start two processes on your target device, these are known as ConManClient2.exe and CmAccept.exe – these can be found in the following folder on your desktop development machine C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<Processor_Type> – with previous releases of CE you would use Visual Studio 2003 or eMbedded Visual C++ 4.0 SP4 to write applications, Visual Studio would require you to run a desktop application (the Smart Device Authentication Utilitiy) which would run two applications on your target device (ConmanClient.exe and SDAuthUtilDevice.exe) – note that Visual Studio doesn’t need Platform Builder attached to the target to run this application – for eMbedded Visual C++ you have two options to deploy an application, the first is to “piggy back” on the existing Platform Builder connection to the device (using CESH/KITL as the connection from eMbedded Visual C++), the second option is to deploy the appliation using TCP/IP and running applications directly on the target like CEMGRC which uses an interesting command line!

With the release of CE 6.0 native and managed application development is merged into one tool, Visual Studio 2005 – now you just need to run the ConManClient2 and CmAccept utilities on the device (how you get them there is another story) and then you can write, deploy, and debug your managed or native applications – which means that Platform Manager isn’t needed any more and therefore shouldn’t be added to your platform (note that ActiveSync doesn’t need Platform Manager to work).

– Mike

Comments (6)

  1. Rox says:

    Hi Mike,

    I don’t know whether this option is removed from RTM version or not, but I do see this option appears in WINCE 6.0 Trial version that I installed on 2006/11/1(Taiwan time).

    PS. CE 5.0 and CE 6.0 co-exist in my PC.


  2. mikehall says:

    The Platform Manager component is in the RTM version catalog as well as the CE 6.0 Beta/Trail version.

    Adding this component to your platform will generate build errors.

    – Mike

  3. Mike,

    Do you have any suggestions on how best to get CoreCon loaded on a headless device.  Using HKLMInit for loading at startup is problematic, since an IP address must be allocated from the DHCP server before ConmanClient2.exe can be executed.  Is there a dependnn hex value associated with the IP stack?

    Jim Y. Wilson

  4. mikehall says:

    I’m not aware of a dependency on the IP stack from the HKLMinit launch keys.

    If you are building a headless device and want to launch ConManClient2 and CmAccept these have a three minute timeout for you to connect from VS 2005, plus VS 2005 needs to know the IP address of the device you are connecting to.

    If you are booting a headless device from Platform Builder you can of course use the Target Control Window (ALT+1) to issue a "s ipconfig /d" command once the image has booted to then get the IP address of the target device, feed this into VS 2005 for application development and then launch conmanclient2 and cmaccept on the target (again using the Target Control Window).

    Do you have the option of using a fixed IP address or do you need DHCP ? – if you need DHCP then perhaps the following might be possible…

    have a launch application that periodically monitors the IP address of the device – if the IP address is valid then the device could send a UDP broadcast with the IP address of the device (and perhaps device name from the registry) and spwan ConManClient2 and Cmaccept – a listner application running on the desktop would then have three minutes to plug the IP address into Tools|Options and deploy an application to the device.

    Sound like a plan ? – the alternative is to run a remote display application on the device (again when the device has a valid IP address) – of course the device will still need to broadcast the IP address of the device to a listening application on the desktop – the desktop side could then display the ‘virtual desktop’ from the headless device, you could then control the device from the desktop.

    So many possibilities !

    – Mike

  5. Klaus Pfaadt says:

    We are also trying to implement application debugging on a headless device (x86). Our problem is the SDK which does not contain e.g. OLE32.DLL. Is there any method in the properties for a smart device project where I can disable the default OLE32 library?

  6. Mike Engel says:

    Hi Mike,

    how can I use the remote tools without the platform manager in a release kernel and not connected to the platform builder?

    Mike Engel