[OS][WM6.5.5] Latest Releases (23563), Porting, Tutorials, Tools, VM, etc.

Post 2: Virtual Memory and Windows Mobile 6.5
Post 3: Registry tips for Windows Mobile 6.5
Post 4: Tutorial on language porting with Visual Kitchen
(new!) Post 5: Description of all packages found in Rollup
(new!) Post 6: Description of the different branches of WM development.
ace10134's Post: Tutorial on porting a new build to "old style" kitchen
+ Que PPC's Post: Tutorial on porting a new build to Ervius Visual Kitchen
indagroove's Post: Tutorial on porting xip.bin for Ervius Visual Kitchen
rgb-rgb's .pdf: Tutorial on porting XIP/SYS to Da_G's Raphael Kitchen
CRACING's: Placing an Custom Image in the About Dialog/Window

WM 6.5.5 Build 23563 - All Langs, All DPI, All Resolutions

Edit: If this download link is dead, then search this thread or the stickied build thread for the build number and mirror.

Language Localization Packages

0401 SAU Arabic المملكة العربية السعودية
0403 ESP Catalan España
0404 CHT Chinese Traditional 台灣
0405 CSY Czech Česká republika
0406 DAN Danish Danmark
0407 DEU German Deutschland
0408 ELL Greek Ellas
0409 USA English United States
040B FIN Finnish Suomen tasavalta
040C FRA French République française
040D HEB Hebrew מְדִינַת יִשְׂרָאֵל
0410 ITA Italian Repubblica Italiana
0411 JPN Japanese 日本
0412 KOR Korean 한국
0413 NLD Dutch Nederland
0414 NOR Norwegian Bokmål
0415 PLK Polish Polska
0416 PTB Portuguese Brasil
0419 RUS Russian Россия
041D SVD Swedish Sverige
0804 CHS Chinese Simplified 中华人民共和国
0816 PTG Portugese Portugal
0c0a ESN Spanish España

images taken down to comply with DMCA notice

This thread is dedicated to porting past/current devices to WM 6.5/Windows Phone and future versions, The latest release of XIP/SYS, issues that might come up when porting it to pre-WM6.5 devices, compatibility with "OEM" Packages, etc.

This is intended as a followup to the thread Here, which contains a mountain of useful info, attachments, etc, but is getting very long in the tooth and is device-specific, whereas this thread will be used for all devices. (that one was anyway!)

The Native Kernel Partition (XIP)

This is generally Partition 2 in the Partition table (following ULDR, and preceeding OS). It is split up into 2 Major ROM Packages, and several possible Minor ROM Packages. OEMXIPKernel makes up the device-specific part of NK, and MSXIPKernel makes up the device-agnostic part of NK. When porting from your current WM version to 6.5, you want to keep OEMXIPKernel as is, and only change the MSXIPKernel files and modules. An important module to consider in OEMXIPKernel is nk.exe - this module is the Native Kernel for the device and handles Virtual Memory, which has changed for WM 6.5, and is discussed in the following post.

You can check to see if you have a 6.5 Native Kernel by dumping xip.bin, and opening nk.exe/s000 in a hex editor. Search for the ASCII string "platform" - near this string should be the build number this nk.exe was compiled against. WM 6.5 builds began around 21100, and nk.exe compiled against them can take advantage of the new memory model discussed below. WM 6.1 and previous builds will be <=21058. nk.exe compiled against these builds will not be able to use the new memory model.

The Operating System Partition (imgfs.bin)

In your kitchen, you want to use the new /SYS from the same build that matches the MSXIPKernel if possible. Occasionally the builds do not match up, this is normal. The /OEM folder generally does not change, but when coming from WM 6.1, you will need to update your initflashfiles.dat with the new shortcuts and folders introduced in WM 6.5.

MariuCh007, enjoy
http://www.filefactory.com/file/b47f1fd/n/23563_All-Res_All-Lang.7z

Virtual Memory in Windows Mobile 6.5 and how it differs from 6.1 and 6.0, important when porting to a device that does not have a WM 6.5 Native Kernel

What is Virtual Memory?

Virtual Memory as it applies to the Windows CE 5.2 Kernel

There's a 32 bit address space available - a total of 4GB potential memory on WM. This total 4gb address space is split in half - 2gb to the Kernel, 2gb to the User. Kernel address space is only accessible by processes/threads with kernel level access, whereas user address space is accessible by all processes/threads. The user address space is from 0x00000000 to 0x7FFFFFFF, and the kernel address space is from 0x80000000 to 0xFFFFFFFF.

The user address space is split into 64 slots of 32mb a piece. (64x32=2048, or 2gb) - The first 33 slots (slot 0 and 1-32) are used for processes, and the remaining slots for object store, memory mapped files, and resources.

Each slot is easy to visualize in hex, you just increment a digit. Slot 0: 0x00000000 to 0x01FFFFFF, Slot 1: 0x02000000 to 0x03FFFFFF, Slot 2: 0x04000000 to 0x05FFFFFF, and so on. Each process gets assigned it's own slot, there are 33 total, minus the kernel process which is always running, so that's where you get the 32 process limit (which is always lower in practice, since there are always processes running in windows mobile to support the OS) - this is also the reason for a 32mb limit per process - you can see that's all the address space available in one slot.

How does that all apply to our situation with modules? When you create a module, you are telling Windows Mobile that you want that module to be memory-mapped, so that each time it loads, it's loading to the same, known area of ram - saving space in slot 0 - this is done on the computer-side, during 'cooking' and is the job of wmreloc, g'reloc, bepe's Platform Rebuilder, etc. Virtual allocations are aligned to a 64KB border, so if you memory map a .dll that's only 3Kb large, it's still going to eat up 64KB of memory space.

There are also pages that can be allocated to these slots, that are aligned to a 4KB boundry, and process/general allocations that take place during normal operation. The way the system handles this is that modules allocated on rom build-time (modules we allocate with g'reloc et. al.) are allocated from top-down (for slot 1 for example, starting at 0x03FFFFFF for the first module, taking up space to the nearest 64kb boundry, then the next module, in a line down to the 0x02000000 address, which is the beginning of the slot) - General allocations that take place during normal system operations are allocated in the remaining space, from the bottom-up (so again with slot 1 as an example, starting at 0x02000000 and ending at 0x03FFFFFF) - As you fill up these slots more and more with modules, that leaves less space for windows to dynamically allocate other, general allocations, which can, and does result in out of memory errors (even when the device has plenty of physical memory left, it cannot address this memory when virtual memory is full)

Here's where the kicker comes in for the difference between 6.0/6.1/6.5 - There are a total of 4 slots that can be used for module allocation, slot 0, 1, 60, and 61. 63 is also available to modules that contain no code (resource only modules, like .mui's)

WinMo 6 could allocate slot 0, 1 - (in order of 1 first, 0 last) for a total of 64mb of vm space for modules/files (and the running process is always mapped to slot 0, so once you encroach on this memory space, you are removing available memory to each application running) - you can see how tight this is.

WinMo 6.1 improved on this by opening up slot 60 and 61 (now the allocation order is 61, 60, 1, 0) - but modules could not be allocated here, only files. So for our relocation tools, this was essentially no change. (still only slot 1, 0 for modules) WM 6.1 also introduces the process initvmmap.exe in the MSXIPKernel, NK partition (xip.bin). This process draws a map of all virtual memory, and uses the following registry key from the boot hive (boot.hv):

This tells the system that the module dllname.dll is only required when filename.exe is running, or filename2.exe is running - and whenever these processes are not running, the virtual memory space is available, and can be dynamically allocated to by the system.

WinMo 6.5 improves on this by opening up Slots 60 and 61 to Modules - yielding an extra 64mb of potential Virtual Memory space. (the allocation order is now 1, 61, 60, 0 for modules, 60, 61, 0 for files) - In order for the Kernel to recognize these new Slots as being mappable for Modules, it must be updated to the 6.5 codebase. This is where the 6.5 nk.exe comes in, and why it's so important.

Profiling Virtual Memory is an important job for an OEM - the less available in Slot 0, the sooner a device will kick back out of memory errors (even if it's not truly out of memory) - and the worse the user experience will be. Some ROM's I have seen have less than 20MB available in slot 0 (and the user experience is as bad as you might imagine) - There are many more intricacies to the whole process - like balancing the load between services.exe and device.exe to best utilize the 32mb VM space available to each, and storing all resource-only dlls as modules so they can be allocated to Slot 63, etc.

This is also why it's important that the re-alloc tools be updated to support the new slots - g'reloc will not ever try to allocate modules to slot 60/61 because as far as it's aware, this is not possible. For the moment I know of 2 tools that will realloc to slot 60/61, wmreloc 2.0, and bepe's Platform Rebuilder (used by ervius vk)

What's the take-home message about VM?

Keep Slot 0 as free as possible. WM 6.5 NK allows you to use more modules without taking up SLOT 0 space, so allows more flexibility to use modules (which are faster to load)

Uploading:
23563 http://www.mediafire.com/download/1a2rtasd7gmai5u/WM6550-23563-Rollup-All-Pkgs.rar
23569 http://www.mediafire.com/download/jv19f4e2w920z72/23569.ZIP

Registry tips for WM 6.5

* Start menu icons

Sizes (for png icons):

240x240 96 DPI 45x45
240x320 96 DPI 45x45
240x400 96 DPI 45x45
320x320 128 DPI 60x60
480x480 192 DPI 90x90
480x640 192 DPI 90x90
480x800 192 DPI 90x90
480x854 192 DPI 90x90

All icon entries go under the following key:


Create a sub-key matching the folder name or shortcut name the icon will go with, for example:


There are 4 possible values you can set under this key:

MSFT said:

Name REG_SZ Specifies the display name of the item. If the value is not specified, the file name will be displayed without the extension.
Group REG_DWORD Specifies whether the item is a folder. The value can be set to TRUE or FALSE. Set the value to TRUE to indicate that the item is a folder. If the value is not specified, the system will determine the Group value by verifying whether the registry key has any subkeys.
Icon REG_SZ Specifies the path and file name where the icon is located. The icon can consist of a PNG file or an embedded icon resource module. If this value is not specified, the default icon of the shell will be used.
Rank REG_DWORD Specifies the rank of the item. An item that specifies a larger value for Rank will be displayed before items that specify a lower value. If this item is not specified, the Rank will be set to 0.

Click to expand...

Click to collapse

To determine icon spacing, you'll need to examine the Rank value for existing icons, you can find the stock values in the following file: Base_Lang_xxxx\mxipinit_startmenu_001.provxml, where xxxx matches your Language ID code. A higher number = higher up in the chain, a lower number = lower down the chain. Any icons without a rank will be displayed at the bottom.

* Restore hidden settings items

Remove the "Redirect" value under the following keys:


* Allow in call recording with the native dialer


* Disable built-in magnifier on double-tap


* Override default Lock Screen notification launchers