[TUT] Beginners guide to Windows Mobile (prepare for cooking)

---

Puzzled with all the buzzwords and your head is spinning?
Still want to learn a little about the strange world of Chefs and cooking?
Even are tempted to ask some questions but have not dared yet with all the geeks around here?

Here is a little nutshell-guide for you to lift you up:

The windows mobile operating system is composed of several parts (and this in several regards not always aligning) and it is helpful to understand the basic architecture to evaluate your problem against that.
This is not a detailed guide, it will not link to any sophisticated tools and it will not solve your problems right away. I just try to supply a little nutshell approach (simplifying some things - don't flame me for this if you know better) to put things in the right order.
After reading (and understanding) you are hopefully enabled to search for the right answers in the vast pool of wisdom around the web. You should also be able to tell apart the tales from the facts (on some level at least) and - if you need - ask the right questions and not immediately be ignored as a noob.

You see below a map that allows you to locate the various terms to the right places.
I will then elaborate a little on each of these in hierarchical order.

ROM file (usually packed into an update service pack containing also the update SW)
Parts:
- IPL
- SPL
- OS 
  partitions:
  - USPL
  - XIP
      - Generic(MS) and OEM parts -> XIP porting
          - packages (*.dsm + *.rgu)
              - files and modules
  - IMGFS
      - Generic(MS) and OEM parts -> the usual ROM Cooking is here
          - packages (*.dsm + *.rgu)
              - files and modules
                  - languages
                      - T9
                      - *.mui.*
                      - *.provxml + lang_db
  - ExtROM
- GSM/Radio
- Boot-Splash

ROM parts and Partitions:
Let us first look at the flash memory of the device. This is handled from the SPL (secondary program loader) during boot (passing control to the OS) and flashing where the different parts that are present in a ROM file will be written to the places of flash memory of the device.
The well known parts of a flash ROM are:

• the IPL (Initial Program loader),
• the SPL (secondary Program Loader) - a powerful on-board pre-OS program that is the gate-keeper for all further actions
• the OS (Operating System),
• the Radio (GSM),
• the initial boot-splash
• and others like ExtROM which is just a FAT partition for storing post-first-boot configuration and installation programs - depending on the device.
• There are some more parts in the device memory for security reasons that hold the IMEI, SIM-Lock data and possibly other data that can be used for forensic analysis.

Shipped (vendor or operator original) ROMs usually contain ALL parts of a ROM so that you do not depend on a previous ROM to get a usable device.

Interesting for cooking is only the OS part of the ROM.
This holds ALL parts that make the difference between the windows mobile OS versions. Some cooks have added their own splash screens as ROM parts (additional to the ones that are displayed when to OS boots later), for some ROM flashing it is also required to replace the SPL (temporary or permanently) allowing the flash of non-signed ROMs or at least make it believe that you are allowed to do that (Super-CID).
Sometimes it is useful to step up to the latest Radio version to exploit features that this offers.

But again: Cooking is only about the "OS" part of the ROM! Only the OS part is usually replaced by flashing new cooked ROMs.

This OS part is structured into "partitions". So you can look at the OS part as something like a hard-disk in your PC that can also have partitions with different file-systems serving different purposes. For the OS part of the ROM the sequence of partitions is the

• ULDR (look that up yourself) which is usually not needed and can often be removed or minimized,
• then the XIP (historically "eXecute In Place")
• then the IMGFS (Image file-system)
• and some additional partition, e.g. for the ExtROM.

XIP and IMGFS make up the Windows Mobile OS and are subject to "cooking".

XIP and IMGFS:
In the boot process the SPL passes control to the nk.exe (Native Kernel) in the XIP and it will load the early drivers and services that allow to reach a certain minimal OS service level to access the IMGFS for further boot.
The IMGFS itself holds all the rest of files and modules to start the OS to that level where the user can use it.

OEM and the rest:
The HW of most mobile devices is special in one or the other way. Dedicated drivers are needed to abstract the HW dependent parts to a level that the Operating system can interface with them in a standardized way. All these are summarized under "OEM parts" (Original Equipment Manufacturer) while all other parts are from Microsoft and are supplied in a generic way.
You can suspect that all OEM parts have to be compiled taking the HW specifics into account, while the generic parts can be taken as is (binary) and both will be assembled to a final ROM production.

This separation of OEM and "the rest" makes "cooking" and "porting" possible at all. If this architecture was not designed by Microsoft, then there was no cooking in the kitchen
OEM parts stay usually unchanged through all cooking and porting activities, so that also means that a WM5 device will keep all the OEM parts even if the OS version is WM6.5. OEM parts are in both, the XIP (nk.exe and some OEM modules) and the IMGFS. You will especially not gain any advantage of the enhanced memory allocation scheme if your device does not have a native 6.5 kernel (nk.exe).

OEM may also add applications to their devices that exploit special HW options of the device (e.g. the camera application) or that are the result of an effort to make their devices unique (like HTC's Homescreen).

Kitchen separate on top-level into SYS and OEM folders but the allocation of packages (see own chapter) to either one or the other is not uniform. Some add the OEM drivers (i.e. the true HW dependent parts) in the SYS folder, others (newer) kitchen put them also under the OEM top-level.

Packages and ROM Protection:
To keep the various parts of a ROM well organized, Microsoft has created an environment that allows to produce ROMs in an easy way. This is not accessible to us ROM hackers, but the remains of the packaging tools in the ready assembled original ROMs have inspired many hackers and chefs to utilise the same methods.
They created tools to de-compose original ROMs and also to use the same methods for creating new ROMs. Over time these tools have become very sophisticated and may even offer more options than original MS tools (I guess). As all this is a shared activity with many contributors, it is important (in my view) to keep sharing what you discover.

In original ROMs you find many files like <some-strange-number-letter-combo>.rgu and also <*>.dsm. These are the remains of the packaging process that has created the ROM. They are NOT needed on the device itself! However have those files allowed to understand the process of building a ROM.
These <some-strange-number-letter-combo> elements are called GUID (Globally Unique Identifier) and are identifying packages. The DSM (Device Side Manifest) file identifies all components of a package (their name, status, properties, size, build properties and much more) while the RGU (Registry Update?) file identifies the changes that are made to the standard registry hive for that package.
So ultimately one method of ROM "protection" that some kitchen offer and that some chefs are using is to remove all the *.dsm and *.rgu files before they build the IMGFS. The resulting ROMs still have all files that are needed for the ROM to run, but they cannot be decomposed to packages (the .dsm files are missing) again and during re-build the *.rgu files are missing to update a standard hive file (e.g. of a new base ROM from MS).

Files and Modules:
Logically the smallest parts are files, which is common to all operating systems. There is one specialty however in the WM-OS and this is so called "modules".
They are basically memory-fix located executable files which can be loaded faster than normal executable files. As their memory location is fixed in the production process, all those modules must not overlap their memory. The process of realigning a new set of modules to the available memory locations is called "re-location" or "re-allocation". Tools like mreloc, G'reloc, wmreloc, extreloc or within OSBuilder take care about this in the production process.
You recognize modules that they are folders in the kitchen with the name of the module and some files inside that make up their content. These modules later "look like" files in the \windows folder of your device but they are still modules which are just hidden from your visibility by the filesystem presenting the data to you.
Even worse for easy understanding is that you seem to be able to "overwrite" such files on your device later, but you do not actually overwrite them. You create a file with the same name in the FATFS that is linked to the IMGFS where the ROM is stored. The copied file takes precedence over the original one in ROM. This works for many files in ROM, but NOT for those who are loaded before the FATFS is active (e.g. after cold-boot the FATFS is empty or during early boot-phase when the XIP partition is loaded).

Languages in a ROM:
While it was usual in older times to have multi-language ROMs, this habit seems to vanish with newer devices and several vendors produce country specific ROMs only. However does Windows Mobile offer all options to have many languages present in a ROM. The places that need adjustment are multi-fold, however only some need real attention usually.

• Luckily the country specific details of time/date/number/currency and alike are stored in a common database and are present in all devices no matter which user interface they have (afaik the nls file). Also the naming of the settings options (e.g. "Short Date Format") are present in all languages already. There is no need to adjust this usually.
• The text entry system (T9 or its successors) is handled by a dedicated package and new languages can be added quite easily. The languages here are independent of the language settings for the UI, so you can have a device with only WWE (World Wide English) on the GUI but still have your local language supported e.g. for sending text messages. Mind that usually all language databases must be of the same (matching the T9 executables) version to work properly. You cannot pick an arbitrary language file from another T9 enabled device.
• The programs or dll that are constructed to support multiple languages have in many cases <program/dll-name>.mui.<nnnn>.* files where the "mui" indicates "multilingual user interface" and the <nnnn> the relevant 4 digit number of your language (0409 is US English, 0407 is German and so on..). Usually there are dedicated packages in a ROM that supply all necessary changes to the registry so that this language is supported when you switch to it in the regional settings.
• Applications that a chef has added to a ROM may need separate methods to add a language, most are not having an automated approach or are only supporting their own native language. You could still work on the binary file directly, either in a structured approach by de-composing the executable into its resources (e.g. with resource hacker) and add/change strings there or even directly hex-editing the file itself. Mind that you MUST NOT insert or delete any byte - you must OVERWRITE existing strings only. You also have to take care that on a smartphone with certificate security switched on you must remove the existing certificate (if any) and re-sign the file again.
• The settings themselves are a special system of menus (*.cpl.xml) on a smartphone that manipulate registry data or other values of the device. For that purpose the settings are using the already existing "Service Provisioning" method that can as well be used via WAP or with other means.

• To make that provisioning in some way a little user-friendly, there is a process to define names and options for changing such data - finally they are stored in a database on the device.
  Now when you call the settings menu, the system reads the elements that shall be changed and also the linked information (label, limits, representation) from that database to present this on the screen.
  So if you like to have more parameters in the settings menus or if you want to make your own panels for settings or tweaks, then you have to deal with adding your information to that database.
  This is done with *.provxml files. These files are treated on the device (so not during cooking where the *.dsm and *.rgu files are used) and they are handled on different occasions (first/cold boot, sometimes also on other occasions). This is also why a "first boot" of a ROM is taking much longer then subsequent boots. So if you want to find out which additional settings-options are in your ROM, parse all *.provxml files for your country string (you remember "0409"?) and add relevant parts for the language you want to add.
  This is tricky though: the files are stored in UTF-8 format without the UTF-8 header. If you save them in the wrong encoding they will not work any longer! I use the free notepad++ editor (http://notepad-plus-plus.org/) that handles them well.
  The final part in this story are the settings panels themselves (usuall in the OEMMISC folder: *.cpl.xml). Also here some labels are defined in a language specific way - just add what you need per language following the obvious pattern that is given in the files already.
• Now that I see the above, I noticed that the smartphone homescreen is also an XML file - so also there the labels and options can be set in a language specific way. Look up the *.home.xml files if the language you want to deal with is present in these files. Usually the MS defined homescreens have very many languages already inside, so you may not need to change anything here. As mostly nobody cares about smartphones any longer and even less about old-style homescreens - this may have no need to be mentioned.
• [added 2012 02 24]: Hardly documented (but widely used) and very useful is that the registry supplies an automatic NLS dependent branching of values. So if you have a value like HKxy\path1\path2\myvalue and you want to have two different data for it, each depending on the selection of the active interface language, then supply the value like:
  
  
  
  • HKxy\path1\path2\0409\myvalue=<English string>
    Example (from SYS\Base_Lang_nn):
    [HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0409]
    "FriendlyName"="Smart Card or Certificate"
    
  • HKxy\path1\path2\0407\myvalue=<German string>
    Example (from SYS\Base_Lang_nn):
    [HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0407]
    "FriendlyName"="Smartcard oder Sicherheitszertifikat"
    
    
  Note that specialty cannot be seen when you access the registry with standard means (so via the device itself) later on anymore. You will just see the registry path of the current selected interface language. Tools that can read the created hives directly will show them.

Bottomline for dealing with languages:

• know the number for your language and the one that is in a ROM
• care for T9 libraries and make sure to use all of the same version
• find the version matching *.mui.* files for the language to add
• search all kinds of XML files (*.provxml, *.cpl.xml, *.home.xml) for the language number and make your changes
• inspect the *.rgu of the language dependent packages and see if all items are set properly. Be inspired and create your own language dependent registry values.

When you move ahead in your strive to cook your own ROMs, you will notice that old style (batch file) kitchen give you control over what happens when as you are calling the dedicated tools for certain jobs directly.

Newer Kitchen have assimilated all work-flows in their own GUI, some still needing the tools that also the batch file kitchen use.

The latest breed of kitchen has most tasks built in. So you are completely left with the style that the master of that kitchen has implemented his understanding of work-flow logic. Sometimes it is hard to understand what belongs where (for a noob that you may be reading until here - it is hopeless anyway) - but as long as you understand the architecture you can have your own mind-map and put things together on your own.



If you like and have some old devices to play with, why not give it a start with any of my 3 kitchen for the good old Candy Bar smartphones which HTC had created?

1. WM65 (English/German) OS Builder Kitchen + ROMs for Typhoon based on Aleut's WM65 ROM
2. OS Builder Kitchen for Hurricane: WM6, WM6.1 and WM6.5 English + German
3. OS Builder Kitchen for Tornado: WM6, WM6.1 and WM6.5 English + German

You need to fix some battery stuff related to these old gems, look here:

1. [now without battery ] Replace Backup Battery in Tornado, Hurricane or Typhoon
   mind that the cooked ROM from the kitchen above already contain the "without battery" part.
2. Measure and compare your battery capacity - easy, foolproof, comparable - any WM dev

If you like this tutorial and it has given you some more insight, please push the "Thanks" button at the bottom.

Nice post mate, this his all foundation in a nutshell-guide .

Thanks.

I agree, nice tut. No doubt, it will help many people!

I'be been reading all, wow, so detailed.

Nice job indeed, thank you.

Grtz,

Laurentius26

Great work. Simple and precise

added language dependent registry branches

---

Not many left who wish to cook anymore, so just to complete the language dependent items in my original post.

Hardly documented (but widely used) and very useful is that the registry supplies an automatic NLS dependent "branching" of values. So if you have a value like HKxy\path1\path2\myvalue and you want to have two different data for it, each depending on the selection of the active interface language, then supply the values like:

• HKxy\path1\path2\0409\myvalue=<English string>
  Example (from SYS\Base_Lang_nn):
  [HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0409]
  "FriendlyName"="Smart Card or Certificate"
• HKxy\path1\path2\0407\myvalue=<German string>
  Example (from SYS\Base_Lang_nn):
  [HKEY_LOCAL_MACHINE\Comm\EAP\Extension\13\0407]
  "FriendlyName"="Smartcard oder Sicherheitszertifikat"

Note that specialty cannot be seen when you access the registry with standard means (so via the device itself) later on anymore. You will just see the registry path of the current selected interface language. Tools that can read the created hives directly will show them.