HTC Extended ROM image editor. This release adds support for Artemis. - P3300, MDA Compact III upgrading etc.

TFAT Image Editor 1.2.0.14
==================================================
A utility to editing Extended_ROM.NBs files.
May be especially useful for use with (T)FAT filesytems image files.
==================================================
Operating systems supported:
- Windows 2000/XP/Vista
Features:
- Create an Extended_ROM image file. Support: Artemis, Athena, Elf, Gene, Herald, Hermes, Titan, Trinity.
- Extract file(s) from the image.
- Write file(s) into an existing image file.
- AutoConfig function.
- Support TFAT 12, TFAT 16 filesytems. 512, 1024, 2048, 4096 sector size.

Related

Actual size of file (extracted using dumprom) is not OK

Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance
XIP files would report incorrect size. Because they are XIP
If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!
I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem
Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel
IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem
If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).

Tool to create custom Ext roms for Alpine

Hi folks,
I've had some sleep now so am editing the original posting to make it clearer and give due credit!
The attached application is based mostly on Wilems (itsme) tool (http://nah6.com/~itsme/cvs-xdadevtools/xda2nbftool/alpinenbfdecode.pl) - so the bulk of the credit goes to him. All I did was work out the checksum algorithm; but as I really suck at Perl, my tool is written in C.
Anyway, this tool allows the decoding of ms_.nbf extended rom files to their header and fat16 image (which can be mounted and modified).
The sneaky part of this tool then allows these two components to be encoded to give a working rom file that can be uploaded to the Alpine device using the usual ROMUpgradeUt.exe application.
Now, PLEASE USE WITH CARE - as I won't be held responsible if using this tool results in a dead Alpine device! Usual disclaimer ..... Also this is an alpha version, so any feedback would be appreciated.
The tool is command line based (no GUI yet - although I will do that soon).
Run the tool without any parameters to get the help - but here's a quick guide:
1. Extract a suitable upgrade (e.g. XDA_IIi_Upgrade_v1.11.162.exe) to a directory like c:\upgrade
2. delete nk.nbf & radio_.nbf files
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. run it to extract the fat16 file and header :
alpine_ext_rom_tool.exe -d -n ms_.nbf
5. this creates ms_.fat and ms_.hdr
6. edit the ms_.hdr (see comments in this file for instructions)
7. mount ms_.fat and add/remove files as needed (updating Config.txt)
8. delete the old ms_.nbf file in c:\upgrade
9. run the tool to create a new nbf file:
alpine_ext_rom_tool.exe -e -f ms_.fat
10. make sure the files been created
11. run ROMUpgradeUt.exe or MaUpgradeUt_noID.exe to update the extended rom on your alpine!
Let me know how you get on if you do decide to give it a go!
Cheers
There's a new GUI version of this tool now available here : http://forum.xda-developers.com/viewtopic.php?t=34783&highlight=
Splash screen
Well as a follow up and after some experimenting - seems like the splash screen is hidden within the extended rom somewhere.
I used the Imate and O2 extended roms as bases, and even after deleting all cabs, etc, within these files and placing my own cabs within - I still get a splash screen which is different between. That is the Imate one using the imate extended rom and the o2 one using the o2 extended rom.
I assume that this is hidden somewhere, but not as a file. It would be nice to be able to edit this as well. Does anyone have any information on where the splash screen may be?
Although I haven't tried using a new, clean, FAT16 image file ... maybe that would give just the default windows mobile splash.... hmmmm
Hey ho
splash image
Splash screen is appended at the end of the FAT16 image.
The size of the fat file extracted from the nbf file is 0x18C0000 and the last 0x40000 bytes of this file are the splash screen in nb format.
So theoretically if you replace the last 0x40000 bytes of the fat file with your chosen splash screen (format as nb using nb_image_converter_859_418.exe) then that's the splash screen you'll get on startup....
Hmmmmm, quiet round here ain't it? Maybe I'll just talk to myself :wink: - more than likely this has all been figured out before ... perhaps I should've done some searching before I started?
Hey ho
hey ho! ;o)
bro, you've made a cool proggie!
don't be disappointed by no answers... maybe there are not so many Alpine users out there...
keep it up and take care...
buzz
Hi Buzz,
Dakujem - thought I was talking to myself there for a little while .... not unheard of!
I suppose until hacking these roms becomes simpler (at least until there are some nice gui programs) it'll remain a bit of a niche market.
But I'm learning to live with the short-comings of the XDA 2i ... nearly :shock:
;o)))
nemas za co... ;o)))
buzz
I don't think the same as bal666.. In fact there are many people waiting for their Alpine 's to be mungled and squeezed just like the BlueAngel There are just so many stuff for the BlueAngel and it makes some people buy BlueAngel. I believe there are a lot of non-posters here that are waiting for some stuff like yours <g>
Hi all
Yes i'm another, doing the rounds of the forum's and threads looking for a convienient solution to the extended ROM. I been sitting on the outer cause i don't think i can make a worthwhile contribution to your quest.
I'm just not prgram savy
Good at following instructions thow!!
I'm desperate to build a nice extended ROM with all the features of Special edition you guys produced some time ago.
Could you point me to a CABS listing that can tell me whats worth retaining/ updating/removing. I'm using the Dump ROM out method.
Which incidently is giving a little grief with format of the created files, ext .img. Any thoughts
So keep up the good work, i'm sure theres a stack of people counting on your good work.
Mike
Hi SubZero & Mike,
thanks for that - makes it seem somewhat more worthwhile. I actually wrote the tool out of boredom, and the fact that I continually play with my XDA and wanted an easy way to restore all my programs and settings; rather than doing it manually.
Mike, there are a number of pages/sites with extended rom cab listings - like http://www.dmmh.nl/xda/ although I couldn't get into it today.
As for your dumprom problems ... sorry mate I've never used it - although there is a thread somewhere here with that (although I'm sure you've seen it) ...
Anyway, the next program will do the same as now but also allow the alteration of the built-in splash screen image - might as well now I've started. But I doubt I'll do a gui version, it's just not worth the aggro!
Cheers
Your right link seems to be down, any other sites would be good.
How could we, the alpine community convince you to develop a GUI??
Think of the incredible personal prestige and total job satisfaction you would get from this.
This is a terrible suck job if you hadn't realized by now.
Thanks
Miket
I thought I'd post this here as a link to a thread I started on updating the XDA2i extended ROM (you are not alone in your crusade)
http://forum.xda-developers.com/viewtopic.php?p=171104#171104
There are lots of bits inside there but the method pointed to works if all you want is to modify the Extended ROM.
http://en.pdamobiz.com/en/forum/forum_posts.asp?TID=373&PN=1
Have fun,
Graham.
Checksum Algorithm
Hi GBird,
thanks for that.
Also I've had a few people ask how the checksum is calculated, so the code is included below. The alpine_crc_key_lookup uses the same keyset as the blue angel - see nbfutils from wilem (itsme); and I suspect the algorithm is the same as well (I'm not going to go and look ... too much effort involved).
Generate a crc for the fat16 image portion of the extended rom and add this to the crc for the header portion (without the checksum field, meaning only the first 120 bytes). This gives you the key you should be using to encode the whole extended rom.
Enjoy!
Bal
--------------------------------------------------
DWORD alpine_crc(
char data[],
int data_len,
DWORD crc)
{
int i = 0;
DWORD crc_new = crc;
/***********************************************************
* Calculate the CRC for this data stream
* Based on a decompilation of the RUU.dll loc_1000C174()
***********************************************************/
for (i = 0; i < data_len; i++) {
crc_new = (crc_new >> 8) ^ alpine_crc_key_lookup((data & 0xFF) ^ (crc_new & 0xFF));
}
return(crc_new);
}
Dear bal666
As a newbee, please instruct in detail the upgrade process from step # 6, 7 & 9
wait for your news
thanks for your hard work
Hi Harry
simple instructions would be as follows:
1. Extract a suitable upgrade, preferably from your provider to a directory like c:\upgrade. Mine is O2, so I use e.g. XDA_IIi_Upgrade_v1.11.162.exe
2. delete nk.nbf & radio_.nbf files from the c:\upgrade directory
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. Open a dos window and cd to c:\upgrade
5. Run alpine_ext_rom_tool.exe to extract the fat16 file and header, like this : alpine_ext_rom_tool.exe -d -n ms_.nbf
6. this creates ms_.fat and ms_.hdr
7. download and install "Extra Drive Creator Pro" from http://www.extradrivecreator.com/download/
8. In Extra Drive Creator add a "File to Drive" using the ms_.fat file in the c:\upgrade directory
9. Add/remove files cab files as needed
10. update the Config.txt file on the mapped drive, open it in a text editor and you'll notice it contains a list of cab files and the order to install them
11. delete the old ms_.nbf file in c:\upgrade
12. run the tool to create a new nbf file: alpine_ext_rom_tool.exe -e -f ms_.fat
13. make sure the ms_.nbf file has been created in c:\upgrade
14. run ROMUpgradeUt.exe to update the extended rom on your alpine!
Hope that helps
Bal
Hi there,
Do you know if there is an issue with the size of the files that are added to the extended ROM ie can you use the whole 24MB?
Using the SD card method with the ntrw.exe file, you are limited to 20.8MB otherwise you start have corrupt CAB files in your extended ROM.
Hi Pug,
alot of my understanding of the Alpine device is based on supposition and blind experimentation .... :shock:
But, from what I believe the extended rom nbf file to do; I reckon you can use the whole 24Mb to store cab files. Let me explain:
The length and structure of the so-called fat16 image that exists in the nbf file maps rather nicely to the rom structure of the Alpine (and I assume the same holds true of other 64rom devices) - see the following web page for what I mean http://wiki.xda-developers.com/index.php?pagename=AlpineRomStructure
If you take an extended rom nbf file and decode it, you end up with a file (excluding header) that is layed out as follows:
0x0000000 - 0x17FFFFF = extended rom fat16 image
0x1800000 - 0x187FFFF = 0xFF padding
0x1880000 - 0x18A57FF = Splash image in nb format
0x18A5800 - 0x18BFFFF = 0x00 padding
This is an exact match to the rom structure - so the so called fat16 image contains alot more than just the extended rom files!
Errrr, to get back to your point - I think you can fill the whole 24Mb with cab file; but best approach would be to try it ....
Bal
Pug,
just had a thought about what you said. The size of the fat16 image (as a whole) is 24Mb on the nose.
So with overhead of MBR, FAT tables, etc - you're probably looking at something like 23.7Mb of storage ....
Thought that's what you'd say so I'm experimenting now.
23.4MB didn't work so I'm trying to slim it down now. Shouldn't have to slim it down more than about 0.5MB so I'm reckoning that 23MB will be the limit.
Now I've put it on a diet I'm trying to find files to beef it up from 21.5MB, suprising how difficult that actually is.
Will let you know when I've found out.
For the record though.....YOU ROCK.
Why thank you
Let me know how it goes ... I'm trying to get some time to update the tool to extract and insert splash screens too - but I have some real work to do too!
Thought I'd try and help out a little here:
0x0000000 - 0x17FFFFF (Extended ROM Fat 16 image)
This is a size of 25,165,824 bytes (24Mb)
FAT tables are usually in 512 chunks and each 512 chunk gives you a pointer to 256 blocks of memory. The blocks are usually in 1,024 bytes (1Kb) though this can vary (in a full file system the blocks are usually much larger).
In a standard OS there are usually two FAT tables (as a backup system) so I will assume that there are two here also.
On top of this there will be at least one block taken up with the directory structure (more if you have subdirectories).
So if my numbers are close then you will need 96 * 2 512 byte FAT tables (This makes an overhead of 98,304 bytes).
On top of this there is 1,024 bytes for the root directory giving a total overhead of around 99,328 bytes.
This leaves you with 25,066,496 bytes for data (23.9 Mb).
You may lose an extra 512*32 (16,384) if there is an MBR on the front of this, though I would think that would be elsewhere.
The rest of the space you will lose through slack space (1,024 blocks that are not completely filled by the data you are using) so if you have a large number of files this theoretical 23.9Mb may drop significantly.
For instance, the Config file is probably around 600 bytes so you will lose the rest of the 1,024 block (424 bytes) as slack space.
If any of this helps you then great
Hope you have fun,
Graham.

The ExtRom Research thread (Trinity/Hermes, maybe others)

While cooking my german GPS rom I noticed that there is very little information about the ExtROM nb format. Right now we can't extract it, we can't rebuild it, we can't resize the partition.
So I figured it was time to put some research into the matter. I made a package that contains the following:
- 04_ExtROM.nb (from RUU_Trinity_HTC_GER_1.23.407.2_103_6275_1.38.00.11_108)
- extrom_dump.raw (a dump of the extrom area after flashing it)
- Content (content of the extrom, copied from device after unhiding)
The idea is to analyse how files are written from NB to flash and how they are stored inside the NB. The format should be identical with Hermes and maybe other devices.
The goals of this research are:
1) understanding the Extrom NB format
2) making an extraction tool for getting files out of extrom.nb files
3) making a rebuild tool that allows us to make custom extrom.nb files
4) Resizing the Extrom partition
Please post your findings in this thread, you can also contact me on IRC (#xda-devs on irc.freenode.net
Here's the file:
http://rapidshare.com/files/24740192/ExtromResearch.rar.html
Here's what I found out so far (only worked on it for a few minutes):
R1:
The Extrom nb seems to hold 7 versions of each file, probably for 7 different languages. Search for PP_AKv33-DefaultPage_ and you'll find:
PP_AKv33-DefaultPage_FIN-040b.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_RUS-0419.CAB
PP_AKv33-DefaultPage_FRA-040c.CAB
PP_AKv33-DefaultPage_GER-0407.CAB
PP_AKv33-DefaultPage_FIN-040b.CAB
Those occur in the 7 different config.txt files. Maybe those cabs are not all really in the NB, at the very least they must be very similar. Otherwise it wouldn't be so easy to compress. I found 7 occurences of several cab files in the NB by searching for the first few bytes of them.
R2:
The raw dump does not contain the config.txt files (at least I couldn't find them). Maybe config.txt gets stored elsewhere. I also didn't find the cabs in the dump so far, maybe a different format or a bad dump.
I had used
pdocread.exe -w -d EXT_FLA -p Part00 0 0xa00000 extrom.raw
R3: Only one of the 7 files in NB actually is actually in the ExtROM content.
My conclusion from R1 and R3:
The extrom.nb holds information for different languages or OS versions. Depending on some information only one of those actually gets flashed.
I'm finding it strange that the extracted ext_rom and the dumped ext_rom haven't the same structure.
I own a wizard (Qtek9100) and using Typho5 to extract it from the RUU and using podcread to dump it from the phone i always get a FAT16 image file. I can then use a program like Winimage to browse and edit it as i like.
Are you sure the extracted ext_rom is correct?
I believe I did everything correctly, yes.
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.
ZakMcRofl said:
I believe I did everything correctly, yes.
Click to expand...
Click to collapse
If you remove the first 0x1040 bytes from the nb file you get something looking like a FAT16 image, but still not working correctly. I wonder if the nbh decoder by itsme as a bug that produces a corrupted extension_rom?
ZakMcRofl said:
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
Click to expand...
Click to collapse
I did I downloaded your dump and used Winimage to check the raw file and it showed an empty confused FAT16 image
ZakMcRofl said:
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.
Click to expand...
Click to collapse
Winimage allows it. There's a tutorial by Faria on how to cook ext_roms and flash it back to wizards and winimage is advised
cheers
This post says otherwise (regarding TFAT16, not FAT16)
The simpliest method.
1. Take MS_.NBA (a decrypted version of MS_.NBF). Open it in any hex editor, and search for bytes "EB FE 90 4D 53 57 49 4E 34 2E 31 00" ("ыРMSWIN4.1", there would be "FAT16" string a bit lower). The string should be found near offset 0x70000. Extract everything starting from the place you've found and up to the end of file to a file named "extrom.img"
2. Open "extrom.img" in WinImage, edit it as you like, save the file
3. Open the hex aditor and place modified "extrom.img" to the same place in MS.NBA file where it was before extraction.
that's all. Convert NBF to NBA and flash your ROM.
The same method cannot be used on Universal. It has TFAT16 instead of FAT16, WinImage knows nothing about TFAT and destroys FAT table. But there is a simple workaround.
Click to expand...
Click to collapse
Source: http://forum.xda-developers.com/showpost.php?p=847312&postcount=10
Well, winimage works perfectly with wizard nb files (decrypted nbf files)
Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.
ZakMcRofl said:
Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.
Click to expand...
Click to collapse
Maybe that's why Wizard's extended roms get corrupted when users try to delete files in it. Perhaps WM5 or WM6 use TFAT16 upon rebooting and it
screws up the reading
Filelist
I took the content files and searched for their occurrences in extrom.nb.
Here is the filelist with hex positions:
Code:
0x0000A280 BT_Table.CAB
0x0001F3B0 Config.txt (FIN)
0x00020A08 HTC_WM5DST_signed.cab
0x000485D0 MP_CVSDcpl_20060920.cab
0x000685B0 PP_AKv30-DefaultPage_ALL.CAB
0x0007DCF8 PP_AKv33-DefaultPage_???.CAB
0x00093850 PP_ExtVersion.xml
0x000956C8 PP_FixITS2654_SMD.CAB
0x000A2800 BT_Table.CAB
0x000B7930 Config.txt (WWE)
0x000B8F88 HTC_WM5DST_signed.cab
0x000E0B50 MP_CVSDcpl_20060920.cab
0x00100B30 PP_AKv30-DefaultPage_ALL.CAB
0x0012B7B8 PP_ExtVersion.xml
0x0012D630 PP_FixITS2654_SMD.CAB
0x0013A768 BT_Table.CAB
0x0014F898 Config.txt (WWE)
0x00150EF0 HTC_WM5DST_signed.cab
0x00178AB8 MP_CVSDcpl_20060920.cab
0x00198A98 PP_AKv30-DefaultPage_ALL.CAB
0x001C3720 PP_ExtVersion.xml
0x001C5598 PP_FixITS2654_SMD.CAB
0x001D26D0 BT_Table.CAB
0x001E7800 Config.txt (RUS)
0x001E8E58 HTC_WM5DST_signed.cab
0x00210A20 MP_CVSDcpl_20060920.cab
0x00230A00 PP_AKv30-DefaultPage_ALL.CAB
0x00246148 PP_AKv33-DefaultPage_???.CAB
0x0025BCA0 PP_ExtVersion.xml
0x0025DB18 PP_FixITS2654_SMD.CAB
0x0026AC50 BT_Table.CAB
0x0027FD80 Config.txt (FRA)
0x002813D8 HTC_WM5DST_signed.cab
0x002A8FA0 MP_CVSDcpl_20060920.cab
0x002C8F80 PP_AKv30-DefaultPage_ALL.CAB
0x002DE6C8 PP_AKv33-DefaultPage_???.CAB
0x002F4220 PP_ExtVersion.xml
0x002F6098 PP_FixITS2654_SMD.CAB
0x003031D0 BT_Table.CAB
0x00318300 Config.txt (GER)
0x00319958 HTC_WM5DST_signed.cab
0x00341520 MP_CVSDcpl_20060920.cab
0x00361500 PP_AKv30-DefaultPage_ALL.CAB
0x00376C48 PP_AKv33-DefaultPage_GER-0407.CAB
0x0038C7A0 PP_ExtVersion.xml
0x0038E618 PP_FixITS2654_SMD.CAB
0x0050DE80 MP_CVSDcpl_20060920.cab
0x00527EE8 Config.txt (FIN)
0x005282F8 HTC_WM5DST_signed.cab
0x005C9298 PP_AKv30-DefaultPage_ALL.CAB
0x005DE9E0 PP_AKv33-DefaultPage_???CAB
0x005F4538 PP_ExtVersion.xml
0x005F63B0 PP_FixITS2654_SMD.CAB
R5: Files are stored sequentially for each language.
I haven't found where the offsets and how the offsets are stored, maybe relative to the beginning of a language section. I haven't found the absolute offsets anywhere yet.

HTC Extended ROM image editor

TFAT Image Editor 1.2.0.14
==================================================
A utility to editing Extended_ROM.NBs files.
May be especially useful for use with (T)FAT filesytems image files.
==================================================
Operating systems supported:
- Windows 2000/XP/Vista
Features:
- Create an Extended_ROM image file. Support: Artemis, Athena, Elf, Gene, Herald, Hermes, Titan, Trinity.
- Extract file(s) from the image.
- Write file(s) into an existing image file.
- AutoConfig function.
- Support TFAT 12, TFAT 16 filesytems. 512 - 4096 sector size.
Fantastic Tool. The first which combines Opening,Modifying,Saving the ExtRom.nb files
And
the Only which is auto config maker.
Many many congrs and applauses...!!!!
Wow! Thank you for making this, i was about to give up on hoping for extrom tools now that new devices aren't using it at all. This did open up the extrom for my Titan though, so good work!
I may be missing something simple: How do you get it to open the ext rom on/for your Titan?
AnDim said:
TFAT Image Editor 1.2.0.14
(c) 2007-2008 AnDim
==================================================
A utility to editing Extended_ROM.NBs files.
May be especially useful for use with (T)FAT filesytems image files.
==================================================
Operating systems supported:
- Windows 2000/XP/Vista
Features:
- Create an Extended_ROM image file. Support: Artemis, Athena, Elf, Gene, Herald, Hermes, Titan, Trinity.
- Extract file(s) from the image.
- Write file(s) into an existing image file.
- AutoConfig function.
- Support TFAT 12, TFAT 16 filesytems. 512, 1024, 2048, 4096 sector size.
Click to expand...
Click to collapse
Is the ElfIN also supported?
AnDim said:
TFAT Image Editor 1.2.0.14
(c) 2007-2008 AnDim
==================================================
A utility to editing Extended_ROM.NBs files.
May be especially useful for use with (T)FAT filesytems image files.
==================================================
Operating systems supported:
- Windows 2000/XP/Vista
Features:
- Create an Extended_ROM image file. Support: Artemis, Athena, Elf, Gene, Herald, Hermes, Titan, Trinity.
- Extract file(s) from the image.
- Write file(s) into an existing image file.
- AutoConfig function.
- Support TFAT 12, TFAT 16 filesytems. 512, 1024, 2048, 4096 sector size.
Click to expand...
Click to collapse
Great proggy !! I' m truly appreciated
and if i have a ROM with 2 files? how can i use this tool to add some cabs? the files are: RUU_signed.nbh and RUUWrapper.exe
ady_uaic said:
and if i have a ROM with 2 files? how can i use this tool to add some cabs? the files are: RUU_signed.nbh and RUUWrapper.exe
Click to expand...
Click to collapse
right
me too
One of a few tools out there to extract the extended rom .nb file from .nbh
http://forum.xda-developers.com/showthread.php?t=289830
There's a gui one around too, just search.
ok, i saw that tool, but i was wondering, with this one, what can we do exactly?
I'm looking for this very long time .now i found it.thank you
you`re so handsome!
How about having the ability to create the image in the size that you want while keeping to its TFAT16 format? I tried using Winimage to do that, but while resizing, it changes the format.
ivanmmj said:
...keeping to its TFAT16 format?
Click to expand...
Click to collapse
For what?
AnDim
AnDim said:
For what?
AnDim
Click to expand...
Click to collapse
The Herald requires a TFAT16. The only software that I have that can change the size of the ExtROM is Winimage and that reformats the image to TFAT12 or FAT16 (not TFAT16) if I change the image size. I'm trying to do something that Artemis users can already do, gained unused space from the extrom and putting it into the main storage. I don't know if it's possible, but I'd love to try.
ivanmmj said:
The Herald requires a TFAT16.
Click to expand...
Click to collapse
It is exact?
My Trinity reads any format (TFAT16, TFAT12).
Theoretically, the minimal size of the TFAT16 for Herald is 2Mb.
If it is necessary it is less, only TFAT12.
Well, I've tried with TFAT12 but it always fails with a corrupt image error. I figured that it's probably an issue with it reading TFAT12. Could be that the device maybe requires TFAT16 or maybe it just requires a 10mb file...
So how could I built a 2mb TFAT16 extROM?
Great tool! AnDim, can u update it to recognize TFAT32 format? 3Q ,the ext rom of Samsung Omina 2 ,I8000 is TFAT32, so i'll need it.

[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.
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):
Code:
[HKEY_LOCAL_MACHINE\System\Loader\ModuleInfo]
[HKEY_LOCAL_MACHINE\System\Loader\ModuleInfo\dllname.dll]
"filename.exe"=dword:1
"filename2.exe"=dword:1
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)
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:
Code:
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start]
Create a sub-key matching the folder name or shortcut name the icon will go with, for example:
Code:
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Phone.lnk]
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Tools]
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Tools\QuickGPS.lnk]
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Google Maps.lnk]
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:
Code:
[HKEY_LOCAL_MACHINE\ControlPanel\Owner]
[HKEY_LOCAL_MACHINE\ControlPanel\Buttons]
[HKEY_LOCAL_MACHINE\ControlPanel\Input]
* Allow in call recording with the native dialer
Code:
[HKEY_LOCAL_MACHINE\System\AudioRecording]
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\Software\Microsoft\Voice]
"EnableCallRecordMenuItem"=dword:00000001
"AllowInCallRecording"=dword:00000001
* Disable built-in magnifier on double-tap
Code:
[HKEY_LOCAL_MACHINE\System\GWE\MAGNIFIER]
"Enable"=dword:0
* Override default Lock Screen notification launchers
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\LockScreen\Notifications\Email]
"Application Command Line"="\Program Files\OEMApp\OEMApp.exe"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\LockScreen\Notifications\SMS]
"Application Command Line"="\Program Files\OEMApp\OEMApp.exe"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\LockScreen\Notifications\Voicemail]
"Application Command Line"="\Program Files\OEMApp\OEMApp.exe"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\LockScreen\Notifications\MissedCall]
"Application Command Line"="\Program Files\OEMApp\OEMApp.exe"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\LockScreen\Notifications\Contacts]
"Application Command Line"="\Program Files\OEMApp\OEMApp.exe"
* Porting languages in Ervius Visual Kitchen using the posted language packs
First, a quick overview of the relevant file structure in VK:
Code:
\Erv\OEM\[i]%DEVICENAME%[/i]\[i]%LOCALE_ID%[/i]\OEM_Lang_[i]%LOCALE_ID%[/i]
\Erv\ROM\[i]%DEVICENAME%[/i]\[i]%BUILDNUMBER%[/i]\OEMXIPKernel
\Erv\SYS\[i]%BUILDNUMBER%[/i]\DPI_[i]%DPI%[/i]\[i]%LOCALE_ID%[/i]
\Erv\SYS\[i]%BUILDNUMBER%[/i]\DPI_[i]%DPI%[/i]_resh_[i]%RESH%[/i]_resv_[i]%RESV%[/i]\[i]%LOCALE_ID%[/i]
\Erv\SYS\[i]%BUILDNUMBER%[/i]\SHARED\[i]%LOCALE_ID%[/i]
Code:
Possible values for the [i]%VARIABLES%[/i] above:
[i]%DEVICENAME%[/i]: Name of your device (Hermes, Raphael, Diamond, etc.)
[i]%LOCALE_ID%[/i]: The 4 digit number matching your locale (list of supported id's found in first post) - a full list can be found [url=http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx]here.[/url] It is possible to port WM to a language that is not supported, you would have to use a PE Resource editing program to translate all the various strings found in the [b].mui[/b] (Multilingual User Interface) files. Note that these change periodically as the builds get updated so you would also need to update your altered .mui's.
[i]%BUILDNUMBER%[/i]: The build version in use (23022 for example)
[i]%DPI%[/i]: DPI of the device (92, 128, 192)
[i]%RESH%[/i]: Horizontal resolution of the device, in pixels (portrait)
[i]%RESV%[/i]: Vertical resolution of the device, in pixels (portrait)
* Porting \SYS
The first thing you would want to do is grab the language pack matching your language. Extract it and you'll have several folders inside. Essentially what you want to do, is grab the folders that match your target device for the variables above, and copy those into the kitchen, in their respective folders.
As an example, if you were porting to Italian, on a 96 DPI, 240 by 320 device, and you had the following folder:
Base_Lang_%LOCALE_ID%_DPI_%DPI%_RESH_%RESH%_RESV_%RESV%
Base_Lang_0410_DPI_96_RESH_240_RESV_320
and place it in:
\Erv\SYS\%BUILDNUMBER%\DPI_%DPI%_resh_%RESH%_resv_%RESV%\%LOCALE_ID%
\Erv\SYS\23022\DPI_96_resh_240_resv_320\0410
Go through each of the folders in the language pack and match it up with a destination folder this way. Compare to the existing 0409 layout to help with the structure. Note that there will be some files you are not going to use (you won't use 96 or 128 dpi files on a 192 dpi device, for example)
Once you have completed matching up each applicable folder in the language pack to a destination in \SYS this way, you're complete with that folder.
* Porting \ROM
The relevant folder here is \Erv\ROM\%DEVICENAME%\%BUILDNUMBER%\OEMXipKernel - inside you want to edit boot.rgu. The relevant keys to edit are:
Code:
[HKEY_LOCAL_MACHINE\MUI]
"SysLang"=dword:[i]%LOCALE_ID%[/i]
[HKEY_CURRENT_USER\MUI]
"CurLang"=dword:[i]%LOCALE_ID%[/i]
NOTE: For anyone not using Ervius VK, you will need to compile boot.rgu to boot.hv when done. Use the HV Tools.zip attached to this thread for that. For anyone using Ervius VK, this is automatically compiled into boot.hv during cooking, and no further action is required.
* Porting \OEM
The relevant folder here is \Erv\OEM\%DEVICENAME%\%LOCALE_ID%\OEM_Lang_%LOCALE_ID% - you need an initflashfiles.dat that matches your language. All the folder names inside here will need to be translated to your language. I will try and make translated initflashfiles.dat for each language available soon.
You will also need to translate any other language-specific packages in \OEM and \EXT. If you don't want to bother translating the 3rd party apps, you can simply rename their .mui files to match your %LOCALE_ID%. The programs will work, but remain in their original language. You can translate these with a PE Resource editing program if you cannot find programs in your local language.
* Package Descriptions
*note: in the case of *Modules vs. *Files, the difference is simply what area of memory these objects go to when loaded (FILES or MODULES section) - other than that, no difference. Essentially, if you're using a native 6.5 kernel, you want *Modules, otherwise not.
ADC - Automatic Data Configuration
AdobeFlash - Adobe Flash
AdobeFlashCodecs - Adobe Flash Video Playback Codecs
AlarmSounds - Alarm Sounds
AUTOUPDATE - Device-Side Auto Update - Not Required
Base - Required - but what is it?
BaseApps - Required - but what is it?
BaseAppsFiles - Microsoft Camera + Camera Integration Support - replaces BaseAppsModules
BaseAppsModules - Microsoft Camera + Camera Integration Support -replaces BaseAppsFiles
Bluetooth - Bluetooth Support (for microsoft BT stack, dependant on build-time switch)
bronze - Required - Components for CHome
BronzeAH - Components for CHome (Arabic language)
BronzeEA - Components for CHome (east-asia languages)
BronzeNonEA - Components for CHome (Non east-asia languages)
BROWSING - IE 5 Components
BROWSINGCORE - IE 6on6 Scripting Components (dependant on build-time switch)
browsingie - IE 6on6 UI and RenderCore (dependant on build-time switch)
BTDUN - Bluetooth dial-up networking
Bth_A2DP - Bluetooth A2DP
Bth_HID - Bluetooth HID (Human Interface Device) profile support
Bth_Watch - Support for the Sony Erricssion Wrist Watch
CHome - Titanium, the WM Pro version of Sliding Panels
CommonEA - Common settings specific to east asia builds, replaces CommonNonEA
CommonNonEA - Common settings specific to non-east asia builds, replaces CommonEA
COMPLEXSCRIPT_FONTS - System fonts for Arabic builds, replaces SYSTEM_DEFAULT_FONTS
ConfettiCore - HW Accelerated RenderCore for 6.5 Chrome
DRM - Digital Rights Management Support (dependant on build-time switch) - Required for Video playback of 3gp and mp4
Enterprise - IPSec, l2TP and Winscard support?
Entertainment - Games
FWUPDATE - ImageUpdate Support
gb18030 - East Asian Font support - Excluded from non-EA images
GPSID - GPS Intermediate Driver, facilitates multiple applications using one serial port simultaneously
INTERNETSHARING - Provides a NAT Router for WWAN <--> USB/Bluetooth communication
IPSECVPN - IPSec VPN Support
IRDA - IR Port Support
LangDB - wince.nls for your language (0404, 0411, 0412, 0804, WWE)
Livesearch - Windows Live Search/Bing Search
Lockscreen - WM6.5 Lockscreen
LockscreenEA - Lockscreen east-asia components - replaces LockscreenNonEA
LockscreenNonEA - Lockscreen Non east-asia components - replaces LockscreenEA
MediaOS - Windows Media Player - Needed for MP3 Ringtone support?
MediaOSFiles - Windows Mobile Player Decoder DMO - replaces MediaOSModules
MediaOSModules - Windows Mobile Player Decoder DMO - replaces MediaOSFiles
Metadata - Required - Registry Hives, Package Info
MODEMLINK - Old-style internet sharing support (DUN) (dependant on build-time switch)
MSIMAR - SIP support for Arabic builds - excluded from non-arabic builds
MSTag - Microsoft Tag Reader (dependant on build-time switch)
MSXIPKernel - Microsoft Native Kernel Components
MSXIPKernelLTK - Empty ImageUpdate Package - Requirement for future expansion
NetCF - Microsoft .NET Compact Framework
NonPhone - Non-Phone (PDA) Components - excluded from phone builds
OEMXIPKernel - OEM Native Kernel Components
Office - Microsoft Office 6 Mobile
OneNote - Microsoft OneNote 6 Mobile
OS - Required - Description?
OSFiles - Required - MS WMV DMO - replaces OSModules
OSModules - Required - MS WMV DMO - replaces OSFiles
Perf - Debug Performance Monitor
Perfbox - Debug Performance Monitor
Phone - Required - Phone support, not in PDA builds
PhoneRedist - Required - Phone support, not in PDA builds
ppgprov - OMA Provisioning Support, not in PDA builds
Redist - ?
RemoteDesktopMobile - Remote Desktop
Riched20 - Rich HTML Editor support - WWE builds - replaces Riched20_CS
Riched20_CS - Rich HTML Editor support - Arabic builds - replaces Riched20
RIL710MUX - CellCore Component (optional)
RingsAndAlerts - Rings and Alerts
RMGR - Roaming Manager (optional)
RUNTIMES - C Runtimes
SipAR - SIP Support for Arabic builds (excluded from non-arabic builds)
SampleMusic - Sample Music (dependant on build-time switch)
Shell - Required
SIM_TKit - SIM Tool Kit, omitted from CDMA builds
Skybox - Microsoft MyPhone, Syncs a phone's info with Microsoft (dependant on build-time switch)
Skymarket - WM MarketPlace isn't live yet - Just a link (dependant on build-time switch)
SMIME - Required - Crypto Support
SMS_Providers - Required - SMS Support
SQLCE - SQL Server for CE (dependant on build-time switch)
SQM - Systems Quality Metrics (customer experience feedback)
SqlCeMobile - Not Required - Unless you need SqlCeMobile
SYSTEM_DEFAULT_FONTS - Required - Non Complex-Script Font Support - replaces COMPLEXSCRIPT_FONTS
Themes - Extra Themes
Transcriber - Transcriber - Not available in every language
UNISCRIBE - SIP Support for select non-WWE langs - replaces Transcriber
VoiceCommand - Voice Command - (0407, 0409, 040C, 0809)
VoIP - VoIP
VoIPOS - VoIP Part 2
Webview - IE 6on6 RenderCore component for OS use, WWE - replaces Webview_CS
Webview_CS - IE 6on6 RenderCore component for OS use, arabic - replaces Webview
WelcomeCenter - The WM6.5 Welcome Center - Required for "Help"
WindowsLive - Windows Live Mobile
WindowsLiveIM - Windows Live Instant Messaging
WMLiveSearchWidget - MS Live Search Widget
WMMoneyWidget - MS Money Widget
WMWeatherWidget - MS Weather Widget
WMWidgets - MS Widgets Support (Requires IE 6on6)
WWAN - WWAN Support (not in PDA Builds)
Branches of WM Development: Here is what all these different version numbers relate to, and a summary of their features.
212xx = AKU1, all builds leading up to and including WM 6.5
213xx = MOT motorola
214xx = ???
215xx = SAM samsung
216xx = HTC htc
217xx = COM1, continuing dev of 6.5.0.1 - 6.5.0.40
218xx = COM2, continuing dev of 6.5.0.50
219xx = MD, feature test branch, pretty much dead now. (unstable features are added here, this tree is based on COM1, so older base OS code, but the UI/UX code is newer)
22xxx = SEMC sony ericsson
*230xx = COM3, continuing development
*234xx = COM4, appears to be abandoned.
*235xx = COM5, more GUI changes here. New Outlook Interface.
*236xx = LG Electronics Branch
*24xxx = Possible HTC branch
*25xxx = SEMC - Sony Ericsson
*280xx, 282xx = WMD. This is a continuation of com3 from 23090. Most of the changes appear to be with IE
235xx is the only branch that has threaded email natively
Thanks to a1d2catz and Cotulla.
Post or PM DaveShaw (or any other mod on this thread) with updates
OK, So since I got a post on the first page I suppose I could keep some useful info here from the thread as well. Just in case someone missed it With every new build comes a new issue, so post your fixes if you have them.
- Here are some helpful programs. First is an awesome ROM Sorting tool. This this is awesome for organizong SYS and it cleans up unwanted files left in module folders. Link HERE
- And second is just a plug for my FlashBack package which you can use to backup and restore(automatically) lots of personal info and program settings Can also set manila to load automatically if you prefer it to "Windows Default", and choice to autorestore or not within program. Saves me a lot of setup time. After a flash all I need to do is restore contacts. Check it out and offer suggestions HERE
-Alter shellres.xx.dll to work with new Toolbar zoom in 23028 build. Video HERE
-Add your own shortcuts and icons to settings items. Post HERE and HERE
-A tool to remove duplicate files from modules. Post HERE
-Editing .tsk file for use in 23025+ builds. For adding Pivot images and Toolbar images. Post HERE
Some more registry keys. If anyone has details on what these do please post.
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\ConfettiPlus]
"EnableStatsCaption"=dword:00000001
"ForceUpdateOverlay"=dword:00000001
"FrameRateCap"=dword:00000100
"UseGDI"=dword:00000001
Transparent quickmenu for HTC taskmanager(for use with 2302x builds)
Code:
[HKEY_CURRENT_USER\Software\HTC\TaskManager]
"LauncherUp"=hex:\
20,00,00,00,01,00,00,00,07,00,00,00,70,00,00,00,0f,00,00,00,0f,00,00,00,\
0f,00,00,00,0f,00,00,00,0e,00,00,00,0e,00,00,00,0e,00,00,00,0e,00,00,00,\
0d,00,00,00,0d,00,00,00,0d,00,00,00,0d,00,00,00,0c,00,00,00,0c,00,00,00,\
0c,00,00,00,0c,00,00,00,0b,00,00,00,0b,00,00,00,0b,00,00,00,0b,00,00,00,\
0a,00,00,00,0a,00,00,00,0a,00,00,00,0a,00,00,00,09,00,00,00,09,00,00,00,\
09,00,00,00,09,00,00,00,08,00,00,00,08,00,00,00,08,00,00,00,08,00,00,00
"LauncherDown"=hex:\
20,00,00,00,01,00,00,00,07,00,00,00,70,00,00,00,0f,00,00,00,0f,00,00,00,\
0f,00,00,00,0f,00,00,00,0e,00,00,00,0e,00,00,00,0e,00,00,00,0e,00,00,00,\
0d,00,00,00,0d,00,00,00,0d,00,00,00,0d,00,00,00,0c,00,00,00,0c,00,00,00,\
0c,00,00,00,0c,00,00,00,0b,00,00,00,0b,00,00,00,0b,00,00,00,0b,00,00,00,\
0a,00,00,00,0a,00,00,00,0a,00,00,00,0a,00,00,00,09,00,00,00,09,00,00,00,\
09,00,00,00,09,00,00,00,08,00,00,00,08,00,00,00,08,00,00,00,08,00,00,00
Great work Da_G as always. I think most people will be happy with the SYS and XIP. That is all I use, and there are so many cooks which are providing ROM's that you should use your time wisely.
On another note I we all should help to contribute to this thread. I know there are others out there with resources to new ROM's, I hope they will be as giving and share as Da_G has.
Thanks again and I will bookmark this thread and follow for new releases of SYS\XIP.
Anyone got the 23019 that ConFlipper mentioned - or was he just toying with us
DT
Da_G can I use the Portuguese language packages from 23001 in the 23016/21935?
Oh noes! I forgot the pizza party posts
@Z7Z:
This should work fine for 23016, but not for 21935. I hope to have a new version to post soon, I will try and post all langs for it
Da_G, my phone came with Wm 6.0. Now i am using 6.1/6.5. I have managed to insert initvmmap.exe and mencflt.dll into my xip, as these files have been added/replaced in the 6.1 and 6.5 xip. Now, i have also inserted required registry entries into boot.rgu in xip.bin, but i dont know how to add the entries in boot.hv. Is it necessary to do so? and if yes, then how?
krazy_about_technology said:
Da_G, my phone came with Wm 6.0. Now i am using 6.1/6.5. I have managed to insert initvmmap.exe and mencflt.dll into my xip, as these files have been added/replaced in the 6.1 and 6.5 xip. Now, i have also inserted required registry entries into boot.rgu in xip.bin, but i dont know how to add the entries in boot.hv. Is it necessary to do so? and if yes, then how?
Click to expand...
Click to collapse
it depends on kitchen
PRB kitchen creates new boot.hv
older kitchen that are using xip.bin u have to compile boot.rgu to boot.hv with HV TOOLS
Thanks a lot for the tools buddy I am using platform rebuilder based kitchen, do i need it?
krazy_about_technology said:
Thanks a lot for the tools buddy I am using platform rebuilder based kitchen, do i need it?
Click to expand...
Click to collapse
no PRB will create new
MMM
I cook with the old kitchenn, based on bepe's kitchen 'buildos.exe".
If i do some tweaks on my XIP and on my boot.rgu, if i understand, i need to compile my new boot.hv with my modded boot.rgu ?
It's right ?
Thanks a lot
Hey!
Hey Da_G now i need to unsuscribe the other and add this
How is the new tools IMGFSfrom and to... development? Hope GREAT!!!
Keep it up man... God bless friends.
Haven't started on the IMGFS part of it yet, still learning some bits of C++ i'll need to create that... but nd4spd has posted a modded set of IMGFS tools here which should work good until i'm done (although the free space in each partition is hardcoded for the moment): http://forum.xda-developers.com/showpost.php?p=4186647&postcount=237
I'm probably a week or so off from posting the first test version (i'll do that in another thread) of the replacement for NBSplit/NBMerge/IMGFSFromNB/IMGFSToNB.
@Nixeus: Yes, when using the older kitchen you need to use program "rgucomp -b" with boot.rgu in same folder, it will compile boot.rgu to boot.hv Then just replace boot.rgu and boot.hv in your OEMXIPKernel. In the old kitchen to do this you'll need to dump xip.bin, replace the .hv, then rebuild xip.bin. XIPPort.exe can do this fairly easily.
Da_G said:
Registry tips for WM 6.5
To change start menu positions
Code:
[HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Tools]
Click to expand...
Click to collapse
I don't have the "tools" key in my registry. I could obviously create it, but what would the string or dword values be?
Under HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start, I see all my shortcurs with different ranks, so is that what you mean -- just change the rank?
Only one Question. Is the voicemailbox-tab working with 23017 ?
Or with the 23xxx tree generally ? .... I never saw a notification there ... number was configured.
Is there a reg-key to get it working ?

Categories

Resources