Hey guys! These were truly some days when evil was hovering over me!… or at least, so I thought!

I’ve been trying since last Saturday to deploy a Win CE application I’ve written in C# for a new embedded board I’ve received from Microsoft as a prize, but I kept getting this annoying errors, like “the Compact version used is too old” or “the application is already running” (and of course, it wasn’t running) and so on.

Since I’ve got that first error, I believed that there was a problem with the WinCE image I’ve built. So, just to be 100% sure that the problem was the image (which I admit, didn’t find to have build-logic problems), I’ve tried deploying the image on another older board, with another image of course, also on an x86 architecture, an image that I knew was perfectly capable of running anything I had in mind.

But what about this? I plug in the cross-over cable, boot the image, run Coreman for deploying the app I’ve written and boom: “Deployment and/or registration failed with error: 0x8973190e. Error writing file ‘WindowsSystem_SR_enu.cab’. Error 0x8007274c: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.” I try the Coreman again, run the debug again, and then I get “the process is already running bla-bla-bla”.

So what to do next? Well, first I was thinking of writing an e-mail for support, but whom to write to? And what to write? Writing an e-mail with “nothing works” as subject, and the posted error in the body of the e-mail would have probably been ignored… And then it came to me: what if the network board is broken (to be read as f***** up”)?

A short history lesson: back in December I had to buy a new network board for my laptop because I’ve accidentally broken a pin of the original on-board Intel gigabit network board. And since it isn’t possible to change the on-board network module, I’ve decided to buy the best PCMCIA network board on the market: the D-Link DGE-660TD Gigabit board.

Enough with the history lesson. So here I am, unplugging my D-Link network board. I dock the laptop in the Lenovo docking station, plug the cable into the docking station network socket, change the IP addresses as required, start Coreman all over again, press deploy and taa-daam: deploy succeeded.

Don’t know if any of you ever had similar problems, but googling any of the errors I’ve got during these last 4 days I had absolutely didn’t help at all, so…

Ok, that’s it for today!

Alex

This is one of those days, when you do one thing, you compile, everything works perfectly, but for some reason, the second time you compile, nothing works any more :).

Platform Builder 6 has a very complex sequential build process. In theory, is has four main steps:

  1. the compilation phase
  2. the sysgen phase
  3. the release copy phase
  4. and the make run-time image phase

Each of these steps uses a very large number of small files containing module and file definitions that will be included in the final image, registry keys and values for the run-time image created during a cold boot, RAM file system directories, files and links, database to be included in the object store of the run-time image, created also during a cold boot and locale-specific definitions (strings), that will replace visible texts to a user.

In conclusion, lots of files, which lots of values. Therefore, lots of possible vulnerabilities.

Now, as I mentioned in the beginning of the post, this is one of those days, when a WinCE6.0 process works perfectly, until boom! No modification done to the image, and while building a second time, I get lots of strange errors (ok, I admit, I did add some insignificant registry keys, but there’s no way a registry key could affect missing .tmp files used during a build process).

After a lot of digging up and re-re-re-re-re-re-re-build, I’ve realized it’s all got to do with my antivirus. Even though I pray for health and wealth for its developers when I go to sleep, I do admit it has a drawback: scanning the opened files used by an application will delay application responsiveness and therefore, the build process.

Apparently Kaspersky isn’t related in any way to Platform Builder (unfortunately), so I had to manually detect which are the executables that run most often in the build process of a WinCE 6 O/S image and create an exclusion for them. Since most of the anti-viruses has such a drawback, I’ll list them so you can add them yourself to your anti-virus’ exclusion list as well:

  • Platform Builder addlib (<WinCE installation folder>publiccommonoakbini386addlib.exe)
  • Platform Builder Res2Res Resource Copy Tool (<WinCE installation folder>publiccommonoakbini386res2res.exe)
  • Platform Builder Build File Filter Tool (<WinCE installation folder>publiccommonoakbini386cefilter.exe)
  • Microsoft Resource File to COFF Object Conversion Utility (<WinCE installation folder>sdkbini386cvtres.exe)
  • Microsoft Linker Stub (<WinCE installation folder>sdkbini386editbin.exe)
  • Microsoft Program Database (<WinCE installation folder>sdkbini386mspdbsrv.exe)
  • Platform Builder Program Maintenance Utility (<WinCE installation folder>sdkbini386nmake.exe)
  • Microsoft Incremental Linker (<WinCE installation folder>sdkbini386x86link.exe)
  • Platform Builder PBSpawn Utility (%Program Files%Microsoft Platform Builder6.00cepbIdeVSPBSpawn.exe)
  • Microsoft Visual Studio 2005 (%Program Files%Microsoft Visual Studio 8Common7IDEdevenv.exe)

Addid this files should help you in case you keep getting random BLDDEMO errors, which don’t really say much of an error in the error or log file…

So, in conclusion, there are some executables that would like to open a file, but the anti-virus kicks in, scans the file and executable will stop with an error for not being able to open (read ‘find’, instead :-)) the file. So what you should do is to add a collection of executables as exclusions to the anti-virus, thus not scanning the files that those executables open.

That’s all for now.

Alex

P.S.: You might find that xcopy or copy will also be used (doh!). Adding them as an exclusion is however not such a bright idea, since most viruses will use either of them to populate themselves through the drives…

Guess what! The goodies have arrived 🙂

The GPS project I will soon start working on is about to… be started :). Today the courier has finally arrived with the GPS Evaluation board and the GPS receiver module, which rocks :). Surely, there wasn’t much time to test everything, since it have only passed like 20mins since I’ve received the first pieces of the puzzle. So far, I have the GPS-08334 Evaluation board (this is actually optional, but is great – in my opinion – for starters) and the EM-406A SiRF III Receiver. I’ve ordered them from sparkfun.com (I can totally recommend it, even if it’s 10% more expensive than other online electronic shops). Pictures were taken with my HTC HD2 (aren’t they awesome?).

IMAG0031 IMAG0033

Pieces (of the puzzle) yet to receive: the Vortex embedded board.

Just for fun, I’ve tested the module using the SiRFDemo application, and everything worked like a charm! I’ve connected the eval board to the development station (which is currently an IBM T60 laptop) using the USB connection available due to the evaluation board. For the final project, I intend to use RS232 only.

So what’s next? I’ll write my own NMEA class for the communication with the GPS receiver module (again, over RS232).

To be continued…

Alex

It’s not that I didn’t know this for such a long time, but today I’ve just realized that there are so many questions regarding automatic application launching.

So, leaving the startup process aside, once WinCE has loaded, the system loads all the applications specified in the HKLMInit registry key, with the values of LaunchXX. The XX stand for a integer value between 00 and 99 (this means that 1 should be coded as 01). The XX values actually represent the sequence that applications are launched (so 00 will be launched first, 01 second etc.). It is good to keep in mind that the system will not wait for an application to ‘fully’ start. This means that it will generate an interruption for each and every application in the Init key, in a specified sequence, without creating a delay or a timeout between any two consecutive applications in the sequence. This is good since it means that application launching cannot create any kind of system hangs (at least in theory).

However, it is sometimes necessary to create a dependency between applications (application MyShell.exe cannot start – in the developer’s point of view – without running Shell.exe, since, for example, it is using some variables generated by Shell.exe). Therefore, a DependXX value can be used, where XX should match the value in the LaunchXX key where the dependecy is specified.

LaunchXX contains a value of the REG_SZ type which must be the name of the program that needs to be launched, such as MyShell.exe, without the parameters. Again, the XX value determines the load order.

DependXX contains a value of the REG_BINARY type, which enables you to determine the dependency of applications on other applications during the load by specifying which applications must be loaded prior to the application specified in the corresponding LaunchXX key. The indexes of XX applications that a given application is dependent on are specified as a lists of words with a reverse byte order. It is important to keep in mind that a word is (as usual) 2 bytes long.

The application specified in the Init registry key must inform the system that it has loaded successfully and the dependent applications can be loaded by calling the SignalStarted() function with a parameter that it is passed to by the system as a command line parameter
during the load.

An example of the Init registry key is shown below:

[HKEY_LOCAL_MACHINEInit]
“Launch10”=“shell.exe”
“Launch20”=“device.dll”
“Depend20”=“hex:0a,00”
“Launch30”=“gwes.dll”
“Depend30”=“hex:14,00”
“Launch50”=“MyShell.exe”
“Depend50”=“hex:14,00, 1e,00”

In this case, the shell.exe application launches first, then it loads the Device Manager (device.dll), which depends (in the example) on shell.exe, then it loads gwes.dll, which is dependent on the Device Manager, and finally, MyShell.exe, which depends on both the Device Manager (device.dll) and gwes.dll.

Normally, setting up the startup options is something you would do on OS image building. However, in case you can’t do this before building the image, and considering you are using a Hive-based registry, it is ok if you use a Registry Editor or a Remote Regustry Editor (like the one over KITL) and update the registry ‘manually’.

Word of advice: always be sure to double-check the launch sequence! It is possible that certain BSP features or drivers are already in the sequence and required by the your OEM. Using the same XX value twice in a sequence may cause system crash or system ‘hang’. In case you want to auto-launch only one application (your main application for the system), it is probably best to assign it the 99 value (in case it’s free :-)).

That should be it for now! Comments are very welcome!

Alex