What's the smallest Windows CE 5.0 configuration that you can target from Visual Studio 2005?
Very small! The DeviceEmulator nk.bin can be as small as 1.3mb! With that 1.3mb OS image, you can deploy and debug native applications using Visual Studio for Devices. Here's how...
In Platform Builder
Install the Device Emulator BSP from http://www.microsoft.com/downloads/details.aspx?FamilyID=474b03a6-e87d-455d-bc16-b8cf18ef39b4&displaylang=en. Pay special attention to the non-skin configuration options in the SDK XML file.
Create a new platform using the wizard...
- Step 4 - choose custom device
- Step 5 (Applications and Services Development) - check "C Libraries and Runtimes" (which checks everything underneath it)
- Step 6 (Applications - End User) - leave everything unchecked
- Step 7 (Core OS) - check "Power Management (Minimal)", "Device Manager", and "Debugging Tools \ Toolhelp API"
- Step 8 (Networking Features) - check "Networking Features \ Winsock Support"
- Step 9 (Device Management) - leave everything unchecked
- Step 10 (File Systems and Data Store) - check "File System - Internal (Choose 1) \ RAM and ROM File System" and "Registry Storage (Choose 1) \ Hive-based Registry"
- Step 11 (Fonts) - leave everything unchecked
- Step 12 (International) - check "Locale Services (Choose 1) \ National Language Support (NLS)"
- Step 13 (Internet Client Services) - leave everything unchecked
- Step 14 (Grahics and Multimedia Technologies) - leave everything unchecked
- Step 15 (Security) - leave everything unchecked
- Step 16 (Shell and User Interface) - check "Graphics, Windowing and Events \ Minimal Input Configuration"
- Step 17 (Windows CE Error Reporting) - leave everything unchecked
- Step 18 (Voice over IP Phone Services) - leave everything unchecked
- Finish!
Now, go to the Platform\Settings menu, and for the release configuration, switch to the Build Options tab and uncheck "Enable CE Target Control Support (SYSGEN_SHELL=1)" and "Enable KITL (no IMGKITL=1)".
Then switch to the Environment tab and add "BSP_NOTOUCH" with value "1"
Now build it using the Platform Builder "Build OS \ Sysgen" menu. The retail nk.bin image will be about 1.3mb in size.
Next, create an SDK for it. Go to Platform Builder's "Platform \ SDK \ New SDK..." menu, fill in the details on the first page, then leave the defaults for the rest.
Finally, build the SDK using the Platform Builder "Platform \ SDK \ Build SDK" menu.
Install the SDK
Install the new SDK on your Visual Studio 2005 machine.
Now comes the hacky part of the process you need to hack your datastore a little.
- Navigate to C:\Documents and Settings\All Users\Application Data\Microsoft\corecon\1.0\addons and look for the newest .xsl file whose name is a GUID. Open that file in notepad or your favorite XML editor
- Edit the RemoteCcClientFile, RemoteCcShutdownFile, RemoteCcTransportLoaderFile and RemoteCcCMAcceptFile properties, removing the "%CSIDL_WINDOWS%" text and just deploying to the root directory. There are two instances of each property, one for emulator targets and one for hardware device targets. Edit both instances of each property.
- Edit the RemoteTransportFile property, again, removing the %CSIDL_% constant, so that the dmatrans.dll deploys to the root directory.
ie.
<PROPERTY ID="RemoteCcCMAcceptFile" Protected="true">%CSIDL_WINDOWS%\CoreCon%CcVersion%\CMAccept.exe</PROPERTY>
becomes
<PROPERTY ID="RemoteCcCMAcceptFile" Protected="true">\CoreCon%CcVersion%\CMAccept.exe</PROPERTY>
If something goes wrong, delete the XML file, uninstall and reinstall your SDK, and it will be recreated.
Use the SDK from Visual Studio 2005
Launch Visual Studio, and do a File/New Project, to create a new C++ SmartDevice project. Pick your SDK from the list of targets, and select "Console" as the application type, with no ATL or MFC support.
Once the wizard has finished, there are a few work items left:
- Remove the #include of commdlg.h from the top of the wizard-generated .cpp file
- Remove the #include of atlcecrt.h from the bottom of stdafx.h
- In the project properties, make the following edits in the "All Configurations" configuration:
- Under Configuration Properties \ Linker, click on Additional Dependencies then type in this text: coredll.lib corelibc.lib $(NOINHERIT)
- Under Configuration Properties \ Deployment, edit the "Remote Directory" entry, removing the "%CSIDL_PROGRAM_FILES%" text. Deploy your app into a subdirectory under the root directory.
- Make the following edit to your project properties under both the Debug and Retail configurations:
- Under Configuration Properties \ Debugging, remove the "%CSIDL_PRGORAM_FILES%" text. The remote executable is in a subdirectory under the root directory.
Now, F5 should build your app, launch the emulator, deploy and debug.
Diagnosing Problems
- If the emulator launches but deployment isn't happening, you might have left a %CSIDL_*% constant in a path somewhere.
- Go to VS's Tools/Options dialog and navigate to "Device Tools \ Devices", click on your emulator entry and click Properties. In the emulator properties dialog, click "Emulator Options" then on the Peripherals tab, check the "Create text console for serial port 1" checkbox. This will cause the emulator to open a console window as it launches, that will show you diagnostics output from the Windows CE kernel.
What's with the CSIDLs?
Visual Studio for Devices must resolve %CSIDL_% symbols in pathnames by executing code on the device/emulator, that calls SHGetSpecialFolderPath(). The OS image size grows substantially if we pull that API in, as it only comes in as part of the GUI shell.
We must painstaking remove all %CSIDL_% symbols from the datastore and project properties. Otherwise, VSD's device-side code will go into a long polling loop waiting for the shell APIs to come online, and when the timeout eventually expires, the VSD operation will fail.
