March 2009 Entries
APIs to create APIs
Antelope Canyon (Arizona, USA)
I hope that the title sounds funny, because, as usual, I can't found a better one...
During the last months I had to port from CE 5 to CE 6 a project where I used an undocumented feature of Windows CE 5, the ability to register an API sets.
This feature allows an application, a driver or a system module to register its own APIs, that can then be accessed by application as regular OS APIs.
I had to use that undocumented feature to provide some redraw functions for a custom "skin" of the Windows CE UI.
In Windows CE you can provide your own custom implementation of windows and control drawing functions. This great (and not so well documented, IMHO) feature of the OS allows the creation of user interfaces that are completely different from the one provided by default and allow a full and deep customization of the UI of all the applications running on your device, both custom ones and OS or third party provided ones.
In my custom UI I needed to export some drawing  functions to .NET applications, to let those same function to be used inside managed custom controls, to keep all the UI coherent.
I didn't want to duplicate code, and the implementation of custom UIs on CE (static libraries linked to GWES) does not allow any "generic" function call interface (like DeviceIoControl for drivers or KernelIoControl for OAL).
I tried to find another mechanism and stumbled upon CreatAPISet and other API-realted functions inside the CE shared source. Having the source code of most of the OS is a great tool for a hacker... and I used it to create my own API set.
After having bored you with this sad story about myself, I'm happy to announce that now the APIs that can be used to create your own API set (sounds like a joke) are documented inside Platform Builder reference!
If you search "Creating, Registering, and Using a Handle-based API Set" inside PB help or simply follow this link:
you will find a detailed description of the operations required to register your own API server and use this feature of the OS.
This also made my porting simpler and keep me safe from the side effects of using undocumented features of an OS: the risk of losing compatibiltiy with newer versions and the risk that some of those functions may have unexpected side effects when used in some particular conditions (the nasty thing you usually discover inside the "remarks" sections of the reference page of documented APIs).
Posted On Wednesday, March 18, 2009 1:29 PM | Comments (0)
Pasta cacio e pepe

I've been in Rome last week for the Windows Embedded Seminar and I had a chance to appreciate a very tasteful pasta that it's typical of that city.
It's also a very simple and quick recipe, and one of my favorites when I came home late from office and I've only a few minutes to cook something edible.
The ingredients list is quite short:
- long pasta (spaghetti or bucatini)
- grated cheesee (the original recipe uses "pecorino romano", cheesee made with sheep milk)
- pepper powder
- olive oil
- salt

Put water in a pot, heat it and wait until it boils (you can grate the cheesee in the meantime...).
When it boils put salt inside it, wait until it boils again and drop the pasta.
Cook it for 1-2 minutes less than the cooking time specified on the box.
When the pasta is almost cooked take a couple of tablespoons of the water and put it inside a recipient with the grated cheesee, mix them well until you get a sort of cream (add some water if needeed).
When the pasta is cooked, put a tablespoon or two of olive oil in a pan, remove pasta from water ad drop it in the pan with the cheesee sauce and a generous amount of pepper powder. Stir it for a couple of minutes and serve.
It's quite a simple dish, the ingredients are easy to find (in Italy, at least), but if you have a chance to taste it in Rome, I can grant that it tastes better than ever.

P.S. The picture above was taken in Porto (Portugal), because I did not take pictures in Rome.. but I like to add some color to my boring posts and Porto is quite a beautiful city, like Rome, so  forgive me for that!
Posted On Tuesday, March 3, 2009 1:55 PM | Comments (0)
Gimme the right key
This post is not about lockpicking... it's about registry settings (and keys) and configuration files, but I can't manage to find a better title.
You can configure a Windows CE OS Image using different kinds of configuration files.
Registry files (.reg) allows you to configure the registry and, since most of the OS components read their configuration from it, it allows you to customize most of the components that you can add to your OS Design.
The merge order of the reg files is somewhat counter-intuitive. The system takes common files first (common.reg and .reg files from different OS components), then merges project.reg (OSDesign specific), then the platform.reg (BSP specific) and, last but not least, the .reg file of your subprojects. The merge tool overwrites values with new values while processing the merged registry file (reginit.ini), and that means that if you have more values specified for the same parameter inside different files, the values specified inside the last merged file is the ones that will be included in the OS image.
If you need to override a common settings (for example the size of IE cache), you can do that inside your BSP configuration (not a good idea in my opinion, because this parameter is not related to the hardware) or inside your project.reg (one for each BSP included in your OS design) or in one of your subprojects settings.
Things get more complicated if your want to override a BSP-related parameter. If you do that inside platform.reg you'll modifiy that parameter for all the OSDesigns that use the same BSP (unless you use some enviroment variable to include it only in a specific OSDesign). You can also remove it from platform.reg and move it inside project.reg of all the OSDesign that share the BSP, each one with its own parameter, but if you make a new OSDesign you should remember to include that parameter in your project.reg... quite a maintenance nightmare.
If you want to set the same parameter for all the BSPs included in your OSDesign you cannot change common.reg or other system files (this will change the parameter for all the platforms generated on your PC and may be overwritten by QFEs released by microsoft) and you'll have to add it to each platform.reg, keeping them synchronized.
An alternative approach that could solve this kind of problems is to move those parameters inside the configuration files of one of your subprojects. If you don't want to put inside a subproject some parameters that are not specific for that components you can add an empty subproject for this pourpose.
You can download a template from here.
The project is named "Settings" (it's a good idea to use the same name on every OSDesing, so you can recognize it as a special subproject) and it builds no target but provides a .reg file that allow you to have "the last and definitive word" on your registry configuration and share the parameter between the different BSP-based configurations of your OSDesign.
It provides also .dat, .db and .bib files to allow you to customize the filesystem, the databases or to add some files to your OSImage.
Posted On Tuesday, March 3, 2009 1:29 PM | Comments (0)
Toradex logo

Tag Cloud