Windows Embedded Cookbook
Valter Minute's blog
March 2009 Entries
APIs to create APIs
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).
Share This Post:
Wednesday, March 18, 2009 1:29 PM
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
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!
Share This Post:
Tuesday, March 3, 2009 1:55 PM
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
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.
Share This Post:
Tuesday, March 3, 2009 1:29 PM
December 2014 (1)
August 2014 (1)
July 2014 (1)
October 2013 (1)
July 2013 (1)
January 2013 (2)
December 2012 (2)
September 2012 (1)
June 2012 (2)
May 2012 (1)
December 2011 (2)
November 2011 (3)
September 2011 (2)
August 2011 (1)
June 2011 (1)
March 2011 (1)
February 2011 (1)
January 2011 (1)
December 2010 (2)
November 2010 (1)
August 2010 (2)
July 2010 (2)
June 2010 (2)
May 2010 (5)
April 2010 (1)
March 2010 (7)
February 2010 (3)
January 2010 (1)
November 2009 (3)
October 2009 (3)
September 2009 (4)
July 2009 (2)
June 2009 (1)
May 2009 (2)
April 2009 (1)
March 2009 (3)
February 2009 (3)
January 2009 (5)
Toradex Developer's Website
Toradex Main Website
"Windows Embedded Compact 7"
"Windows Embedded Compact 7" "Silverlight for Windows Embedded"
Silverlight for Windows Embedded
Windows Embedded Compact 7
Copyright © 2005 Valter Minute
This work is licensed under a
Creative Commons License