config.txt - autorun or RunCC - customization - Windows Mobile Development and Hacking General

config.txt - autorun or RunCC - customization - Windows Mobile Development and Hacking General

tighter specifications for config.txt and other customizing files
big sorrow, my huge and complicated customization failed on new rom.
after a dozen reflashing I finally located problem.
IN NEW ROMs, there is "RunCC" app which completely replaces "autorun" (autorun.exe and associates are not present)
- "RunCC" is by default using script files, with the same names as were in ROMs customized by "autorun" (config_operator.txt, config.txt...)
- commands used in script files in "RunCC" are compatible with commands from "autorun", but many are not supported, look below
why we need customization on the first place?
- as our custom roms are already customized of course, we don't need it for the same reason as it was meant to be used,
but as customization is executed right after initialization of a new rom, and before any of other startup apps or today screen plugins that's making it a good tool for running little scripts with user choices, or programs registering scripts, or registry, notification, file changes.
advantages of RunCC:
- more flexible for operators, OEM companies, and parties doing customization
if there is bug in one of script txt files, (or it's missing) customization will continue with next file
every operator has assigned it's config*.txt file, now if one have bug, other would still run
- change priority for executing script files
- can execute config*.txt files from SD cards without custom made sdAutoRun.exe
* well, except the option of running SD configs, there's isn't much advantage in all this for us cooks, as there is only one customizer-the cooker
disadvantages:
- not supporting HIDE: and LOCK: commands - not possible to use with user-input type customizing apps
- can't redirect script files to each other (command CFG
files to be run are defined in special file (with kind of basic C++ commands): RunCC.lua
this could lead to possible conflict with creating file of the same name + troubles if someone like me is trying to use his own config_papo.txt script file, like he was used to. This leads to personal damage in wasted time, electrons and burned out nerve cells
==================================================
scheme as scripts are usually executed by "autorun" customization:
[HKEY_LOCAL_MACHINE\COMM]
"AutoRunCFG"="\\Windows\\<config>.txt"
* not applicable with RunCC
|
v
config_operator.txt
|
v
config_PT.txt
|
v
config_AP.txt
|
v
config_end.txt
|
v
config.txt
last line in every file have to contain "CFG: \windows\<next_cfg_file>.txt
last one should contain:
LOCKisabled
RST: Reset
* disabling lock on end should make next start complete (without need to start by clicking on start)
==================================================
by "RunCC" customization:
RunCC.lua file: defines all possible script (config*.txt) files, and priorities of excuting with parameter:
RunDefault, RunExtra, RunCustomer (I didn't check on the order, I suppose 'RunDefault' is first)
by default, all script files, as you can see them above are defined, if you use any of them, your commands will be executed, if you use file with different name it won't even if you try to redirect by CFG: command (need to edit RunCC.lua)
CFG:, LOCK:, HIDE: is ignored with RunCC
==========================================
commands:
LOCKisabled -- enable user input (it's semicolon followed by big D letter of course. don't put smilie there like it's shown here)
LOCK:Enabled -- disable user input
HIDE:Enabled -- hides windows logo, background process could be seen HIDEisabled -- covers it back
* if only HIDE:Enabled, status will still not show running program name - if you running scripts which calls on app names, you need LOCKisabled too for them to work
* HIDE: pair (maybe LOCK as well) can't be used twice in one txt file (process would stop)
* LOCK & HIDE don't work with the new autorun
CAB: \windows\... --- install CAB
EXEC:\windows\... --- exe file
XML: \windows\... --- provisioning XML file
CFG: \Storage\Config2.txt --- continue with another autorun, txt file. need to be specified on the last line
TSK: \Windows\... --- theme tsk (not working in all versions of "autorun", not with RunCC)
FILEOP:\windows\... --- New format for file operations files (it's possible it only works with RunCC)
CPY1:\windows\source --- copy (source file)
CPY2:\windows\folder\target --- copy (target file)
RST: Reset --- perform reset
SHOW:\windows\... --- shows custom image file during process. Must be BMP
* note that three letter commands have space after semicolon, in new version of autorun it's not needed, but why not rather using it.
* first file (usually config_operator.txt) is unicode, the rest of it is usually ansi, but could be unicode as well.
* common mistake is using parameters - NOT ALLOWED
* spaces - SDAutorun can handle them (I didn't test for "autorun")
if you need parameters, call mortscript's renamed autorun.exe file which would call the same named script where you could put RUN command with program name and parameters
---
SDAutorun:
you can continue, on SD card having your cab files there to be installed after flashing someone's custom ROM, his ROM has to be "comatible". That is done by adding "sdautorun.exe" and command EXEC:\windows\sdautorun.exe in script file.
(search for sdautorun)
==================
My conclusion is, we don't need RunCC and we want back our old good "autorun"
1. disable RunCC ext package
2. download "autorun" attached to this post. it consist of three EXTs. include all three of them
3. in "Autorun" EXT I added reg entry to disable "RunCC" as this is being run in "init" section which is organized with chaotic style by assigning random numbers 1-100 to each app and hoping to not hit the same twice, you need to check with your rom if RunCC has the same as in my case: 58
if you don't remove entry to run "RunCC", nothing wrong would happen, it's just not healthy in general to have shortcuts to nonexistend exes to be run every start.
I am working on the attachment. will add it later today/tomorrow

Interesting info thanks could you please upload some examples as this is all new to me
Many thanks [email protected]

sure, still trying to get more from it. then I'll upload that substitutive autorun I promised before.
examples.. you can find it in your phone, search config*.txt files in windows folder
or for runCC the file: runcc.lua - windows folder or
in OEM - ControlBlock

Related

mousio's AutoRun

[ Based on plenTpak's already great AutoInstall4 (2008/03/28) ]
The scripts included here require MortScript and are intended to help automatically install and configure software, copy files and folders, and import registry and provisioning stuff - this all with little or no user interaction!
So should you need to install a new ROM or install new software versions, just go ahead and let User Customization take care of the rest...
Usage:
Unpack SDConfig.txt and scripts to storage card (and review them )
Dump any install files (silently installable only!), script files (e.g. to process the interactive install files, see further), registry files, provisioning files, and files and folders to copy, into the AutoRun subfolder.
Hard-reset, or start the RunAutoRun script
Hope this makes things easier for some people!
By default, it uses this file structure:
Code:
_ Storage Card\
|_ SDConfig.txt
|_ SDConfig\
|_ <MortScript cab>
|_ AutoWait.mscr
|_ AutoRun.mscr
|_ AutoRun\
|_ <your stuff here>
I rarely need to change my SDConfig file anymore and I just drop all of my AutoRun stuff (cab/mscr/zip/reg/xml files and also regular files and folders) in the dedicated AutoRun folder, it's that easy!
The AutoRun folder may contain any or all of the following:
cab files to install silently and mscr scripts to run,
regular files/folders to copy,
zip archives to unpack,
reg files to import,
xml files to concatenate.
All is processed (and logged!) in the same order as listed above, with all items sorted alphabetically first.
After installing, files are copied/unpacked, then registry files are imported, and finally the xml files are concatenated into a single provisioning file that is called by SDConfig.txt.
Here are some important notes for each item:
I use scripts to install the more interactive cabs: e.g. instead of putting Fringcab.cab here, I put a Fringcab.mscr here, and move Fringcab.cab elsewhere (i.e. a sibling folder called "Interactive"); my Fringcab.mscr installs Fringcab.cab but then also takes care of the interactive installation part of it.
The "regular" files are files that do not fit the other categories (cab/mscr/zip/reg/xml); regular files/folders found here will be xcopied to the root folder on the device (creating folder structure if necessary) - quite like plenTpak explained here.
Zip archives are unpacked to the root folder on the device (creating folder structure if necessary); zip archives are smaller to store, but unpacking is less tolerant than xcopying when it comes down to read-only or system files and such...
Not thoroughly tested the registry import since I use xml files for registry changes also; if I recall correctly from my brief testing, I believe the reg file should not be unicode for the script to be able to parse it correctly, so mind the encoding!
A provisioning file is always generated, so that SDConfig does not fail on a missing file.
About the AutoWait script: see here and here. To summarize roughly: 1 AutoWait call is needed for each full 3-minute block that your AutoRun requires to run. Apart from extra run time, it will not do any harm to add extra AutoWait calls to your SDConfig file.
Remark: The AutoRun script can take a parameter to use a custom sibling folder instead of the default AutoRun folder (e.g. a folder "Games"), but I failed to pass that parameter directly from SDConfig. However, yet another script can take care of that, as follows:
create a script for each custom folder (e.g. a script "Games.mscr"), with the following contents:
Code:
CallScript( SystemPath("ScriptPath") \ "AutoWait.mscr" )
CallScript( SystemPath("ScriptPath") \ "AutoRun.mscr", SystemPath("ScriptName"), "^NL^^NL^ processing " & SystemPath("ScriptName"), & "..." )
adapt the SDConfig.txt file to copy and call the new script(s) just created (which in turn will call the original AutoRun script, so do not forget about AutoWait here too!)
A RunAutoRun script is also included in the zip file, to test the SDConfig/AutoRun without hard-resetting your device.
Personally, I use MortScript-4.11b7-PPC.cab and these scripts together with ROMS using SDAutorun v2.0 - and I only have my Trinity to use it on.
Main related links:
MortScript
AutoInstall4
User Customization
SDAutoRun v2.0
Use all at your own risk!

[ reserved ]
The script does not check if it is run manually or automatically, nor does it check the mortscript version it runs with, nor does it actively try to avoid double installation of mortscript, but feel free to post your own code to include these interesting features. Another feature could be to automatically detect the name of the storage card root folder in order to support different languages...

thank you mousio tested with xml, cabs, and folder/files.. very good

Great idea! Automating the automated process of SDAutoRun!

Taking the automated process to next level . AWESOME!!! . you developers are not going to let me get me out of cooking frenzy

The script does not check if it is run manually or automatically, nor does it check the mortscript version it runs with, nor does it actively try to avoid double installation of mortscript, but feel free to post your own code to include these interesting features. Another feature could be to automatically detect the name of the storage card root folder in order to support different languages...
Click to expand...
Click to collapse
If I can find some spare time for this...

Thanks for this tool!
I've only got one issue with it, and that is AutoWait related. It seems that after 6 minutes (I'm installing a lot of cabs), SDAutorun continues to execute the rest of SDConfig.txt, it complains about a missing AutoRun.xml (as the AutoRun.mscr hasn't generated it yet), then the device hangs.
Reading your instructions, it seemed that the solution would be to add more lines of EXEC:\Temp\AutoWait.mscr to the SDConfig.txt, but this appeared to have no effect at all!
If there is any other possible solution for dealing with long-running scripts, I'd love to hear it.
Alex

Would splitting them up into sub scripts work better?
Cuts down the time for each script, but may be more complex.

mousio said:
If I can find some spare time for this...
Click to expand...
Click to collapse
Here is the code that seems to work for me with regard to StorageCard location for international people.
Code:
# STORAGE CARD PATH
Sub StorageCardLogic
If (Length(RegRead("HKLM","System\StorageManager\Profiles\SDMemory","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\SDMemory","Folder")
ElseIf (Length(RegRead("HKLM","System\StorageManager\Profiles\SDMMC","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\SDMMC","Folder")
ElseIf (Length(RegRead("HKLM","System\StorageManager\Profiles\PCMCIA","Folder")) > 0)
StorageCardPath = "\" & RegRead("HKLM","System\StorageManager\Profiles\PCMCIA","Folder")
EndIf
EndSub

Storage Card logic
Long time no post
Based on several sources, including yours, this is now similar to what is in my latest version:
Code:
RegStorageCard1 = RegRead( "HKLM", "System\StorageManager\Profiles\SDMemory", "Folder" )
RegStorageCard2 = RegRead( "HKLM", "System\StorageManager\Profiles\SDMMC", "Folder" )
RegStorageCard3 = RegRead( "HKLM", "System\StorageManager\Profiles\PCMCIA", "Folder" )
RegInternalStorage = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND", "Folder" )
RegAutoPart1 = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND", "AutoPart" )
RegAutoPart2 = RegRead( "HKLM", "System\StorageManager\Profiles\moviNAND\FATFS", "AutoPart" )
If( RegAutoPart1 = 1 || RegAutoPart2 = 1 )
storagecard = "\" \ RegInternalStorage
ElseIf( NOT IsEmpty( RegStorageCard1 ) )
storagecard = "\" \ RegStorageCard1
ElseIf( NOT IsEmpty( RegStorageCard2 ) )
storagecard = "\" \ RegStorageCard2
ElseIf( NOT IsEmpty( RegStorageCard3 ) )
storagecard = "\" \ RegStorageCard3
Else
storagecard = "\Storage Card"
EndIf

SDConfigGen - a tool for automatically creating SDAutorun configurations

First off, I'd like to thank Sleuth255 for SDAutoRun, and to mousio for his AutoRun tool which provided the inspiration for this project.
SDConfigGen is a command line tool for the PC which inspects a collection of files to be installed, then produces an SDConfig.txt and other associated scripts and provisioning files to allow SDAutoRun to automatically install them.
It differs from mousio's solution in that rather than having SDAutoRun call a MortScript to do all the work, this tool creates an SDConfig.txt to do the majority, only calling scripts for specific functionality when required. Scripts (and therefore MortScript) may not even be required, if nothing being installed needs automation.
Installation
Unzipping the contents of the archive will produce this folder structure:
\
Storage Card\SDConfig\Cabs\
Files\
Scripts\
Settings\
Sys\First things first - to use any of the script-based functionality a copy of the MortScript installation cab file must be placed within the Sys folder. Download MortScript-4.11b7.zip (or newer version) from http://www.sto-helit.de, then extract \cab\MortScript-4.11b7-PPC.cab from it.
Usage
If the name of the Storage Card will be different on your target device, then rename that folder to whatever it will be. Otherwise, just leave it as it is.
Within the sub-folders of SDConfig, add the files you want to be installed.
Cabs:
Any .cab files in this folder will be installed. If the installation of a .cab file requires user interaction (to confirm a license window, for example), then create a .mscr script file of the same name containing instructions to be executed while the cab file is being installed.
For example, if you need to install a cab file: "eWallet-PocketPC-Install.cab",
create a file called "eWallet-PocketPC-Install.mscr" too. This file contains
MortScript to be run while the cab installer is being run, for example:
Code:
windowTitle = "Software License Agreement"
WaitFor(windowTitle, 60)
SendLeftSoft(windowTitle)
Note that you don't need to worry about actually installing the cab, or waiting for installation to finish - just write the automation code itself.
The SDAutoRun UI will be hidden while an interactive cab is being installed like this, and a MortScript status window shown instead. The device will be responsive to user input, so if any non-automatable interaction is required, that can be done manually.
Files:
After the cab files have been installed, all files in this folder will be copied directly to the root folder. To copy files to sub-folders, place them in sub-folders of this folder. For example, to copy files to the Windows folder, create a Windows folder here and place the files within it.
Standard (English) folder names will automatically be replaced by variables, so files in the "Files\Program Files" folder here will be copied to %CE1% folder by SDAutoRun.
The file copy operation is actually performed by generating a CopyFiles.xml provisioning file in the Sys folder, and it is this that goes in the SDConfig.txt file. This method was chosen as it avoids the path length limit of copying directly in SDConfig.txt, and allows for the %CEn% variable subsitution scheme.
Settings:
After the files have been copied, any settings in this folder will be applied. Settings may either be .xml provisioning files (which are added directly to SDConfig.txt), or registry data in .reg, .rgu or .cereg files. Registry data files will be automatically converted to xml provisioning files within the Sys folder, which are then added to SDConfig.txt.
Scripts:
After the settings have been applied, any .mscr scripts within this folder will be executed. SDConfigGen will generate instructions in SDConfig.txt to automatically handle copying them to the \Temp folder and renaming them to replace spaces by underscores before execution if required.
Note that the device will not be interactive at this point, so don't write scripts that require user interaction.
Sys:
Apart from placing a copy of MortScript-4.11b7-PPC.cab in here, you shouldn't touch the contents of this folder; they will be automatically cleaned out and generated by the SDConfigGen tool.
Notes
I've provided RegToXml as a standalone .exe file so that registry data files can be manually converted to .xml provisioning files, if required. This is not generally necessary, though, as it will occur automatically as part of the SDConfigGen process.
Due to limitations of SDAutoRun, during installation some files need to be copied to the \Temp folder on the device before execution. A TempCleanup.xml provisioning file is generated in the Sys folder by SDConfigGen which is the last thing executed by SDConfig.txt. It should remove any temporary files that were placed in the \Temp folder, but will not remove the folder itself, or any other files within it.
SDAutoRun also requires that SDConfig.txt be ASCII, which means that if any files contain characters outside that range (such as accented characters), they can not be directly referenced. SDConfigGen will automatically detect this, and generate provisioning XML files to transparently rename the files before processing them, then back again afterwards.
The last statement in the SDConfig.txt is the RST: Reset statment, to reset the device.
The only part of the file structure that can be changed is the name of the "Storage Card" folder - the other folders cannot be renamed or moved. By default, when the SDConfigGen tool is run, it works with the first sub folder under the folder the .exe file is placed. To override this behaviour, pass the folder path to SDConfigGen.exe as a command line argument.
Cabs, settings and scripts are executed in alphabetical order, grouped by subfolder. Subfolders will be executed first, so for example the contents of Cabs\Prerequisites\ would be installed before the files directly in Cabs\ (but after files in Cabs\A\). All interactive cabs are executed first, followed by non-interactive ones.
All generated files (except SDConfig.txt) are in Unicode UTF-16 encoding.
To have SDConfigGen create a log file of the generation process, use the SDConfigGenWithLog.bat file included in the archive. It will create a results.log file containing the messages that would normally be output to the console.
This is still an early version, so there will probably be bugs with it. I've used it successfully for setting up my own device several times now, but I can't make any guarantees. Please do post any bug reports or suggestions here though!
Alex
Updates
0.6:
All output files are now in UTF-16 encoding, with the exception of SDConfig.txt, which is in ASCII.
If files referenced by SDConfig.txt have names containing non-ASCII characters, provisioning files to automatically rename them before they are accessed, and to restore them afterwards will be generated.
Subfolders are now supported in the Cabs, Settings and Scripts folders. Files within subfolders will be processed first, in alphabetical order of subfolder name.
File folder variable substition made case insensitive
Added SDConfigGenWithLog.bat file for easy logging of output to a log file
0.5.1:
Removed .svn files from the file structure (oops!)
0.5:
Made warning message on skipping registry files less confusing
RegToXml: Now supports empty values for String, MultiString and Binary values
RegToXml: Made ,ore robust to invalid data - if a value contains invalid data, only that value is skipped.
RegToXml: The line number is now reported with any error or warning message.
RegToXml: Whitespace allowed to surround the = in value lines.
0.4:
RegToXml: Fixed nesting bug with registry key deletion conversion
RegToXml: Now supports comments (lines starting with ; )
0.3:
RegToXml now assumes that registry files without Unicode BOM's are encoded in the system default ANSI codepage, rather than UTF-8 (this means that if your registry file is UTF-8, it must contain a Byte Order Mark to be read correctly)
0.2:
Files are now installed in alphabetical order by file name (within their own group). For example, first interactive cabs A-Z, then non-interactive cabs A-Z. This allows control over installing cabs that require others to be installed before or after them.
.NET Framework (required)

Lookin Mighty Fine Siuer.
Not in the Testing Time yet.
But does the scripts folder eventually combine the scripts into one?
(lazy Bum At Work, Not Able to test it)

No, the scripts in the scripts folder are not combined into a single script, they are all executed separately. Would there be some benefit to trying to combine them into a single script before execution?

AlexVallat said:
No, the scripts in the scripts folder are not combined into a single script, they are all executed separately. Would there be some benefit to trying to combine them into a single script before execution?
Click to expand...
Click to collapse
No, you are absolutely right there is now good reason for it.
It's better to have them seprated, makes finding **** Ups easier.
Don't know what i was thinking or why..

AlexVallat,
Thanks for your job, you soft is amazingly simple which is a great pro compared to SASHIMI for instance.
So yhis afternoon I started to put all my files in the appropriate folders and when I launch SDConfigGen with the folder path I don't get in the config.txt file \Storage Card\ before the files to execute but the path I gave as parameter. I think transforming the path given into \Storage Card\ could help.
One other point, as a poor French guy your RegToXml converter does not handle all the French extended character set such as é, à, ... Could you make it support this characters.
Anyway for now it is fully usable but requires SDConfig.txt file edition before launching the whole process. Tomorrow it will be hands-on time as I plan to upgrade my Polaris ROM so more news to come regarding SDCofingGen usage.
The_Steph

The_Steph said:
AlexVallat,
Thanks for your job, you soft is amazingly simple which is a great pro compared to SASHIMI for instance.
So yhis afternoon I started to put all my files in the appropriate folders and when I launch SDConfigGen with the folder path I don't get in the config.txt file \Storage Card\ before the files to execute but the path I gave as parameter. I think transforming the path given into \Storage Card\ could help.
One other point, as a poor French guy your RegToXml converter does not handle all the French extended character set such as é, à, ... Could you make it support this characters.
Anyway for now it is fully usable but requires SDConfig.txt file edition before launching the whole process. Tomorrow it will be hands-on time as I plan to upgrade my Polaris ROM so more news to come regarding SDCofingGen usage.
The_Steph
Click to expand...
Click to collapse
Hm my pall had the same thing but changing to Unicode seemed to solve his XML issue. NOt sure if this is the same but worth the try.

Great work alex!
Question:
Anyway to verify the syntax of the provisioning XML files?
Any tools out there that can create these files or verify them? I think a tool like this would be great.
NEVERMIND! I just saw your reply in the reg2xml converter thread! THANKS!

The_Steph: Thanks for your comments!
The idea with the path is that the name of the folder is used to control the name of the Storage Card on the device. So if you name your folder Storage Card, that's what goes in the SDConfig.txt. If, on your device, it has a different name (due to language changes, or whatever), then you need to rename the folder appropriately.
Thanks for the bug report about accented characters in RegToXml. I will fix that and post an updated version soon.
gtxaspec: I could verify that the files were valid XML, but the more useful check that they contain valid provisioning instructions is beyond the scope of this project. Not least because the documentation describing what are valid instructions is confusing and can be inaccurate. With anything other than the file and registry providers, it usually ends up being a case of trial and error. With the file and registry providers, using the auto-generation capabilities of SDConfigGen will avoid most surprises.
Alex

Version 0.3 released
I've just updated the first post to release version 0.3. This should address the accented characters issue raised by The_Steph, however it does mean that if your registry file is UTF-8 encoded, it must include Byte Order Marks to indicate this. Otherwise, it will be assumed to be encoded in the system default code page.
I've also added a feature that files are now installed in alphabetical order (within each group). If you need to make sure that certain cabs are installed before others, this can now be done by renaming them, usually by including a numeric prefix.
Alex

reg2xml bugs
Hi Alex,
Converting everything to xml and using standard provisioning is an interesting approach!
Only obviously reg2xml has got some problems still with .reg files containing certain characters:
I've attached you a sample file which is not converted correctly at three points, each with a different error cause.
- Comments (Lines beginning with ";") in the .reg files are sometimes (not in every case, could not see what the trigger is) leading to an aborted conversion.
- Some characters like the arrow character (ASCII 27/1BHex) are also a problem.
Maybe the attached file helps in finding the bug.
BTW: Do you also have a tool that is converting just the other way around: From XML to reg indstead of from reg to XML?
Sometimes I need to have a .reg file instead of an .XML. And importing the XML and then trying to find all registry entries to export it back to a .reg can be a very tedious thing when the imports are not all together in one registry branch.
Thanks!

Thanks for the bug report, asango. Yes, I forgot about comments, I'll fix that and release an update soon. I'm looking into what the best way to handle control characters like 0x1B is (which is 'Escape', according to the ASCII chart I'm looking at). Obviously crashing is not an acceptable behaviour, so I'll have some sort of fix for it.
I don't have a XmlToReg tool, but it sounds like a good idea - I'll probably write one over the weekend.
Alex

Great, looking forward to that, thank you!

Version 0.4 released
The first post has been updated to version 0.4. RegToXml has been updated to add support for comments in .reg files.
Unfortunately there appears to be no way to include control characters in an XML file. If the character itself, or even the character entity (like &#x1B, then the file is regarded as malformed and not accepted. I have therefore not been able to do anything to fix this (sorry asango!).
If anyone knows of a way that a provisioning file could be used to set a registry string value containing these characters, please let me know.
On a more positive note, the requested XmlToReg tool is up - I've given it its own thread here: XmlToReg.
Alex

Yes, the comments are now handled corectly, perfect!
Some other thing is still an issue:
test.reg: Converting...
test.reg: Conversion failed. (Unexpected value format: dword) Skipping.
In this case the output file is not generated at all, seems that not only the value is skipped but this causes the whole file not being written.
This leads to another suggestion: Would it be possible to indicate the line number where a problem happened?
This would make it much easier to find the problem.
And regarding the non handled escape characters:
This also leads to aborting. Would it also be possible to just skip them and issue a warning but go on with the conversion and with writing the outout file for the rest of the entries?

Now that is odd. "dword" is a perfectly valid value format, it shouldn't have produced that error. Any chance you could send me the .reg file that produced it?
Line numbers should be do-able, I'll add that to the next version.
The "skipping" message there referred to the "test.reg" at the start of the message, not to the dword value. I agree it looks misleading as it is currently worded though, I'll improve that.
About recovering from errors and skipping only invalid values rather than the whole file - this will be quite tricky. By the time I am notified of invalid characters by the XmlWriter, it has already given up in a sulk and can't be persuaded to continue writing any further. I'll need to do some sort of pre-vetting before passing data on to it. If I come up with any good ideas on how to do this, I'll include it in the next version.
Alex

asango, here's a candidate RegToXml.0.5.0 - could you check if it is still reporting the "Unexpected value format: dword" error with your file? It now reports line numbers, which might help track down the problem. It should also be able to recover from an invalid value and skip just that value, although I'm not sure how well that is working yet.
Alex

Hi Alex,
Great, the line numbers are making things much easier and this way I even found the reason for this error very easily:
Here's the point where it is failing:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL]
"NITZEnable"= dword:00000001
...with this error message:
test.reg: Converting...
[Line 194] Error: Invalid value (Unexpected value format: dword)
Skipping: HKEY_LOCAL_MACHINE\Drivers\BuiltIn\RIL\NITZEnable
Done.
As soon as I'm deleting the blank between the "=" and "dword" everything is ok.
Maybe you can allow blanks after the "=" in general?
This would solve this issue definitely
And yes, by the way the xml file is now generated despite of this error, very good!
Asango

Hmm... I'm not sure whitespace is supposed to be allowed around the = sign. It doesn't make anything ambiguous though, so there's no good reason not to relax the matching. Try this 0.5.1 which allows whitespace around the = sign, hopefully that should now parse your file correctly.
Alex

Yes, now I can see no other issues with the RegToXml tool, good work!
Also the whole cold boot import is ok with one exception:
Only the CopyFiles.xml which is generated by the SDConfigGen.exe is not copying all the files from the "Files" diectory during its execution.
Tried to import that xml manually with the xml option of Taskmgr and also got an error, but since the error is *very* uninformative and not showing the line number and my CopyFiles.xml is rather big I could not find the problem.
Could it be that the reason for the error is that if a file is already existing or read only that this will stop the rest of the import?

asango said:
Yes, now I can see no other issues with the Only the CopyFiles.xml which is generated by the SDConfigGen.exe is not copying all the files from the "Files" diectory during its execution.
Tried to import that xml manually with the xml option of Taskmgr and also got an error, but since the error is *very* uninformative and not showing the line number and my CopyFiles.xml is rather big I could not find the problem.
Click to expand...
Click to collapse
Second hands-on day with SDConfigGen and I have the same issue with v0.4. CopyFiles.xml is not executed at all. Probably a syntax error issue as stated by asango (I've done the same tests as him).
The_Steph

[TUT] Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3

Version: 26/04/2009
Intro
Welcome; I wanted to offer a little "something" back to the XDA community in the hopes that it will benefit others and to show my appreciation to the folks that make XDA the great community that it is. Hopefully, this guide will help you work your way up the ranks to Chef … let’s begin!
There are many chefs that provide quality ROM's for you to use. However, if you've gotten excited about the idea of cooking your own ROM's, you've probably felt overwhelmed by the volume of Forum Threads and Wiki pages at your disposal to learn how to do this.
The sections are intended to be followed in sequence as the last section should provide you with a final product that can be flashed to your device – so you may want to read this guide once over before going through the motions … who am I kidding? You’re going to follow along aren’t you?
In case you're wondering ... I chose Sous-Chef because Commis or Chef De Partie just didn't have the same appeal
Applying Original/Cooked ROM's
You probably won't be able to apply an Original or Cooked ROM to your device as your Cellular Carrier has most certainly locked your device. You'll need to unlock your device before venturing into the world of ROM installation. These activities are beyond the scope of this guide; you can however, go to this Wiki page to learn more.
HTC Raphael
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael
Original VS Cooked ROM's
HTC periodically releases Official Generic ROM's that you can apply to your device. You can find a list of Original Shipped WM6.1 ROM's at this Wiki page.
Original Shipped WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_WM6.1_ROMs
There are essentially two types of Cooked ROM's; those that another Chef makes available for you to use, and those that you cook yourself. You can find a list of Available Cooked WM6.1 ROM's at this Wiki page.
Available Cooked WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_Cooked_WM6.1_ROMs
Outro
Lastly, this guide only covers the ROM cooking process; changing your device Startup Splash Screen and Radio or flashing a HardSPL are beyond the scope of this guide; you can however, go to these Wiki and/or Forum pages to learn more.
Radio
http://wiki.xda-developers.com/index.php?pagename=Raphael_ExtractedRadioRoms
http://forum.xda-developers.com/showthread.php?t=439566
Startup Splash Screen
http://forum.xda-developers.com/showthread.php?t=431161
Hard SPL
http://wiki.xda-developers.com/index.php?pagename=Raphael_HardSPL
This guide is intended to help you learn how to cook your own ROM's; it will walk you through the process of extracting the contents of an Official ROM, adjusting the Page Pool, changing the Data Cache Size, and Patching the ROM to remove Certificate verification. The guide does not cover the steps required to add/remove ROM packages or port an XIP from a different ROM version or device ... not yet anyway
Now for the disclaimer bit; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk. If you spot mistakes or inaccuracies in the guide however, please let me know so that I may correct them. Now, read on if you still feel that this is your choice career path
Oh, one last thing ... to the following folks for sharing their knowledge with the rest of us ... thank you!
Da_G
Ameet
Bepe
Cmonex
Ervius
JCEspi2005
JugglerLKR
mskip
Olipro
Aruppenthal
NRGZ28
Noonski
If I missed someone, it's purely accidental – send me a note and I will add your name to the list.

[TUT] Sous-Chef's Guide to Da_G's Simple Kitchen 5.3 ... continued
Location, Location, Location
There are many fine Kitchens out there to use; Visual Kitchens (Ervius), Automated Kitchens (Bepe), and Semi-Automated Kitchens (Raphael, Da_G). This guide uses Da_G's Simple Kitchen to assist you in learning the basics of operating a Kitchen; which ultimately, allows you to produce your own ROM.
References
Da_G....: http://forum.xda-developers.com/showthread.php?t=471288
Raphael.: http://forum.xda-developers.com/showthread.php?p=2453788
Bepe....: http://forum.xda-developers.com/showthread.php?t=467488
Ervius..: http://forum.xda-developers.com/showthread.php?t=469420
Preparing Your Facility
Before you can begin to cook your own ROM, you need to equip your facility with some Kitchen utensils. Your Kitchen is going to require a good Unicode & UTF-8 text editor; I personally use ConTEXT & Notepad. Another handy utensil to have is a comparison utility for date/file/binary comparisons; I use WinDiff & BeyondCompare. Some other utensils that you're going to require are: Microsoft ActiveSync, .NET Framework 2.x/3.x. You will also need an archive extraction utensil; I use IZArc, WinRAR, and WinZIP. You’ll also need a good Hexadecimal calculator; I use Windows Calculator (Scientific Mode).
It's also a good idea to ensure that your Kitchen remains "pest" free; common pest control services include AVG, McAfee, and Symantec anti-Virus. You'll need to add the CustomRUU Updater tool to your list of anti-virus exclusions as it will be detected as a "Generic Dropper (Trojan)".
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
To assist you in your apprenticeship, I have included a link to the Generic Simple Kitchen that I used to prepare this guide - the kitchen also includes a .DOC and .PDF format of this guide. The procedures were tested against a GSM Raphael device. I can’t confirm that these procedures will work on CDMA device ROM’s. Additionally, other device ROM’s may not be compatible with this kitchen format. Make sure to review the _README.TXT before you begin.
Generic Simple Kitchen, 17 MB
You’re going to need a RUU_SIGNED.NBH file; I used the following HTC Official Generic ROM – you’ll need to extract the contents of the .EXE and .RAR/.ZIP using an archive utensil.
[ROM] [WWE] Raphael HTC 5.05.405.1 Radio Signed (52.58.25.3 0,1.11.25.01)
http://rapidshare.com/files/1939660...igned_Raphael_52.58.25.30_1.11.25.01_Ship.rar
http://www.megaupload.com/?d=0F50UM5K
For the purpose of this guide, I will assume that you have added the C:\XDA\ folder, sub-folder, and files to your anti-virus exclusion list – at the very least CustomRUU Updater.EXE – and that the contents of the Generic Simple Kitchen were extracted to the following folder.
C:\XDA\MY_KITCHEN
The guide is divided into the following sections:
Extracting the RUU_SIGNED.NBH Contents ... 3
Consolidating .RGU Files to BOOT.RGU ..... 4
Increasing the Data Cache ................ 5
Reducing the .PAYLOAD File ............... 6
Extracting the XIP.BIN Contents .......... 7
Unlocking the Paging Pool ................ 8
Disabling Certificate Checking ........... 9
Updating the XIP.BIN Contents ............ 10
Updating the .PAYLOAD file ............... 11
Changing the Unsigned CAB Policies ....... 12
Changing the Unsigned Themes Policies .... 13
Changing the Remote API (RAPI) Policies .. 14
Compiling the New RUU_SIGNED.NBH File .... 15
Flashing the RUU_SIGNED.NBH File ......... 16
Advanced Topic: XIP Porting .............. 17
Sous-Chef's TIPs ......................... 18
I will attempt to provide an overview, the list of tools required, and the process to follow in each section. As you become more comfortable (and familiar) with the activities, you will find that you can consolidate (or skip) certain outlined steps. Incidentally, you'll probably want to keep these web links open in case you need to lookup some of the terms or concepts in the guide.
Acronyms
http://wiki.xda-developers.com/index.php?pagename=Acronyms
Glossary
http://wiki.xda-developers.com/index.php?pagename=Glossary
Development Resources for Windows Mobile
http://forum.xda-developers.com/showthread.php?t=445396

Extracting the RUU_SIGNED.NBH Contents
Extracting the Contents
An .NBH is a signed group of modules or packages; they are typically comprised of .NB files. An .NBH can contain any combination of .NB files. An .NB file is a block of code that can be a Radio ROM, Operating System packages (XIP and IMGFS), Startup Splash Screen (or SPL).
The file we will be working with is the OS.NB file; it contains the ULDR, XIP, and IMGFS (OEM, SYS). To extract the contents of an .NBH file, we issue the following command.
NBHextract.exe RUU_signed.nbh
Upon completion, the following files will have been extracted: Unknown.nb, 01_SPL.nb, 02_MainSplash.bmp, 02_MainSplash.nb, and 03_OS.NB. For the purposes of this guide, the 03_OS.NB file is the file we will be working with; it will be renamed to OS.NB.
Splitting the OS.NB File
In any ROM, the OS.NB is padded with extra data that is split into packets for the flashing process. This ensures that incorrectly transmitted packets can be re-transmitted to a device without having to resend from the beginning. Packets are usually groups of bytes and vary between devices - a packet will typically contain of data followed by padding.
For the Raphael, the data packets are 800 bytes in size and padded with 8 bytes. For the purposes of this guide, this padded portion is not required and therefore, we strip it from the OS.NB using with the NBSPLIT tool by issuing the following command.
nbsplit -kaiser os.nb
The -kaiser option instructs the NBSPLIT tool to process 0x800 (2048 decimal) hexadecimal bytes of data and that 8 bytes of padding will follow each 800 bytes. Upon completion, the following will have been extracted: os.nb.payload, os.nb.extra. For the purposes of this guide, the os.nb.extra is not required.
At this point, we need to extract the contents of the ULDR, XIP, IMGFS (OEM, SYS) from the .PAYLOAD file as we will be changing the ULDR and XIP. Most of the .PAYLOAD file content is the IMGFS; this is the portion that makes up content of the OEM and SYS folders. Most chefs add/remove OEM packages in these folders during their cooking process - you'll eventually do the same.
Tools Required
The following tools are required for the RUU_SIGNED.NBH extraction activities.
NBHextract
NBSplit
ImgfsFromNb
ImgfsToDump
RomMaster
DumpROM
PKGTool
Procedure
The following procedure initiates the ROM Extraction (NBH, IMGFS, and XIP) activity via a script that is included in the Generic Simple Kitchen. The extraction process can take a significant amount of time to complete.
Copy the RUU_SIGNED.NBH file to the C:\XDA\My_Kitchen\BaseROM\ folder.
Navigate to the C:\XDA\My_Kitchen\Tools\ folder.
Launch RaphaelKitchen.cmd.
Select E, press ENTER.
Select A, press ENTER.
At the Done! message, allow the process to resume – do not close command prompt!
At the Now Start Cooking Your ROM! Press Any Key To Continue message, press ENTER.
Select X, press ENTER.
References
NBHextract: Extract Contents From NBH Files
http://forum.xda-developers.com/showthread.php?t=289830
[TUT] ROM For Everyone (Video Tutorial To Cook The ROM)
http://forum.xda-developers.com/showthread.php?t=413782
[REF] Cooking Class Class of 2008/09 [ONLINE]
http://forum.xda-developers.com/showthread.php?t=335631

Consolidating .RGU Files to BOOT.RGU
The boot hive contains system settings that are applied only during boot. The boot hive is read out of ROM and used to start drivers and file systems needed to reach the system hive file. Once the system hive is mounted, the boot hive is discarded. Changes made to the registry during the boot process are copied into the system hive once it is available. The boot hive in ROM remains unchanged.
The boot.hv registry hive, which contains the contents of all .RGU files in the XIP, provides the initial basic registry hive that is referenced during the loading of the kernel and any necessary drivers to mount the root file system. Once the file system is mounted the default.hv and user.hv registry hives are mounted and used. Most chefs add/remove/change entries from the BOOT.RGU file during their cooking process – you'll eventually do the same.
For the purposes of this guide, we will consolidate the contents of all .RGU files found in the Dump_XIP folder into the BOOT.RGU file. Consolidating the contents of the .RGU files found in the Dump_XIP folder to the BOOT.RGU file ensures that all necessary registry entries will be added during the ROM compilation activities.
Tools Required
The following tools are required to edit .RGU files.
Unicode Text Editor
Procedure
The following procedure will consolidate all of the .RGU files found in the Dump_XIP folder into the BOOT.RGU file.
Navigate to C:\XDA\MY_KITCHEN\Temp\Dump_XIP\ folder.
Launch a text editor and open the BOOT.RGU file.
Launch a text editor and open the next .RGU file that appears in the C:\XDA\MY_KITCHEN\Temp\Dump_XIP\ folder.
Select and copy all of the file contents.
Switch to the BOOT.RGU file and paste the content to end of this file.
Repeat steps 3 to 5 until the content of each .RGU file has been appended to the BOOT.RGU file.
Save the expanded copy of the BOOT.RGU file in the C:\XDA\MY_KITCHEN\ROM\XIP\ folder.
Tip
Make a backup copy of the BOOT.RGU file before editing; delete the backup file when done.
Observe the line formatting and spacing in the BOOT.RGU file and make certain to have an empty line as the last line of the file.
Comment lines, which usually begin with a semi-colon [;], can be omitted.
Registry removal lines usually begin with a minus [-] after the open square bracket.
References
Windows Mobile
http://msdn.microsoft.com/en-us/library/ms885472.aspx

Increasing the Data Cache
File caching improves performance and also improves power management; when an application accesses physical storage, the storage device uses much more power. The less often physical storage is accessed, the longer storage devices spend in a low-power state.
By increasing the DataCacheSize registry value, you effectively improve the performance of applications that are file system intensive such as database and mapping applications – which results in lower physical storage access requirements. Drastically increasing the DataCacheSize however, may have adverse effects and slow the device down as a result of longer auto-compaction processing.
For the purposes of this guide, we are going to increase the current DataCacheSize value from 4MB to 8MB.
Tools Required
The following tools are required to adjust the DataCacheSize value.
Unicode Text Editor
Hexadecimal Calculator
Procedure
The following procedure will change the current DataCacheSize value of 4MB to 8MB.
Navigate to the C:\XDA\MY_KITCHEN\ROM\XIP\ folder.
Launch a text editor and open the BOOT.RGU file.
Search for the following registry key entry:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\FLASHDRV\FATFS]
Locate the following registry value underneath the key:
"DataCacheSize"=dword:00000800 ;2048 sectors(2048*2048=4MB)
Change the registry value to the following:
"DataCacheSize"=dword:00001000 ;4096 sectors(4096*2048=8MB)
Save the BOOT.RGU file.
Exit the text editor.
Tip
Make a backup copy of the BOOT.RGU file before editing; delete the backup file when done.

Reducing the .PAYLOAD File
At this point, we need to remove the contents of the IMGFS (OEM, SYS) from the .PAYLOAD file in preparation for our changes to the ULDR and XIP. Removing the IMGFS (OEM, SYS) contents from the .PAYLOAD file will reduce the size of the .PAYLOAD file making it easier to work with.
To reduce the .PAYLOAD file, we essentially need to cook a new version of the .PAYLOAD file with an empty IMGFS partition – one which only contains the .VM and .ROM folder contents. For the purposes of this guide, we will use the Ervius Payload Reducer script to perform this process.
Tools Required
The following tools are required for the .PAYLOAD file reduction activities.
ImgfsFromNb
ImgfsFromDump
ImgfsToNb
Procedure
The following procedure initiates the .PAYLOAD file reduction activity via a script that is included in the Generic Simple Kitchen. The reduced os.nb.payload file will be required when we update the XIP.BIN file.
Copy the ReducePayload folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\ folder.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\ folder to the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder.
Navigate to the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder.
Launch reduce_payload.bat.
At the OS.NB.PAYLOAD Successfully Reduced. Press Any Key To Continue ... message, press ENTER.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676

Extracting the XIP.BIN Contents
The Execute-in-place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. Before we can proceed to make changes such as unlocking the Page Pool and disabling Certificate checking, we need to extract the contents of the XIP.BIN file.
It is possible to use the XIP.BIN contents from a newer version of a ROM from a different device or a newer operating system. This is typically done by chefs who are looking for the most recent versions of system files from a specific device or version of an operating system – you'll eventually do the same.
For the purposes of this guide, we will be using the same version of the system files.
Tools Required
The following tools are required for the XIP.BIN file extraction activities.
XIPPort
Procedure
The following procedure will extract the contents of the XIP.BIN file. The extracted contents of XIP.BIN file will be required when we unlock the page pool and disable certificate checking.
1. Copy the XIPPort folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\ folder.
2. Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
3. Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
4. Launch XIPPORT.EXE.
5. Click the Dump XIP.BIN button.
6. Exit XIPPORT.EXE.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
XIP Porting Guide
http://forum.xda-developers.com/showthread.php?t=379598

Unlocking the Paging Pool
The Paging Pool serves as a limit on the amount of memory that can be consumed by pageable data. It includes an algorithm for choosing the order in which to remove pageable data from memory. Pool behaviour is typically determined by the OEM – Microsoft sets a default value for the paging pool, but the OEM can change that value. Applications do not have the ability to set the behaviour for their own executables or memory-mapped files.
For the purposes of this guide, we are going to apply a change to the kernel binary file which will permit us to change the Paging Pool size (initially set to 6MB) to other sizes using the PagePool Changer tool.
Tools Required
The following tools are required for the Paging Pool unlock activities.
Hexadecimal Editor
Procedure
The following procedure will change the kernel binary file to permit adjustments to the Paging Pool size via the PagePool Changer tool.
Navigate to the C:\XDA\MY_KITCHEN\Tools\xvi32\ folder.
Launch XVI32.EXE.
Select File, Open.
Navigate to C:\XDA\MY_KITCHEN\Temp\XIPPort\OUT\MODULES\nk.exe\ folder.
Select the S000 binary file.
Select Search, Find.
In the Hex String box, type:
03 15 A0 03 02 15 A0 13
Click OK.
Change the following 4 bytes after the 03 15 A0 03 02 15 A0 13 string;
FROM: 00 10 82 E5
TO: 00 00 A0 E1
Select File, Save.
Select File, Exit.
Tip
Make a backup copy of the S000 file before editing; delete the backup file when done.

Disabling Certificate Checking
During the startup process of your device, the operating system verifies that each system file against an internal certificate store to ensure that each file is signed with a trusted certificate; if the system file is not signed, the file is ignored.
To allow execution of non-signed system files, we need to disable the internal certificate store verification. Once disabled, the operating system will trust all code installed regardless of its signature. This provides more control over the code that gets installed on the device – you no longer need to load and manually sign additional certificates such as those from the sdkcerts.cab into the device root certificate store.
For the purposes of this guide, we are going to apply a change to the kernel binary file which will disable the internal certificate store verification.
Tools Required
The following tools are required to disable the internal certificate store verification.
AutoPatcher01
Procedure
The following procedure will disable the internal certificate store verification.
Navigate to the C:\XDA\MY_KITCHEN\cmonex_AutoPatcher\ folder.
Launch AUTOPATCHER01.EXE.
Click the Cert Patch button.
Select All File (*.*) from the Files Of Type list.
Navigate to C:\XDA\MY_KITCHEN\TempXIPPort\OUT\MODULES\nk.exe\ folder.
Select the S000 binary file.
At the Successfully Patched... message, click OK.
Exit AUTOPATCHER01.EXE.
Tip
Make a backup copy of the S000 file before editing; delete the backup file when done.
References
[RES] RILPHONE.DLL And "How To" With A Radio
http://forum.xda-developers.com/showthread.php?t=481026
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx

Updating the XIP.BIN Contents
The Execute-in-place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. Now that we have unlocked the Page Pool and disabled Certificate checking, we need to assemble the extracted XIP.BIN contents back into a XIP.BIN file that includes our changes.
It is possible to use the XIP.BIN contents from a newer version of a ROM from a different device or a newer operating system. This is typically done by chefs who are looking for the most recent versions of system files from a specific device or version of an operating system – you'll eventually do the same.
For the purposes of this guide, we will be using the same version of the system files.
Tools Required
The following tools are required for the XIP_OUT.BIN file creation activities.
XIPPort
Procedure
The following procedure will compile the contents of the XIP.BIN file. To eliminate some confusion, the new .BIN file will be called XIP_OUT.BIN – the XIPPort tool creates the new .BIN file and renames it to XIP_OUT.BIN.
Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
Launch XIPPORT.EXE.
Click the Build XIP_OUT.BIN button.
Exit XIPPORT.EXE.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
XIP Porting Guide
http://forum.xda-developers.com/showthread.php?t=379598

Updating the .PAYLOAD file
The Update Loader (ULDR) Partition
The boot loader can accommodate multiple execute-in-place (XIP) regions where individual modules can be updated after the initial operating system image file has been written to the device – the ULDR is an example of this use. The Update Loader (ULDR) provides Flash-Over-The-Air (FOTA) capabilities permitting your carrier to issue changes such as Hotfixes over the cellular network – generally, most carriers avoid this practice.
As this is generally undesirable in a cooked ROM, since we are making modifications that a carrier Hotfix might roll back, we will reduce the partition. This will cause the device to report insufficient ULDR space to the carrier FOTA request … and the freed up space becomes available for our uses. Lastly, we will remove some debugging system libraries from the XIP_OUT.BIN file – effectively providing approximately 3 MB of space.
Adjusting the ULDR and Updating the .PAYLOAD file
We will use the ROM Tools feature of the XIPPorterEx tool to adjust the ULDR, remove the debugging system library files. We will commit our changes which will replace the current XIP.BIN contents with our new XIP_OUT.BIN contents resulting in the final OS.NB.PAYLOAD file – which we will use when cooking our new ROM.
The new OS.NB.PAYLOAD file will be placed in the following folder – effectively replacing any existing OS.NB.PAYLOAD file.
.\XIPPorterEx\MyTools\os_nb.payload\
As we have already unlocked the Paging Pool and disabled Certificate checking, we will not use the Execute Cert Patcher, Execute PP Patcher, Change PP To MB features. As we will be using the same version of the system files, we do not need to port the MSXIPKernel or remove cachefilt.dll, mencfilt.dll, and encfilt.dll.
Tools Required
The following tools are required to perform the OS.NB.PAYLOAD file update activities.
XIPPorterEx
G’Reloc
ImgfsFromDump
ViewImgfs
XIPPort
Procedure
The following procedure will create a new OS.NB.PAYLOAD file which will be used when cooking our ROM.
Copy the XIPPorterEx folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\ folder.
Copy the .ROM folder (and contents) from the C:\XDA\MY_KITCHEN\SYS\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\sys\ folder.
Copy the .VM folder (and contents) from the C:\XDA\MY_KITCHEN\SYS\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\sys\ folder.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder to the C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder.
Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip.bin_old\ folder.
Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip.bin_new\ folder.
Copy the XIP_OUT.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip_new_ported\ folder.
Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\ folder.
Launch XIPPORTEREX.EXE.
Clear the following check boxes:
Execute Cert Patcher
Execute PP Patcher
Port Only MSXipkernel
Delete CACHEFILT.DLL
Delete MENCFILT.DLL
Delete ENCFILT.DLL
Change PP To MB
Create OEM Package From Unused Xip Modules/Files
Don't Copy Xip Dsm
DEBUG Save Temp .BIN Files
Click the ROM Tools button.
Clear the following check boxes:
Conservative Mode
Write NEW Xip Size Into MBR
Select the DEBUG Delete Temp .BIN Files check box.
Click the Give From Your XIP_OUT.BIN button.
Click the Write button.
At the OS.NB.PAYLOAD Was Successfully Reduced... message, click OK.
Click the Done button.
Copy the OS.NB.PAYLOAD from C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os.nb.payload_Reduced\ folder to the C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder – overwriting the older version of the file.
Click the Find Start XIP Offset button.
Click the Write It button.
At the NEW OS.NB.PAYLOAD Was Updated Successfully... message, click OK.
Exit XIPPORTEREX.EXE.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\os_nb.payload\ folder to the C:\XDA\MY_KITCHEN\ROM\ folder.
Delete the OS.NB file from the C:\XDA\MY_KITCHEN\ROM\ folder.
Tip
You can change the ROM Date/Version in the Ervius PkGToolsBuildOs Kitchen 6.X-5.3 tool.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Reduce ULDR Partition Size
http://forum.xda-developers.com/showpost.php?p=2916649&postcount=7
[TUT] ULDR Removal for Elf/Elfins
http://forum.xda-developers.com/showthread.php?t=446506
[Walkthrough] How to Port a ROM [XIP and SYS]
http://forum.xda-developers.com/showthread.php?t=389772
[14 NOV] M-Amine 2.0 Kitchens + Tutorials
http://forum.xda-developers.com/showthread.php?t=437898
[Full Guide Thread] TNT.Kitchen for Wizard, Auto XIP Porting and Modules Relocating
http://forum.xda-developers.com/showthread.php?t=388666

Changing the Unsigned CAB Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow execution of unsigned .CAB files, we need to change the default security policy settings that pertain to .CAB files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4101: Unsigned CABS Policy = 8
ID 4102: Unsigned Applications Policy = 1
ID 4122: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4101" value="8" />
<parm name="4102" value="1" />
<parm name="4122" value="1" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html

Changing the Unsigned Themes Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. If a signed theme file does not have a matching root certificate in the Software Publisher Certificate (SPC) store, the file is unsigned and is therefore not executed. To allow execution of unsigned Theme files, we need to change the default security policy settings that pertain to Theme files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4103: Unsigned CABS Policy = 16
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4103" value="16" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Customizing the User Interface of Windows Mobile Powered Devices
http://msdn.microsoft.com/en-us/library/bb416487.aspx

Changing the Remote API (RAPI) Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
The Remote API (RAPI) enables applications that run on a desktop to perform actions on a remote Windows Embedded CE-based device. This includes the ability to manipulate the file system on the remote device, including the creation and deletion of files and directories. Additionally, the Remote API (RAPI) functions can be used to create and modify databases, either in the device's object store or in mounted database volumes. The Remote API (RAPI) applications can also query and modify registry keys as well as launch applications and invoke methods on the remote device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow unrestricted access by remote applications to implement ActiveSync operations on Windows Mobile powered devices, we need to change the default security policy settings that pertain to the Remote API (RAPI).
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4097: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4097" value="1" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Remote API (RAPI)
http://msdn.microsoft.com/en-us/library/aa920177.aspx

Compiling the New RUU_SIGNED.NBH File
Brief Review
At this point, we have consolidated the contents of various .RGU files found in the Dump_XIP folder to the BOOT.RGU file to ensure that all necessary registry entries will be added during the ROM compilation activities. We have increased the Data Cache size, unlocked the Paging Pool, disabled Certificate checking, reduced the ULDR, changed the Unsigned .CAB policy, changed the Theme policy, changed the Remote API (RAPI) policy, and reduced the .PAYLOAD file.
This guide did not go into details about adding, changing, or removing ROM packages to/from the OEM and SYS folders. Additionally, the guide did not cover the steps required to port an XIP from a different ROM version or device – you'll eventually want to learn how to do these types of activities.
Compiling the ROM
We now need to assemble all of these changes into a new RUU_SIGNED.NBH file – this process if often referred to as ROM compilation. We are going to use the Ervius PkgToolsBuildOS-5.3 tool to perform this process – there are newer versions of the Ervius PkgToolsBuildOS available.
Tools Required
The following tools are required for the RUU_SIGNED.NBH file creation activities.
PkgToolsBuildOS-5.3
ImgfsFromDump
NBMerge
Procedure
The following procedure initiates the ROM creation activity via a script that is included in the Generic Simple Kitchen. The creation process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_KITCHEN\ folder.
Launch RaphaelKitchen.cmd.
Select C, press ENTER.
The Ervius PkgToolsBuildOs application will be launched.
Click the BuildOS tab.
Click the Load ROM button.
Select the All Packages In One check box.
In the Name box, type in the title: All Packages In One ROM
Select the Create_ROM_***.bat check box.
In the ROM Date Updater boxes, enter the desired date. Alternatively, click the Today button.
Click the Update Date button.
At the ROM Date On Flash Updated Successfully... message, click OK.
Click the Go button; allow the process to complete.
Wait for the Done message to appear in the Top Status bar.
Exit the Ervius PkgToolsBuildOs application to allow the process to continue.
The HTC ROM TOOL Process Log will appear.
Click the OK button on the Process Log window or allow it to auto exit.
At the Press Any Key To Continue... message, press ENTER.
Select X, press ENTER.
Copy the RaphaelCustomRUU.exe file from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\RUU\ folder.
Move the RUU_SIGNED.NBH file from the C:\XDA\MY_KITCHEN\ folder to the C:\XDA\MY_KITCHEN\RUU\ folder.
Tip
If the compilation is successful, the last three (3) lines in the Report window of the Ervius PkgToolsBuildOs application will display: Checking os-new.nb for bad NAND block marker. Checked 0x### sectors successfully! Done.
References
Ervius: Visual Multilang Kitchen For Last Bepe ROM-Tools
http://forum.xda-developers.com/showthread.php?t=469420

Flashing the RUU_SIGNED.NBH File
If you are reading this, you must have successfully compiled your RUU_SIGNED.NBH file and are now ready to flash it to your device … congratulations! Now for the disclaimer bit; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk.
Also keep in mind that you'll need to unlock your device before venturing into the world of ROM flashing. If you haven’t unlocked your device and applied the Hard SPL, you need to complete these tasks before you can proceed.
The ROM Flashing process is relatively straight forward. You need to ensure that you can connect to your device via the ActiveSync application. Once you have connected to the device, launch the RaphaelCustomRUU tool to flash your cooked ROM to your device – I suggest temporarily disabling your anti-virus software to avoid unforeseen problems.
Tools Required
The following tools are required to flash the RUU_SIGNED.NBH file to your device.
RaphaelCustomRUU
Procedure
The following procedure initiates the ROM Flashing activity. The flashing process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_KITCHEN\RUU\ folder.
Launch RaphaelCustomRUU.exe.
At the Welcome To The ROM Update Utility window, select the I Understand The Caution Indicated check box.
Click the Next button.
At the Follow The Instructions Below window, select the I Completed The Steps Indicated Above check box.
Click the Next button.
At the Current Information About Your PDA Phone window, click the Update button.
At the Verify That You Want To Update The ROM Version window, click the Next button.
At the You Are Now Ready To Update Your ROM Image window, click the Next button - allow the flashing process to complete.
Click the Finish button.
Tip
The current version of the PDA Phone ROM Update Utility 3.27.4.3 we are using has been modified to not format the device when only flashing a Radio, Startup Screen, or Operating System.
Your anti-virus will warn you that the RaphaelCustomRUU.exe contains the "Generic Dropper (Trojan)" – this is a false-positive indication; the .EXE is safe to use.
You can usually recover from a failed flash by copying a known "working" .NBH file to a MicroSD Card and starting your device in the Tricolour bootloader.
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
[Resources] Flashing your First GSM Raphael Rom (For Noobs)
http://forum.xda-developers.com/showthread.php?t=448008

Advanced Topic: XIP Porting
This guide is intended to help you learn how to port the Execute-In-Place (XIP) region from a new (donor) device for use in your kitchen; it will walk you through the process of extracting the contents of an Official ROM, obtaining the new (donor) device XIP, and porting the new (donor) device XIP into your kitchen.
[TUT] Sous-Chef's Guide to Aruppenthal’s XIP Porting Kitchen
http://forum.xda-developers.com/showthread.php?t=526804

Sous-Chef's TIPs
Tips and techniques passed down from the senior chefs in the business.
Love .PROVXML's? Hate Not Knowing If It Worked?
http://forum.xda-developers.com/showthread.php?t=519548
[WinXP Script] Extend Search Companion
http://forum.xda-developers.com/showthread.php?t=490216
[Guide] How to create .LNK files and use parameters
http://forum.xda-developers.com/showthread.php?t=490447

13/02/2010: Tutorial Statistics
Views: 8,744
Guide Downloads: 96
Kitchen Downloads: 118

Thank you very much for putting this together this will help newbs like me cook my own ROM instead of rely on others. Very great contribution.

[TUT] Sous-Chef's Guide to Da_G's Ervius Visual Kitchen 9.7

Version: 31/05/2009
Intro
Welcome; I wanted to offer a little "something" back to the XDA community in the hopes that it will benefit others and to show my appreciation to the folks that make XDA the great community that it is. Hopefully, this guide will help you work your way up the ranks to Chef … let’s begin!
There are many chefs that provide quality ROM's for you to use. However, if you've gotten excited about the idea of cooking your own ROM's, you've probably felt overwhelmed by the volume of Forum Threads and Wiki pages at your disposal to learn how to do this.
The sections are intended to be followed in sequence as the last section should provide you with a final product that can be flashed to your device – so you may want to read this guide once over before going through the motions … who am I kidding? You’re going to follow along aren’t you?
In case you're wondering ... I chose Sous-Chef because Commis or Chef De Partie just didn't have the same appeal
Applying Original/Cooked ROM's
You probably won't be able to apply an Original or Cooked ROM to your device as your Cellular Carrier has most certainly locked your device. You'll need to unlock your device before venturing into the world of ROM installation. These activities are beyond the scope of this guide; you can however, go to this Wiki page to learn more.
HTC Raphael
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael
Original VS Cooked ROM's
HTC periodically releases Official Generic ROM's that you can apply to your device. You can find a list of Original Shipped WM6.1 ROM's at this Wiki page.
Original Shipped WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_WM6.1_ROMs
There are essentially two types of Cooked ROM's; those that another Chef makes available for you to use, and those that you cook yourself. You can find a list of Available Cooked WM6.1 ROM's at this Wiki page.
Available Cooked WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_Cooked_WM6.1_ROMs
Outro
Lastly, this guide only covers the ROM cooking process; changing your device Startup Splash Screen and Radio or flashing a HardSPL are beyond the scope of this guide; you can however, go to these Wiki and/or Forum pages to learn more.
Radio
http://wiki.xda-developers.com/index.php?pagename=Raphael_ExtractedRadioRoms
http://forum.xda-developers.com/showthread.php?t=439566
Startup Splash Screen
http://forum.xda-developers.com/showthread.php?t=431161
Hard SPL
http://wiki.xda-developers.com/index.php?pagename=Raphael_HardSPL
This guide is intended to help you learn how to cook your own ROM's; it will walk you through the process of extracting the contents of an Official ROM, adjusting the Page Pool, changing the Data Cache Size, and Patching the ROM to remove Certificate verification. The guide does not cover the steps required to add/remove ROM packages or port an XIP from a different ROM version or device ... not yet anyway
Now for the disclaimer bit; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk. If you spot mistakes or inaccuracies in the guide however, please let me know so that I may correct them. Now, read on if you still feel that this is your choice career path
Oh, one last thing ... to the following folks for sharing their knowledge with the rest of us ... thank you!
Da_G
Ameet
Bepe
Cmonex
Ervius
JCEspi2005
JugglerLKR
mskip
Olipro
Aruppenthal
NRGZ28
Noonski
If I missed someone, it's purely accidental – send me a note and I will add your name to the list.

[TUT] Sous-Chef's Guide to Da_G's Ervius Visual Kitchen 9.7 ... continued
Location, Location, Location
There are many fine Kitchens out there to use; Semi-Automated Kitchens (Raphael, Da_G), Automated Kitchens (Bepe), and Visual Kitchens (Ervius). This guide uses the Ervius Visual Kitchen to assist you in learning the basics of operating a Kitchen; which ultimately, allows you to produce your own ROM.
References
Ervius..: http://forum.xda-developers.com/showthread.php?t=469420
Da_G....: http://forum.xda-developers.com/showthread.php?t=471288
Raphael.: http://forum.xda-developers.com/showthread.php?p=2453788
Bepe....: http://forum.xda-developers.com/showthread.php?t=467488
Inspecting the Facility
It’s important to get acquainted with any new facility; last thing you want to find out is that you don’t know where to plug your utensils or appliances. Here’s a brief tour of the facilities to get you on your way.
EXT Folder
The External packages (EXT) folder is divided into Device Specific folders and a Shared folder. The Shared folder is typically used for files (packages) that can be installed on any device. Device Specific folders are typically used for files (packages) that should only be applied to a specific type of the device – for example, the Raphael device.
Each Device Specific folder is further divided into Operating System Build Version Specific folders and a Common folder. The Common folder is typically used for files (packages) that can be installed on any Operating System build version. Operating System Build Version Specific folders are typically used for files (packages) that should only be applied to a specific build (version) of Operating System – for example, build version 20764.
Operating System Build Version Specific folders, the Common folder, and the Shared folder can be further divided into sub-folders making file (package) management simpler – for example, .\Raphael\20764\Raphael_External_Packages.
Tip
The EXT Build drop-down box in the Visual Kitchen permits selection of different Operating System Build Version Specific folders.
OEM Folder
The OEM folder can contain multiple Device Specific folders. Device Specific folders are typically used for files (packages) that should only be applied to a specific type of the device – for example, the Raphael device.
Each Device Specific folder is further divided into Locale Specific folders and a Common folder. The Common folder is typically used for files (packages) that can be installed in any locale – not specific to a language. Locale Specific folders are typically used for files (packages) that should only be applied to a specific locale – for example, 0409 (English).
Tip
The Language drop-down box in the Visual Kitchen permits selection of different Locale Specific folders.
ROM Folder
The ROM folder is divided into Device Specific folders and a Shared folder. The Shared folder is typically used for kernel system files that are compatible amongst devices. Device Specific folders are typically used for kernel system files that should only be applied to a specific type of the device – for example, the Raphael device.
The Shared folder is further divided into Operating System Build Version Specific folders. Operating System Build Version Specific folders are typically used for kernel system files that should only be applied to a specific build (version) of Operating System – for example, build version 20764.
Each Device Specific folder is further divided into Operating System Build Version Specific folders. Operating System Build Version Specific folders are typically used for kernel system files that should only be applied to a specific build (version) of Operating System – for example, build version 20764.
Tip
The XIP Build drop-down box in the Visual Kitchen permits selection of different Operating System Build Version Specific folders.
Advanced OEMXipKernel and MSXipKernel operations can be performed using the XIPPORTEREX & ROM tool.
SYS Folder
The system (SYS) folder is divided into Operating System Build Version Specific folders. The Build Version Specific folders will often contain files (packages) specific to the device DPI (Dot Per Inch) and Horizontal/Vertical display size.
Each Operating System Build Version Specific folder is further divided into a ROM DPI, ROM Resolution, and Shared folder – providing a significant amount of flexibility during ROM compilation.
The ROM DPI, ROM Resolution, and Shared folders are further divided into Locale Specific folders and a Common folder. The Common folder is typically used for system files (packages) that can be installed in any locale – not specific to a language. Locale Specific folders are typically used for system files (packages) that should only be applied to a specific locale – for example, 0409 (English).
Tip
The ROM DPI and ROM Resolution drop-down boxes in the Visual Kitchen permits selection of different Operating System Build Version Specific resolution and bit depth.

[TUT] Sous-Chef's Guide to Da_G's Ervius Visual Kitchen 9.7 ... continued
Preparing Your Facility
Before you can begin to cook your own ROM, you need to equip your facility with some Kitchen utensils. Your Kitchen is going to require a good Unicode & UTF-8 text editor; I personally use ConTEXT & Notepad. Another handy utensil to have is a comparison utility for date/file/binary comparisons; I use WinDiff & BeyondCompare. Some other utensils that you're going to require are: Microsoft ActiveSync, .NET Framework 2.x/3.x. You will also need an archive extraction utensil; I use IZArc, WinRAR, and WinZIP. You’ll also need a good Hexadecimal calculator; I use Windows Calculator (Scientific Mode).
It's also a good idea to ensure that your Kitchen remains "pest" free; common pest control services include AVG, McAfee, and Symantec anti-Virus. You'll need to add the RaphaelWrapper (OSNBTOOL.EXE) tool to your list of anti-virus exclusions as it may be detected as a "Generic Dropper (Trojan)".
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
To assist you in your apprenticeship, I have included a link to the Generic Visual Kitchen that I used to prepare this guide - the kitchen also includes a .DOC and .PDF format of this guide. The procedures were tested against a GSM Raphael device. I can’t confirm that these procedures will work on CDMA device ROM’s. Additionally, other device ROM’s may not be compatible with this kitchen format. Make sure to review the _README.TXT before you begin.
Generic Visual Kitchen, 17 MB
You’re going to need a RUU_SIGNED.NBH file; I used the following HTC Official Generic ROM – you’ll need to extract the contents of the .EXE and .RAR/.ZIP using an archive utensil.
[ROM] [WWE] Raphael HTC 5.05.405.1 Radio Signed (52.58.25.3 0,1.11.25.01)
http://rapidshare.com/files/1939660...igned_Raphael_52.58.25.30_1.11.25.01_Ship.rar
http://www.megaupload.com/?d=0F50UM5K
For the purpose of this guide, I will assume that you have added the C:\XDA\ folder, sub-folder, and files to your anti-virus exclusion list – at the very least RaphaelWrapper.exe – and that the contents of the Generic Visual Kitchen were extracted to the following folder.
C:\XDA\MY_VISUAL_KITCHEN
The guide is divided into the following sections:
Extracting the RUU_SIGNED.NBH Contents ....... 4
Reducing the .PAYLOAD File ................... 5
Extracting the XIP.BIN Contents .............. 6
Increasing the Data Cache .................... 7
Unlocking the Paging Pool .................... 8
Disabling Certificate Checking ............... 9
Reducing the Update Loader (ULDR) Partition .. 10
Changing the Unsigned CAB Policies ........... 11
Changing the Unsigned Themes Policies ........ 12
Changing the Remote API (RAPI) Policies ...... 13
Compiling the New RUU_SIGNED.NBH File ........ 14
Flashing the RUU_SIGNED.NBH File ............. 15
Advanced Topic: XIP Porting .................. 16
Sous-Chef's TIPs ............................. 17
I will attempt to provide an overview, the list of tools required, and the process to follow in each section. As you become more comfortable (and familiar) with the activities, you will find that you can consolidate (or skip) certain outlined steps. Incidentally, you'll probably want to keep these web links open in case you need to lookup some of the terms or concepts in the guide.
Acronyms
http://wiki.xda-developers.com/index.php?pagename=Acronyms
Glossary
http://wiki.xda-developers.com/index.php?pagename=Glossary
Development Resources for Windows Mobile
http://forum.xda-developers.com/showthread.php?t=445396

Extracting the RUU_SIGNED.NBH Contents
An .NBH is a signed group of modules or packages; they are typically comprised of .NB files. An .NBH can contain any combination of .NB files. An .NB file is a block of code that can be a Radio ROM, Operating System packages (XIP and IMGFS), Startup Splash Screen (or SPL).
The file we will be working with is the OS.NB file; it contains the ULDR, XIP, and IMGFS (OEM, SYS). To extract the contents of an .NBH file, we initiate the Ervius NBH/NB/PAYLOAD Dumper tool from within the Generic Visual Kitchen.
Upon completion, the following files will have been extracted: OS.nb, OS.nb.payload. Additionally, the Ervius NBH/NB/PAYLOAD Dumper tool creates a DUMP folder that contains all the files required.
Tools Required:
The following Ervius Visual Kitchen tool will be used for the RUU_SIGNED.NBH extraction activities.
Dump NBH/NB/PAYLOAD
Procedure
The following procedure initiates the ROM extraction activity via the Ervius NBH/NB/PAYLOAD Dumper tool built into the Generic Visual Kitchen. The extraction process can take a significant amount of time to complete.
Copy the RUU_SIGNED.NBH file to the C:\XDA\My_Visual_Kitchen\BaseROM\ folder.
Navigate to the C:\XDA\My_Visual_Kitchen\ folder.
Launch ErviusKitchen.exe.
At the multiple warning messages, click OK.
Warnings that may appear include:
Folder Not Found
Could Not Find A Part Of The Path
You Need To Specify … First
Click the Dump NBH/NB/PAYLOAD button.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\BaseROM\ folder.
Select the RUU_signed.nbh file and then click Open.
At the All Done... Nbh/nb/payload Dumped and ''Kitchen'' created Successfull!!! message, close the Ervius Visual Kitchen application.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\DUMP\ folder.
Move the sub-folders (and content) to the C:\XDA\MY_VISUAL_KITCHEN\ folder.
At the Confirm Folder Replace message, click Yes To All.
At the Confirm File Move message, click Yes To All.
Tip
The C:\XDA\MY_VISUAL_KITCHEN\BaseROM\Dump\ folder should be empty at this point – and can be removed.

Reducing the .PAYLOAD File
At this point, the Ervius NBH/NB/PAYLOAD Dumper tool has removed the contents of the IMGFS (OEM, SYS) from the .PAYLOAD file in preparation for changes to the ULDR and XIP. Removing the IMGFS (OEM, SYS) contents from the .PAYLOAD file reduces the size of the .PAYLOAD file making it easier to work with.
The Ervius NBH/NB/PAYLOAD Dumper tool has placed a copy of the reduced .PAYLOAD file in the C:\XDA\My_Visual_Kitchen\ROM\Raphael\ folder.
Tip
Advanced .PAYLOAD file operations can be performed using the XIPPORTEREX & ROM tool.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676

Extracting the XIP.BIN Contents
The Execute-in-place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. It is possible to use the XIP.BIN contents from a newer version of a ROM from a different device or a newer operating system. This is typically done by chefs who are looking for the most recent versions of system files from a specific device or version of an operating system – you'll eventually do the same.
At this point, the Ervius NBH/NB/PAYLOAD Dumper tool has extracted the contents of the XIP.BIN and placed a copy of the file in the C:\XDA\My_Visual_Kitchen\ROM\Raphael\ folder.
For the purposes of this guide, we will be using the same version of the system files.
Tip
Advanced XIP.BIN file operations can be performed using the XIPPORTEREX & ROM tool.
You can change the ROM Date/Version using the XIPPORTEREX & ROM tool.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
XIP Porting Guide
http://forum.xda-developers.com/showthread.php?t=379598

Increasing the Data Cache
File caching improves performance and also improves power management; when an application accesses physical storage, the storage device uses much more power. The less often physical storage is accessed, the longer storage devices spend in a low-power state.
By increasing the DataCacheSize registry value, you effectively improve the performance of applications that are file system intensive such as database and mapping applications – which results in lower physical storage access requirements. Drastically increasing the DataCacheSize however, may have adverse effects and slow the device down as a result of longer auto-compaction processing.
For the purposes of this guide, we are going to increase the current DataCacheSize value from 4MB to 8MB.
Tools Required
The following tools are required to adjust the DataCacheSize value.
Unicode Text Editor
Hexadecimal Calculator
Procedure
The following procedure will change the current DataCacheSize value of 4MB to 8MB.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\ROM\Raphael\20764\OEMXipKernel\ folder.
Launch a text editor and open the BOOT.RGU file.
Search for the following registry key entry:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\FLASHDRV\FATFS]
Locate the following registry value underneath the key:
"DataCacheSize"=dword:00000800 ;2048 sectors(2048*2048=4MB)
Change the registry value to the following:
"DataCacheSize"=dword:00001000 ;4096 sectors(4096*2048=8MB)
Save the BOOT.RGU file.
Exit the text editor.
Tip
Make a backup copy of the BOOT.RGU file before editing; delete the backup file when done.

Unlocking the Paging Pool
The Paging Pool serves as a limit on the amount of memory that can be consumed by pageable data. It includes an algorithm for choosing the order in which to remove pageable data from memory. Pool behaviour is typically determined by the OEM – Microsoft sets a default value for the paging pool, but the OEM can change that value. Applications do not have the ability to set the behaviour for their own executables or memory-mapped files.
For the purposes of this guide, we are going to apply a change to the kitchen_build_rom.bat to set the Paging Pool size (initially set to 6MB) to a new size of 8MB.
Tools Required
The following tools are required for the Paging Pool unlock activities.
Unicode Text Editor
Procedure
The following procedure will change the kitchen_build_rom.bat to set the Paging Pool size during ROM compilation.
Launch a text editor.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\Tools\ folder and open the kitchen_build_rom.bat file.
In the Find (Search) box, type:
implantxip
Add the following implantxip command line option:
-PP 8
Select the Save option in your text editor.
Select the Exit option in your text editor.
Tip
Spaces are usually required between command line options; the command line option should only appear once.
You can add output logging to file by adding the following command instructions to the end of a command line:
| ..\tools\mtee /+ ..\%LOG_FILE%
Newer versions of Ervius Visual Kitchen provide built-in logging and an Option button to set the Paging Pool size.

Disabling Certificate Checking
During the startup process of your device, the operating system verifies that each system file against an internal certificate store to ensure that each file is signed with a trusted certificate; if the system file is not signed, the file is ignored.
To allow execution of non-signed system files, we need to disable the internal certificate store verification. Once disabled, the operating system will trust all code installed regardless of its signature. This provides more control over the code that gets installed on the device – you no longer need to load and manually sign additional certificates such as those from the sdkcerts.cab into the device root certificate store.
For the purposes of this guide, we are going to apply a change to the kernel binary file which will disable the internal certificate store verification.
Tools Required
The following tools are required to disable the internal certificate store verification.
Unicode Text Editor
Procedure
The following procedure will change the kitchen_build_rom.bat disable the internal certificate store verification.
Launch a text editor.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\Tools\ folder and open the kitchen_build_rom.bat file.
In the Find (Search) box, type:
implantxip
Add the following implantxip command line option:
-NoCert
Select the Save option in your text editor.
Select the Exit option in your text editor.
Tip
Spaces are usually required between command line options; the command line option should only appear once.
You can add output logging to file by adding the following command instructions to the end of a command line:
| ..\tools\mtee /+ ..\%LOG_FILE%
Newer versions of Ervius Visual Kitchen provide built-in logging and an Option button to disable the Certificate Store verification.

Reducing the Update Loader (ULDR) Partition
The boot loader can accommodate multiple execute-in-place (XIP) regions where individual modules can be updated after the initial operating system image file has been written to the device – the ULDR is an example of this use. The Update Loader (ULDR) provides Flash-Over-The-Air (FOTA) capabilities permitting your carrier to issue changes such as Hotfixes over the cellular network – generally, most carriers avoid this practice.
As this is generally undesirable in a cooked ROM, since we are making modifications that a carrier Hotfix might roll back, we will reduce the partition. This will cause the device to report insufficient ULDR space to the carrier FOTA request … and the freed up space becomes available for our uses.
For the purposes of this guide, we are going to apply a change to the kitchen_build_rom.bat to reduce the ULDR – effectively providing approximately 3 MB of space.
Tools Required
The following tools are required to disable the internal certificate store verification.
Unicode Text Editor
Procedure
The following procedure will change the kitchen_build_rom.bat disable the internal certificate store verification.
Launch a text editor.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\Tools\ folder and open the kitchen_build_rom.bat file.
In the Find (Search) box, type:
implantxip
Add the following implantxip command line option:
-uldr
Select the Save option in your text editor.
Select the Exit option in your text editor.
Tip
Spaces are usually required between command line options; the command line option should only appear once.
You can add output logging to file by adding the following command instructions to the end of a command line:
| ..\tools\mtee /+ ..\%LOG_FILE%
Newer versions of Ervius Visual Kitchen provide built-in logging and an Option button to enable or disable ULDR reduction.

Changing the Unsigned CAB Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow execution of unsigned .CAB files, we need to change the default security policy settings that pertain to .CAB files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4101: Unsigned CABS Policy = 8
ID 4102: Unsigned Applications Policy = 1
ID 4122: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\OEM\Raphael\0409\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4101" value="8" />
<parm name="4102" value="1" />
<parm name="4122" value="1" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html

Changing the Unsigned Themes Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. If a signed theme file does not have a matching root certificate in the Software Publisher Certificate (SPC) store, the file is unsigned and is therefore not executed. To allow execution of unsigned Theme files, we need to change the default security policy settings that pertain to Theme files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4103: Unsigned CABS Policy = 16
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\OEM\Raphael\0409\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4103" value="16" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Customizing the User Interface of Windows Mobile Powered Devices
http://msdn.microsoft.com/en-us/library/bb416487.aspx

Changing the Remote API (RAPI) Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
The Remote API (RAPI) enables applications that run on a desktop to perform actions on a remote Windows Embedded CE-based device. This includes the ability to manipulate the file system on the remote device, including the creation and deletion of files and directories. Additionally, the Remote API (RAPI) functions can be used to create and modify databases, either in the device's object store or in mounted database volumes. The Remote API (RAPI) applications can also query and modify registry keys as well as launch applications and invoke methods on the remote device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow unrestricted access by remote applications to implement ActiveSync operations on Windows Mobile powered devices, we need to change the default security policy settings that pertain to the Remote API (RAPI).
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4097: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\OEM\Raphael\0409\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:

Ensure that the following lines are present in the section:

<characteristic type="SecurityPolicy">
...
<parm name="4097" value="1" />
...</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Remote API (RAPI)
http://msdn.microsoft.com/en-us/library/aa920177.aspx

Compiling the New RUU_SIGNED.NBH File
Brief Review
At this point, we have increased the Data Cache size, ensured that the implantxip command unlocks the Paging Pool and sets an initial size 8MB, disables Certificate checking, and reduces the ULDR. We changed the Unsigned .CAB policy, changed the Theme policy, and changed the Remote API (RAPI) policy.
This guide did not go into details about adding, changing, or removing ROM packages to/from the OEM and SYS folders. Additionally, the guide did not cover the steps required to port an XIP from a different ROM version or device – you'll eventually want to learn how to do these types of activities.
Compiling the ROM
We now need to assemble all of these changes into a new RUU_SIGNED.NBH file – this process if often referred to as ROM compilation. We are going to initiate the Create ROM tool from within the Generic Visual Kitchen to perform this process – there are newer versions of the Ervius Visual Kitchen available.
Tools Required
The following Ervius Visual Kitchen feature will be used for the RUU_SIGNED.NBH file creation activities.
Create ROM
Procedure
The following procedure initiates the ROM creation activity via a script that is included in the Generic Visual Kitchen. The creation process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\ folder.
Launch erviuskitchen.exe.
Click on the Device drop-down box and select Raphael from the list.
In the ROM Ver box, change the value: 5.05.405.1
Click the Create ROM button, the command window will begin to display processing information after a few minutes.
Wait for the All Done message to appear in the Bottom Status window.
Exit the Ervius Visual Kitchen application.
Copy the RaphaelWrapper.exe file from the C:\XDA\MY_VISUAL_KITCHEN\Tools\ folder to the C:\XDA\MY_VISUAL_KITCHEN\RELEASE_Raphael\ folder.
Tip
Processing information may take a few minutes before it appears in the Command window; this is a result of logging activity being spooled to logging files for troubleshooting purposes.
If the compilation is successful, the last three (4) lines in the Status window of the Ervius Visual Kitchen will display: ROM Builded successfull!!! Reenabling all skipped packages. All packages Reenabled. All done!!!
References
Visual multilang/multidevice/multibuild kitchen for last bepe rom-tools!!!
http://forum.xda-developers.com/showthread.php?t=469420

Flashing the RUU_SIGNED.NBH File
If you are reading this, you must have successfully compiled your RUU_SIGNED.NBH file and are now ready to flash it to your device … congratulations! Now for the disclaimer bit; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk.
Also keep in mind that you'll need to unlock your device before venturing into the world of ROM flashing. If you haven’t unlocked your device and applied the Hard SPL, you need to complete these tasks before you can proceed.
The ROM Flashing process is relatively straight forward. You need to ensure that you can connect to your device via the ActiveSync application. Once you have connected to the device, launch the RaphaelWrapper tool to flash your cooked ROM to your device – I suggest temporarily disabling your anti-virus software to avoid unforeseen problems.
Tools Required
The following tools are required to flash the RUU_SIGNED.NBH file to your device.
RaphaelWrapper
Procedure
The following procedure initiates the ROM Flashing activity. The flashing process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\Tools\ folder.
Copy the RaphaelWrapper.exe application to the C:\XDA\MY_VISUAL_KITCHEN\RELEASE_Raphael\ folder.
Navigate to the C:\XDA\MY_VISUAL_KITCHEN\RELEASE_Raphael\ folder.
Launch RaphaelWrapper.exe.
At the Welcome To The ROM Update Utility window, select the I Understand The Caution Indicated check box.
Click the Next button.
At the Follow The Instructions Below window, select the I Completed The Steps Indicated Above check box.
Click the Next button.
At the Current Information About Your PDA Phone window, click the Update button.
At the Verify That You Want To Update The ROM Version window, click the Next button.
At the You Are Now Ready To Update Your ROM Image window, click the Next button - allow the flashing process to complete.
Click the Finish button.
Tip
The current version of the PDA Phone ROM Update Utility 3.27.4.3 we are using has been modified to not format the device when only flashing a Radio, Startup Screen, or Operating System.
Your anti-virus may warn you that the RaphaelWrapper.exe contains the "Generic Dropper (Trojan)" – this is a false-positive indication; the .EXE is safe to use.
You can usually recover from a failed flash by copying a known "working" .NBH file to a MicroSD Card and starting your device in the Tricolour bootloader.
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
[Resources] Flashing your First GSM Raphael Rom (For Noobs)
http://forum.xda-developers.com/showthread.php?t=448008

Advanced Topic: XIP Porting
This guide is intended to help you learn how to port the Execute-In-Place (XIP) region from a new (donor) device for use in your kitchen; it will walk you through the process of extracting the contents of an Official ROM, obtaining the new (donor) device XIP, and porting the new (donor) device XIP into your kitchen.
[TUT] Sous-Chef's Guide to XIP Porting in Ervius Visual Kitchen
http://forum.xda-developers.com/showthread.php?t=526610

Sous-Chef's TIPs
Tips and techniques passed down from the senior chefs in the business.
Love .PROVXML's? Hate Not Knowing If It Worked?
http://forum.xda-developers.com/showthread.php?t=519548
[WinXP Script] Extend Search Companion
http://forum.xda-developers.com/showthread.php?t=490216
[Guide] How to create .LNK files and use parameters
http://forum.xda-developers.com/showthread.php?t=490447

13/02/2010: Tutorial Statistics
Views: 38,176
Guide Downloads: 1,353
Kitchen Downloads : 770

OEM vs EXT
So ive been out of the loop for a couple months, and the main place i am stuck is converting my old oem packages into the packages used in the new style kitchen. maybe a post with this info would be good too!
And good job, im sure this will help a lot of new cooks!

fallingup said:
So ive been out of the loop for a couple months, and the main place i am stuck is converting my old oem packages into the packages used in the new style kitchen. maybe a post with this info would be good too!
And good job, im sure this will help a lot of new cooks!
Click to expand...
Click to collapse
This post should get you going for now ...
http://forum.xda-developers.com/showpost.php?p=3959154&postcount=903

[KITCHEN] OS Builder V1.4.236 FULL (01.12.2012) - pro wm/wp7 kitchen by barin

Official XDA OSBuilder kitchen thread (developed by Barin)
this thread is dedicated to discussions related windows mobile
Official XDA OSBuilder 7 kitchen thread (developed by Barin)
this thread is dedicated to discussions/info related to windows phone 7
I'm honored to be allowed to officially announce/present/support osbuilder here in xda forums by barin. thank you.
this is a new kitchen (not based on old platform rebuilder) developed by asusmobile.ru member barin and tested by many others (mentioned below) including myself.
ultrashot is also developing some parts of osbuilder (custom imgfsfromdump with advanced parameter support for example).
"One word: SUPERIOR!" hd2owner
OS Builder V1.4.236 FULL (01.12.2012) - 3962+ downloads
OS Builder V1.4.235 FULL (25.11.2012) - 271 downloads (20590)
OS Builder V1.4.234 FULL (22.11.2012) - 91 downloads
OS Builder V1.4.223 FULL (02.10.2012) - 931 downloads
OS Builder V1.4.209 FULL (19.05.2012) - 2155 downloads
OS Builder V1.4.206 FULL (21.04.2012) - 531 downloads
OS Builder V1.4.205 FULL (16.04.2012) - 199 downloads
OS Builder V1.3.199 FULL (09.12.2011) - 4792 downloads
OS Builder V1.3.189 FULL (08.11.2011) - 1762 downloads
OS Builder V1.3.187 FULL (03.11.2011) - 159 downloads
OS Builder V1.3.163 FULL (29.09.2011) - 2183 downloads
OS Builder V1.2.157 FULL (20.09.2011) - 257 downloads
OS Builder V1.2.153 FULL (15.09.2011) - 157 downloads
OS Builder V1.2.148 FULL (04.09.2011) - 558 downloads
OS Builder V1.2.143 FULL (28.08.2011) - 412 downloads
OS Builder V1.2.140 FULL (21.08.2011) - 229 downloads
OS Builder V1.2.133 FULL (11.08.2011) - 337 downloads
OS Builder V1.2.124 FULL (28.07.2011) - 423 downloads
OS Builder V1.2.116 FULL (27.06.2011) - 1716 downloads
OS Builder V1.2.111 LE (08.06.2011) - 518 downloads
OS Builder V1.2.107 LE (05.03.2011) - 970 downloads
OS Builder V1.2.101 LE (21.02.2011) - 582 downloads
OS Builder V1.2.99 LE (19.02.2011) - 213 downloads
OS Builder V1.2.89 LE (31.12.2010) - 1244 downloads
Total osbuilder downloads on xda: 24552+
ATTENTION!
SINCE VERSION 1.2.81 (06.12.2010) OSBuilder IS DEPENDENT OF .NET FRAMEWORK 4 (runtime version not lower than 4.0.30319). Get .NET framework 4 here
DOWNLOAD (latest public osbuilder version by barin): OSBuilderSetup1.4.236-FULL.zip
OSBUILDER LATEST CHANGELOGS ->POST 3 & POST 4
NEW XPH COMPRESSION METHOD FROM WP7 MANGO
Since 1.2.153 we have possibility to use xph compression from wp7 mango (patched by ultrashot).
only usable on armv7 devices!! don't use xph on older arm devices! it won't work.
if you have a armv7 device and want to try xph->ultrashot's patched mango cecompr.dll thread
If someone wants to donate and help the project, take a look at the original thread on asusmobile.ru and the thread on mobileunderground.info
Many thanks to those, who helped to test osbuilder:
Alexx~, AndrewSh, greench, Lost_Angel, Vladimir1973
Special thanks to yad for the important and necessary information on relocation.
ENORMOUS thanks to alexx~ for many ideas and concepts, for THAT NOT VALUED! aid during the testing, and it is simple for the human support from the beginning also to the end of writing program.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Basic purpose of osbuilder
-assembling flat dump from the packets
-assembling IMGFS
-assembling ROM-File (for supported devices)
-extract/dump ROM-File (for supported devices)
OSBuilder can build NB0, NB and NBH files and for supported devices it can change rom version, date and/or some other data.
Also many other functions are included (Manila other language exclusion for example), which can be useful during creation and assembling of dump and ROM.
Basic possibilities
1. The group of packets (4 types of groups, the level of the nesting of groups is theoretically not limited, packets they are grouped by simple haul) and mapping packets and groups in the form of the tree
2. Convenient contextual menu for the work with the packets.
3. Selection of language for the piercing (co-existence of packets for the different languages)
4. Possibility to introduce detailed description for the packets and the groups (with the selection of packet or group description it will be automatically mapped into specially [otvedennom] for this window)
5. Import of configuration from the files of option.xml and their subsequent removal.
6. Retention of the configuration on silence and of any quantity of the configurations
7. Editing of dsm, rgu, initflashfiles, provxml of packet directly from the program
8. Possibility of the connection of external editors for dsm, rgu, initflashfiles, provxml
9. The survey of the folder of packet directly from the program (on silence conductor is used, but the connection of another file- manager is also possible)
10. Editing of boot.rgu, packages.sof, packages.cif, defaultcerts.dat, oem.cer directly from the program.
11. Survey and the editing of the order of assembling the list (it edits packages.sof)
12. The preliminary survey of the list, which must come out after assembling with the indication as and how often changed each parameter, such as file of rgu made change and in what line of the file of rgu this parameter is contained.
13. The preliminary survey of the file of initflashfiles.dat, which must come out after assembling.
14. Removal of files from modules and imageinfo.txt
15. Sufficiently flexible tuning of the parameters of assembling.
16. Possibility of the call of external programs from the menu.
17. Automatic forming or correction .VM and .ROM according to the data from the template or the file XIP
18. Built-in mechanism of readdressing the modules (Reloc) of the received flat dump.
19. Assembling the file of division IMGFS 20. Assembling file ROM - size of nb0 (payload)
program-window:
Contextual menu of the packet Built-in editor OF DSM (title)
the built-in editor OF DSM (modules and files)
the built-in editor OF DSM (dependence) information about the module Menu of additional tools
the editor of packages.sof (cif) Preliminary survey of list cleaning the modules Readdressing modules (Reloc) Tuning (parameters of assembling)
Program (assembling the files of payload NBH) is successfully tested with following HTC-devices:
HTC blueAngel
HTC touch 2 (Mega)
HTC touch of 3450 & 3452 (Elf of & Elfin)
HTC touch Of diamond
HTC touch HD
HTC touch diamond 2
HTC max 4G HTC Of iolite
HTC HD2
HTC HD mini
HTC kovsky (SE X1)
HTC WhitestoneW
If you have precise information about the special features of a certain new device model (structure of divisions and FLASH of regions, the signs of the search for date and version into nk.exe, and also other special features, for example, necessary whether to prescribe somewhere into nk.exe the sizes of rom, region etc, then the support of this can be added into osbuilder.
As to gather the dump without the template i tried to make the process of editing and assembling far more convenient and more visual. the result is osbuilder.
If you have ideas for improvements, write them down here and barin will take a look at them.
Tutorial Videos:
01-DumpNBH.zip
02-Grouping.zip
Manual:
WWE Manual Download Link
Multibuild feature (use more than one sys build):
http://www.mobileunderground.info/showthread.php?t=12348&p=42486#post42486
Porting XIP:
http://www.mobileunderground.info/showthread.php?t=12348&p=38546#post38546
http://www.mobileunderground.info/showthread.php?t=12348&p=38615#post38615
http://www.mobileunderground.info/showthread.php?t=12348&p=38829#post38829
Setting Package Build Order:
http://www.mobileunderground.info/showthread.php?t=12348&p=38558#post38558
Exclude/Include specific packages:
http://www.mobileunderground.info/showthread.php?t=12348&p=38622#post38622
OEM creator for EXT to OEM Conversion (another tool by ultrashot coming soon):
http://www.mobileunderground.info/showthread.php?t=12348&p=38919#post38919
Getting Started:
http://www.mobileunderground.info/showthread.php?t=12348&p=38859#post38859
List of supporters (fullversion):
Code:
Alexx ~, AndrewSh, HD2Owner, 3D MASTER,
ash172, bitje, Elesvil, erickwill, Feropont, fq3803, Gangsta-P,
Pgreench, GUG, Hellonasty, indagroove, Kristof Petho, LiquidStorm,
mishok_006, mondi, Mor-Da, MorzeCBP, mwalt2, NarkoZ,
NightOWL, Petrovych, rewwps, Satan!, serfer222, SergeyLAR,
tian tian, ultrashot, usv, Hacker, Zloy Pryanik, Vladimir1973
Other great tools by barin:
OS Builder 7 (WP7 Kitchen)
LEO Advanced ROM Update Utility
Titan Advanced ROM Update Utility
Mozart Advanced ROM Update Utility
Blackstone Advanced ROM Update Utility
Topaz Advanced ROM Update Utility
Kovsky Advanced ROM Update Utility
Whitestone Advanced ROM Update Utility
HTC Splash Tool
My projects:
HD2O ROM Series
X1O ROM Series
HTC HD2 stock ROM overview thread
Latest Opera 9.70 thread
HD2 WP7 donation fund for da_g
HD2 haret/linux/android donation fund for devs (cotulla, dcordes, markinus, letama, netripper)
HD2 6.5.3 global bold font fix (by ultrashot)
HD2Owner's youtube channel

TIPS & FUTURE CHANGELOG (web translation)
TIPS:
packages.sof/cif
i found it less complicated to re-build this lists myself than re-order the existing ones.
if you want to edit existing one:
-go to editor (packages.sof and cif same procedure)
-press "remove all missed" button
-mark all new packets you added on the right side
-place "cursor" on bottom of left side
-add packets from right side on bottom of left side with "move to packages.sof" button
if you want to re-order yourself, i am using this order currently (htc hd2 512mb):
-msxipkernel
-msxipkernelltk
-oemxipkernel
-langdb
-wincenls_xxx
-metadata (according sys version)
-oemdrivershigh
-os (according sys version)
-adobe flash (sys) (notice: make sure browsing is after browsingcore)
-....
-....(all sys packages)
-EXT/sys_fwupdate_mini (see tutorial videos)
-EXT/sys_sqm_mini (see tutorial videos)
-OEM/BuildInfoPkg
-....
-....(all OEM packages)
-AdobePDF
-....
-....(all OEM ext packages in oem format)
-All custom apps
-All custom mods
HD2 WM KITCHEN EXAMPLE (TEMPLATE):
DOWNLOAD HD2O template kitchen v1.1 (htc hd2, 14 languages supported; wm6.5.0/wm6.5.3)
DOWNLOAD HD2O template kitchen v1.15 patch
DOWNLOAD HD2O template kitchen v1.16 patch
OS Builder HD2 Template Kitchen v1.15 (27.07.2011) - 554+ downloads
OS Builder HD2 Template Kitchen v1.0 (21.06.2011) - 386+ downloads
template kitchen changelog:
v1.16 changes (03.10.11) patch
-xph compression integrated
v1.15 changes (27.06.11) patch
-lockscreen issue fixed on 6.5.3
-lockscreen media controls added
-lockscreen slider in middle instead top
-configurations adjusted
-packages.sof/cif adjusted
v1.1 changes (27.06.11)
-packages.sof/cif adjusted (now stock order)
-some sys packages of both builds adjusted (packages.sof related)
-ext packages cleaned
-paths in osbuilder settings adjusted (sorry, now fixed relative paths)
-wince.nls for asian roms added (only replace in rom if cooking asian rom)
-other minor changes in oem (mui's etc)
notes about template kitchen:
-all configs for 14 languages included (28 configs, 6.5&6.5.3) incl. manila exlusion list
-oem packages merged as far as possible if useful
-all "ext" language folders merged into one folder for each language for better overview
-if you are cooking chinese rom, replace wince.nls in rom with one from asian leo rom
-if you add your own apps, generate new dsm and add it on bottom of packages.sof/cif with built in editor
-navipanel, jetcetprint, copilot and jbed removed
-very close to stock but restructured
For chefs coming from a platformrebuilder kitchen i will add a tool by ultrashot to convert ext to oem later (osbuilder uses only oem packages).
you can use this for now - link

LATEST CHANGELOGS (web translation)
OSBuilder V 1.4.236 (01.12.2012)
Code:
1. Serious internal issue is fixed
OSBuilder V 1.4.235 (25.11.2012)
Code:
1. Fixed a serious issue that occasionaly appears while generating the version of the package by default
OSBuilder V 1.4.234 (22.11.2012)
Code:
1. Internal processing algorithm of XIP packages is changed (NK, SLDR)
2. Configuration menu item "Group language packs" is added. In the packages view tree (for packages selecting) the package group LANG is created and language packs are grouped into subgroups by codes (eg 0419, 040C, etc.) and placed in the LANG group.
3. More detailed information is displayed about the versions of packages (Tools -> Packages versions (DSM))
4. Saving files in editors of sof / cif, dsm and certificate files is now possible by hotkey Ctrl-S
5. In sof / cif editor - added the ability to automatically select all the language packs at the right window (see the toolbar)
OSBuilder V 1.4.223 (02.10.2012)
Code:
1. "Copy path to clipboard" item is added to Package context menu.
2. Files with nbh, nb, esco, nb0, payload, ffu extensions are associated with Dump Tool. Warning! Dump Tool works only with FFU WP7 files. All attempts to open FFU WP8 files will return error.
3. For WP7 second generation devices: logo file generator is added to Tools/Built-In.
4. Added ability (Additional tools) to view the policy.xml files (like provxml files - processing order and editing)
5. Added context menu of the kitchen root folder path (lower left corner of the main window) – possibility to open in a file manager or the command line, also possibility to copy the path to the clipboard
6. DSM Editor: added ability to set flags Boot hive and Allow Downgrade. Also added the opportunity to set the flags DIFF and DEL for FileEntry
7. In Tools/Built-In: added Cab Builder, allowing to create Cab file from the folder with files and to sign it with the certificate.
8. In Settings: changed an option to automatically include 0409 packages to rom. Now it's 0409/0809
9. A hell of internal changes in routines of processing and assembling
OSBuilder V 1.4.209 (19.05.2012)
Code:
1. Minor improvements in registry parser
2. Minor improvements in WMSTORE and NBH generators
OSBuilder V 1.4.206 (21.04.2012)
Code:
1. Dump tool supports esco files completely. You don't need to extract boot.img from esco files youself. Just open original esco file in Dump tool.
2. Minor improvements in Complex RGU
OS Builder V1.4.205 (16.04.2012)
Code:
1. New settings form
2. More responsive UI
3. WMSTORE rom format support.
4. Significantly updated D000FF support. Thanks, Andim! !!!Be VERY careful with maximum ROM size!!!
5. Automatic o32_dataptr fixing - important for system updates
6. WP7 DSM support improved. New module size calculation subroutine.
7. WP7 page pool changing support. (!) You have to keep original not patched NK, otherwise pool won't be changed during building.
8. Package file browser performance improved.
9. Simple algorithm against ROMs with hexed headers added. No need to use such protections anymore.
10. Language packages sorting function added to CIF/SOF editor.
11. RGU: Now OSB ignores most of errors OEMs and MS got used to.
12. SLDR certs edit button.
OS Builder V1.3.199 FULL (09.12.2011)
Code:
1. Removed NBH dialogue, which earlier could be called during the ROM building (correspondent checkbox and timer are removed from settings)
2. Context menus allowing moving packages are added to the Packages.sof / cif Editor.
3. The possibility to drop packets (drag and drop) is added to the Packages.sof / cif Editor. Drag and drop mode button switch is in the toolbar (see tips). In drug-n-drop mode packets multiple files selection is unavailable, you can drag and drop the package from the right side to the left or move the package to the left.
4. The ability to dump the IMGFS section file is added in Dump Tool (for example - one extracted from the ROM imgfs.bin)
5. HTC NBH Extractor tool is added to the built-in utilities. Use it to extract sections (nb files) from NBH file. See menu Utilities-> Built-in (Menu Tools-> Built-in)
6. The ability to display and handle package flags Reserved, Uldr / Sldr, Regular, etc. is added to DSM Editor.
7. The ability to extract SLDR1/SLDR2 packages from template to ROM \ SLDR folder is added (See additional. Tools-> Templates)
8. The ability to automatically rebuild SLDR and add custom certificate to its dat files is implemented. SLDR can be rebuilt either from template or from packages in your ROM \ SLDR folder.
9. The ability to save the module as a file MNGE is added in the ModuleInfo (see Toolbar ModuleInfo). You must specify the Vbase module address with which it is stored in MNGE in the dialog box before saving it.
10. The ability to apply a DIFFBIN patch is added to the ModuleInfo (see Toolbar ModuleInfo). Before patching you must specify the address of the module Vbase for applying the patch in the dialog box.
11. The ability to write a file in MNGE format is added in FileInfo (file is implicitly converted to a module and then stored in MNGE format). Original will stay unchanged, if you don’t specify Replace the original file in Save File dialogue.
12. Added the ability to build the file NB (D000FF) with sections written in the DIRECT_MAPPING form. This process uses only the template, so the base NB file is not needed. This method improves ROM performance. I want to warn you that updates (cab) in this case will setup slower, but thanks god – we don’t have them every day. The corresponding checkbox can be found in ROM files and Formats settings.
13. Added the ability to upgrade the kitchen packages directly from cab files (see Additional Tools). You can update all the packages except Reserved. While upgrading first packages versions will be verified the and in case of successful validation updates will be permitted. In any case, it is recommended to do kitchen Backup before upgrading. If the updates contain Canonical packages, which just added to the kitchen but do not replace existing packages, then after the update it is recommended to check packages .sof / cif
New tutorial video about pakages.sof/cif editing can be found in the first post
OS Builder V1.3.189 FULL (08.11.2011)
Code:
1. For WP7 devices: added the ability to build the LOGO partition from custom BMP, JPG or PNG files, and to substitute original LOGO partition of ROM (in the D000FF container ).
To enable Custom Logo - go Settings/Build Dump and ROM and toggle the appropriate checkbox. Also specify custom image file(s) you are going to use in LOGO. Pictures should have a resolution 480x800.
2. Fixed a bug that could occasionally appear when porting / rebuilding NK WP7 - post [URL="http://forum.xda-developers.com/showpost.php?p=19149336&postcount=50"]http://forum.xda-developers.com/show...6&postcount=50[/URL]
OS Builder V1.3.187 FULL (03.11.2011) - supports WP7 ROM building
Code:
1. Fixed issue with deleting a parameter defined in boot.rgu, if the removing directive was stored in other packages - the post http://forum.xda-developers.com/show...&postcount=564
The second step to full WP7 support
2. Relocation engine is totally redesigned. (Hats off to Ultrashot for valuable help with WP7 modules Z .reloc sections)
3. Added possibility of porting/rebuilding XIP (NK) and the assembling IMGFS partition file for Windows Phone 7 with real registry recompiling and relocations according to WP7memory model (tested on HTC HD2, HTC HD7 and HTC Mozart. Credit for tests goes to Feropont and HD2Owner)
I want to warn that the registry files have to be checked by registry preview, because there is a hell of syntax errors in the original registry. Frankly, it seems (IMHO) that first the registry was generated and then some comments for dumb and mistakes were added.
Registry Preview will define incorrect lines to help you to fix that. The most common errors are:
- Parameter name without the quotes
- The comments are not marked with a semicolon or marked with colon.
- HEX type values end with point (the last or the only parameter line)
- The value MULTI_SZ contains comments between the lines parameter
- Existence of Directives for conditional compilation IF ... END (it's not a mistake, but currently these directives are not processed, so you should label them as a comment)
4. The dsm-editor has now the feature to set/clear Z-flags for modules.
Warning! This flag is used for WP7 XIP modules only if the RW section of a module must be located within the boundaries of RAMStart-RAMFree (nk.exe, kernel.dll, kitl_noplat.dll and similar)
5. For WP7 - Added ability to edit the file MsDefaultcerts.dat (see Additional Tools)
6. For WP7- Added ability to edit files CoreOS.dat and initobj.dat (see Additional Tools)
7. Added ability to automatically insert a certificate which will sign files while assembling DefaultCerts.dat and MsDefaultCerts.dat (for WP7) - see the settings in Build Dump and ROM. The original files stay untouched.
8. XIP Port settings - added the list of additional MS packages (for WP7). When porting WP7 XIP, the packages specified in this list will be replaced with donor packages.
At the moment, we can safely add the following packages to this list:
BaseDrivers_NK
CCFGSVC
GFX_NK
KFPCRT
Watson_Core
WinCENLS
9. In Configuration and packages tab of Setting - added the option "Always include 0409packages." If your WP7kitchen allows the language selection, it is recommended to use this option enabled to include English-language packages by default to your ROM, otherwise there is risk to get non-bootable ROM.
10. Added - the ability to build NB files (! For the moment only D000FF container !, NB assembling for the new _wmstore structure devices is not supported yet) and NBH files for WP7
To build NB you should have the original NB and should define the way to it in Build ROM settings, for example ".\NB\OS.nb". Unfortunately, to get rid of the original NB is not yet possible, but the work is in process. Hats off to AnDim for help and information provided. NBH build configuration settings are similar to the previous version, except that the CID tab can contain multiple values (each value in a separate line)
Warning! If you plan to use for cooking WP7 dump obtained by earlier versions of OSBuilder, I would strongly recommend you to dump again, and to copy the new ROM template \ ROM.tpl to your kitchen. The new template will contain additional service information, which was not recorded in earlier versions of OSBuilder
11. OSBuilder is fully backward compatible with WM6.x kitchens, (it was a big deal btw, but it was implemented). When you open the kitchen OSBuilder automatically detects the required mode WM6/WP7.
This compatibility will remain for the future, but no new features for WM kitchens will be added. OSBuilder WM Kitchens Development is terminated due to the termination of WM6.5.x development from MS side.
Thanks again to the team (AndrewSh, Feropont, Vladimir1973) - for the support, for the tests, for your work!
Special thanks to HD2Owner for enthusiasm and his titanic work in testing WP7mode.
Thanks a lot to AnDim for his tenderness and important information provided.
Sincerely,
Barin and Ultrashot
OS Builder V1.3.163 FULL (29.09.2011) - supports WP7 ROM dumping
Code:
1. The first step to full WP7 rom assembling support - Added ability to dump HTC WP7 ROM (either with the FLPART structure, or with _wmstore structure - like Eternity or Omega roms).
Advanced Dump Tool also supports extracting sections, packages, modules and files from WP7 (HTC) ROM file.
WARNING! DO NOT ATTEMPT TO ASSEMBLE WP7 ROM WITH OSBuilder OR TO USE TPL Builder TO CREATE A WP7 TEMPLATE!!!
Special thanks to: AnDim, AndrewSh, Ultrashot, xb0xmod (xda)

CHANGELOG (web translation)
OS Builder V1.2.157 FULL (20.09.2011)
Code:
1. Added possibility to convert files to modules for WP7 files
2. To FileInfo menu - added possibility to convert file to module at a place (replacing file by the module or saving module to any folder/disk and leaving the file untouched).
3. Added possibility to select separate packages in XIP (drag and drop into the tree to select the package). This feature is recommended in case if XIP is assembled from packages in your ROM folder, or the packages from ROM folder are used as your OEM XIP
4. Added possibility to compress separate XIP objects. That feature reduces the amount of Physical Space and thus it can free-up some RAM. To specify that you want to compress an object, you must set up Flag C (full file or module compression) or Flag R (compression of all sections of module except those containing code) in DSM Rebuilder/Files and Modules tab.
Setting the Flag C for the filesys.exe module – works without any problems
Setting up C flag to the other modules can cause un-bootable ROM.
Example for LEO (tested on several devices):
Do not even touch dlls marked with Flag K
Code:
----------MSXIPKernel----------
For all files - Flag С
Modules:
coredll,dll - Flag R
device.exe - don’t touch
filesys.exe - Flag C
imgfs.dll - don’t touch
initvmmap.exe - don’t touch
regenum.dll - don’t touch
the rest of dll - Flag R
----------OEMXIPKernel----------
For all files - Flag С
Modules:
nk.exe - don’t you even think about touching it!!!!!!!!!!
cecompr.dll - don’t touch
QCBPM.dll - don’t touch
rpc_pmem_client.dll - don’t touch
wce_pmem.dll - don’t touch
the rest of dll - Flag R
----------WinCENLS_WWE----------
wince.nls - Flag С
With that above mentioned settings and squeezing nk RW sections in RAM – about 0,5 Mb of Program Memory (RAM) was added.
Changelog for OS Builder V1.2.153 FULL (15.09.2011) - now with XPH support
Code:
1. While registry preview or rom-cooking: if reg settings are not tied to a key (after removing the key directives), a comprehended syntax error indicating the line is displayed
2. Reloc engine is modified – now Reloc and Recmod is supported for WP7 Modules (REVERSMOD – still under development) for all new fixup types (3 - IMAGE_REL_BASED_HIGHLOW, 5 - IMAGE_REL_BASED_ARM_MOV32A and 7 - IMAGE_REL_BASED_ARM_MOV32T)
3. Added support for XPH compression - see the settings in Build Dump and ROM.
! ATTENTION!
To enable XPH compression – you would also replace cecompr.dll for that library in XIP.
It’s cecompr.dll ported from Mango WP7.1. Guy in charge – ultrashot (who doubts?) Thanx to him for fixing ordinals in the import table for WM6.5 compatibility.
Warning! This library contains the ARM v7 instructions, so it will only work on devices that support these instructions ( particularly on devices with a processor Snapdragon - like HTC HD2)
OS Builder V1.2.148 FULL (04.09.2011):
Code:
1. IMGFS assembling engine now supports paths and object names in UNICODE. (Hats off to ultrashot)
2. Several internal fixes (not visible from UI but important)
OS Builder V1.2.143 FULL (28.08.2011):
Code:
1. The item ZeroLength is added to UL partition drop-down menu (Settings\ Buid Dump and Rom) - ULDR partition is physically removed, but the record about it remains in the Partition Table (SectorsBefore = 0; SectorsCount = 0). In my opinion this is the most viable option for the removal of ULDR. (Here "my opinion" means the opinion of Barin but I would say that this feature removes a lot of bugs - especially if you build so called "empty" roms).
2. The option "Remove flag IMAGE_SCN_COMPRESSED" is added to Advanced IMGFS compression options. This option helps to avoid the idle invocation of the function CEDecompres and thus speeds up the loading of modules.
3. The check-box “Group modules at the beginning of IMGFS partition" is now available in Settings/Build Dump and Rom. Don’t use this option cooking for 6.0-6.1 nk devices and old devices. Good for Leo and other stuff like that. (feature is checked by Barin - for Asus P750, ultrashot - for X1, me - for Asus P525)
OS Builder V1.2.140 FULL (21.08.2011):
Code:
1. The random bug occurred sometimes while cleaning code from resource files - fixed
2. The code of several dlls and executables contains the useless invocation of CePerf.dll (module containing functions of monitoring and logging performance) - needed for debugging purposes only. This test fails to generate results if CEPerf.dll - dependent logging library - is missing. As far as we operate with ready MS Build - we don't need it. But this useless invocation spoils system time and resources. (The idea and cleaning algorithm - by ultrashot)
So now it's possible either to completely remove CEPerf.dll invocation from all files and modules containing it, or do it on the fly while assembling rom (leaving the original files untouched).
3. Earlier it was possible to manually add BuildImgfsGroupModules parameter to osb file to regularize modules and files in IMGFS. Now it's a default feature - while assembling IMGFS first all modules are processed, than all files...
4. When "Merge all Packages to one" option is toggled - registry assembling is highly optimized.
OS Builder V1.2.133 FULL (11.08.2011):
Code:
1. The ability to digitally sign cab and tsk files while assembling the rom (as it was for executable files in previous versions) is added. You can add cab or tsk files to the “sign files” list to sign files either manually or using the context menu of the package.
Not only target file itself is signed, but also all executable files inside it. The originals (source files) stay untouched.
2. The tool Cab/Tsk Signer is added to built-in utilities. With it you can sign cab and/or tsk files.
You can select either a single file or all files in a folder. It is possible to create a cab file to install the certificate, as well as the opportunity to add a certificate in _setup.xml of the cab file.
3. The item ‘Quick registry assembling” is removed from Settings/Build DUMP and Rom if packages are merged. Now this option is hidden but selected by default. If Merge All Packages to One checkbox is toggled - the rapid registry assembling algorithm will be executed. If this checkbox is cleared – registry assembling will be usual (old-fashioned).
4. The ability to sort / clean rgu files is added. Provides sorting/cleaning either the separate package rgu (via the package context menu), or all rgu files in the kitchen with a possibility to make a choice between EXT, OEM, ROM and SYS or all of them (Additional Tools-> Cleanup-> Sort / clean files rgu).
While sorting / cleaning process: double values will be removed from rgu (in case of different values of the same parameter the last value will be saved, as during the regular registry assembling), the removal directives for keys and values will be moved to the beginning of the file. Keys and values are sorted alphabetically.
If the key and value with OEM version (HKEY_LOCAL_MACHINE \ SOFTWARE \ OEM \ MASD) is present, it will be moved to the end of the file.
IMO optimized by this option rgu files are much more readable.
Remember that when sorting/cleaning rgu all comments will be deleted!
5. While installation OSBuilder sets association with hv files. You can open it for viewing just double-clicking it in Windows Explorer.
6. Registry comparer is added to Tools/Built-in. It can compare the contents of rgu and hv files, export to rgu either separate keys, or the difference obtained when comparing files.
OS Builder V1.2.124 FULL (28.07.2011):
Code:
1. Fixed some minor issues in Complex RGU
2. Added new features in IMGFS assembling - completely redesigned (actually written from scratch) utility for IMGFS assembling (Hats off to ultrashot for that work) .
In the configuration menu: added item "Advanced IMGFS compression options" (with a list of files / modules and additional compression options for sections in modules). Modules / files included in the list – will appear non-compressed in IMGFS. There is also a possibility to search and add all graphic manila files to that list (with signature QTC1)
Building the list - it’s possible to use templates, such as *.png, *.jpg. If someone wants to build a fully uncompressed section, just type *.* in the list.
Additional options of the modules sections compressing allow you not to compress the separate module sections containing code and / or RW sections of all modules, regardless whether they are in the list or not.
It’s also possible to control the compression of files/ modules setting flags U, R and S.
R flag can be used only for the modules. Flags U and C can be used for both modules and files. Flags in dsm have a higher priority than the list of Advanced compression options.
If you set U flag for a file or module in dsm editor, that file or the module will not be compressed in IMGFS not depending upon whether it is in the list or not.
If you set R flag for a module in dsm editor, then only the resource section of this module will be compressed in IMGFS.
If you set C flag for a file or module in dsm editor, the file or module is fully compressed in IMGFS not depending upon whether it is in the list or not.
Setting all flags U, R and C for the same object is not allowed. The built-in dsm editor will return warning.
The flag C has the highest priority among the flags.
3. In the configuration menu: added item " ?????? Demand paging ??? ???????." – sorrowfully it’s not correctly translated into English – will be fixed later. That means: The prohibition of "Demand paging" feature for modules.
The flag IMAGE_SCN_MEM_NOT_PAGED will be set up to the headers of modules in that list and also it will be set up to the modules with M flag in dsm
Wildcards such as *. exe are allowed in the list.
4. The item "Compress XIP even if it is not compressed in the ROM template." is added to Settings/Build Dump and Rom (reduces rom size for 1,6 Mb)
OS Builder V1.2.116 FULL (27.06.2011):
Full version - to the masses
Code:
1. In the Personal Data Generator in Wi-Fi setup added WPA2 and WPA2-PSK
2. In add. configuration property added to the item "Remove the attribute R with non-executable files." Attribute is removed directly into the headlines IMGFS (the originals stay untouched). The idea belongs to the distinguished Ultrashot.
Those who are transferred from the LE version to the FULL, be sure to read the post http://asusmobile.ru/board/viewtopic.php?p=336183 # 336 183
OS Builder V1.2.111 (08.06.2011):
Code:
1. Added scroll bar of the window of exceptions (the settings dsm) - Post http://asusmobile.ru/board/viewtopic.php?p=332069 # 332069
2. In the Personal Data Generator element in the list is opened for editing, not only the context menu, but doubleclick - post http://asusmobile.ru/board/viewtopic.php?p=332069 # 332069
3. To Dr.Freezer icon_smile - In the section [PortEngine] option has been added XIPPortKeepMSXIPDsm (default = False). When set to True XIP'a assembly is similar to version 1.2.1981 and earlier.
FULL VERSION:
4. When you open the list to set the flag in the configuration menu SHARED warning is issued only once per session
OS Builder V1.2.107 (05.03.2011):
Code:
1. Fixed a glitch with the cleaning of temporary folders in the Temp - post http://asusmobile.ru/board/viewtopic.php?p=331389 # 331389
2. Improved Personal data generator. If any field in the tab "Owner" does not fill these fields in the registry is not set to zero - a post http://asusmobile.ru/board/viewtopic.php?p=331437 # 331437
3. The path to the configuration file is transferred into an environment variable _CFGFILE (if the file exists)
4. In the configuration file in section [OSBuilder] option has been added WriteLogsToLOGFolder. If it is set to True, the log files will be written in assembly LOG folder in the root of the kitchen. The folder will be created automatically.
At the beginning of the assembly, this folder will be automatically cleared to logic from different assemblies are not mixed together. I consider this feature useful if enabled Auto clear folder TEMP.
5. Accelerated preprocessing (in the case of rewriting a large number of modules / files)
6. Fixed a throwback to boot.rgu - post http://asusmobile.ru/board/viewtopic.php?p=331579 # 331579
IMHO at this point has long been unnecessary, because the packets from XIP'a be learned all at once.
7. In the setting of the assembly item is removed, "an error message in case of duplication of files and modules for rewriting. By paragraphs "Override automatic ..." and "Confirmation".
8. Hung on the F5 key update, but at the start of the assembly F7
FULL VERSION:
9. Improved Complex RGU. Now you can view the remote key (Screenshot)
By doubleclick file is opened or rgu provxml, which removes the key. By pressing a button at the end of the line will state the key at the time of removal.
Switch to normal or deleted keys is carried out in the menu "View -> Remote Keys"
10. Fixed problem with saving the list of modules unmovable.
11. In the package for recmod allowed any modules, regardless of the settings
12. In Module Info / File Info added ability to set / unset the flag for the SHARED section RW. Author of ideas - respectable Ultrashot. All actions at your own risk.
13. In the configuration menu added to the list to set the flag for RW SHARED sections and modules. In assembling all files in / modules list will be flagged for RW SHARED sections. The originals are not touched.
14. In setting the item was added to "sign the files from the list of SHARE RW". No comments.
During the test items 12-13 special thanks Alexx ~, AndrewSh, Ultrashot, Vladimir 1973
OS Builder V1.2.101 (21.02.2011):
Code:
1. Fixed minor issues if OsBuilder is used in multilingual mode (several configurations for several rom languages)
2. Added the possibility to run SINGLE exe file with arguments while device first boot. Exe file will be executed after importing other Personal settings. The execution order corresponds to the order in the list.
3. Fixed English interface issues in Personal Data Generator
OS Builder V1.2.99 (19.02.2011):
Code:
1. Fixed package description window size (5 lines, 120 pxl)
2. Built-in HTC Splash Tool added - you can create Primary и Secondary boot Splash WVGA (480x800) in NB or NBH format. You can also extract image from NB splash. See Menu Tools -> Built-In.
3. Built-in HTC NBH Builder Tool added
– allows to create NBH file from NB files. You can import NBH header parameters from settings, registry or NBH file. Files and code sections are added and deleted using the context menu.
Sections, which should be included to NBH must be toggled in checkboxes. You also can save your settings in a separate file. See the menu Tools -> Built-In.
4. For HTC-LEO - in case when the date and time sync failed on first start - date and time of the ROM creation will be added.
5. Several improvements in assembly and merge dsm algorithm
6. Fixed a problem with new versions of Yandex-maps
7.The option RomConfirmOverwrite has been added to the section [OSBuilder] of configuration file. If the parameter = False, then the assembly of the ROM process does not display “Over-write?” dialogue (the file is automatically overwritten). By default, this option is True
8. Built-In Personal data generator tool is added
– see Additional Tools - Personalize. You can pre-enter owner name, Wi-Fi settings, mailboxes, VPN connections and favorites.
You can add, delete and change personal data by using the context menu.
Favorite links found in OEM provxml files are added automatically to the top list. Toggle correspondent checkbox if you want them to be added to Favorites. You can add your custom Favorites in the bottom list via context menu.
Personal data is stores in the root of OEM folder in the file Personal.dat. You can save it in menu File->Save to OEM.
To integrate your personal data to your custom rom you should go to Configuration Menu->Advanced Settings->Write Personal Data (toggle checkbox)
Full version:
9. Added the possibility to save personal data (paragraph 8) in a readable xml (provxml) file.
Keep in mind that not all data can be imported during provxml runtime.
OS Builder V1.2.89 (31.12.2010):
Code:
1. From tuning of assembling XIP' and are removed the points of the removal of the files of dsm and other files of rgu. The files of dsm and rgu (besides boot_ms.rgu and boot_oem.rgu) are moved away depending on the state of the button of the association of packets into one in. If it is selected to unite packets into one, then with XIP' and dsm and rgu from it will be removed. You remember that if you will use XIP with completely [udalennymi] of dsm in other kitchens, which do not consider the absence of dsm in XIP' e, then in the window Of about (information about the system) in you can be absent version OS CE!
2. In the window with the list of modules L is added the contextual menu, which makes it possible to open module or file of dsm, in which is contained the record about the module. Also with the aid of the contextual menu it is possible directly to establish or to remove flag L into dsm for the selected module
3. On the request is added the possibility of cleaning the resource modules/of files directly in the kitchen, but not only during the assembling. You be attentive! Confirmation will be inquired only one time, the then selected originals will be purified.
4. Is corrected omission into DumpTool - post [url]http://asusmobile.ru/board/viewtopic.php?p=325559#325559[/url]
5. In the form of cleaning the files of manila is added contextual menu (Select of all, Invert of selection)
6. In the form cleaning the files of manila is reflected only those languages, whose files are not located in the list of the exceptions of configuration.
7. In the form of the list of exceptions for the configuration is added the button of " To remove from the list the files of *manila"
8. In the self-correction of dsm it completed the correction of versions. Are corrected both the versions of packet and its interface and the versions of dependences. Are corrected all packets in SYS, ROM \ OF XIP, and also OEM_*, OEMDrivers*, LangDb. In the packets, which relate to OEM the number of [bilda] is set equalequal to zero. [Defoltnye] data for the version are formed in the dependence on the tuning DSM (on silence they are taken from the packet OS)
9. Now and into [pablik] of the version: Quotation: In Dump Of tool is added the additional tool, which makes it possible to extract divisions, packets, modules and files directly from the file ROM ([Skrinshot]1 Of [skrinshot]2 Of [skrinshot]3) COMPLETE VERSION:
10. In addition to point 3 is added the possibility of the signature of the purified files by certificate (point of contextual menu)
11. Is added the possibility of the auto-signature of the files of resources, purified during the assembling. See tuning the assembling dump and ROM
OS Builder V1.2.81 (06.12.2010):
Code:
Attention! Beginning from the current version Of oSBuilder it is re-aimed on .NET Of framework 4.0. See large [kra]c[nye] letters in the cap
1. the problem, connected with the list REVERSMOD - post [url]http://www.mobileunderground.info/showthread.php?t=12348&p=60619#post60619[/url]
2. the problem, connected with the record of the files of tuning the configuration Of oSBuilder' and into the dump - post [url]http://asusmobile.ru/board/viewtopic.php?p=323581#323581[/url]
3. Is corrected omission into ComplexRGU (parameters Of default and @ they are processed as one parameter. Earlier in one key was possible mapping @ and Default as the different parameters). With the search for the parameter Of default in the line of search can be introduced both Default and @
4. The editing of dsm of packet is additionally hung to the key F3
5. Rewrote in its own way RECMOD (earlier it was used " classic"). Now modules analogous (SkyBox) [rekmodyatsya] without the problems.
6. The search for the lingual files of Manila (for the exception or the removal) is substantially accelerated
7. In ModuleInfo is added the information about the imported libraries (given they are taken on the basis ImportDirectoryTable) and a quantity of the exported functions
8. Is added the possibility of retrieval for line and binary data in the files and the modules . Binary data can be searched for including on the pattern - the insignificant byte is designated by two signs of a question. The window of search is caused from the panel of tools (window of log' a) for the search in all files/modules, or from the contextual menu of packet for the search only in the selected packet.
9. In Dump Of tool with the discovery of file ROM the information about the packets is read now without the preliminary extraction of flat dump, that healthily economizes the time. In the panel of tools it is possible to select, what precisely dump must be obtained, flat, or immediately decomposed on the packets.
10. In Dump Of tool is added the possibility of the extraction of sections NB from the file NBH, if for the dump was selected file NBH
11. All tuning Of dumpTool are written in the list, but not into the file of osb
12. It built in the library of msvcr71.dll [installyator] (it is established automatically in the same folder, as OSBuilder)
13. In the additional tools added the search for modules L modules search for in all packets. As results of search show the modules, which are located in slot 0 the modules, for which is established the flag L into dsm. [Dablklik] on the module causes ModuleInfo
14. Wrote the component PE Of file Of info it derives information about the usable file (Headers, Sections, DataImageDirectories, etc.)
15. In the menu of configuration is added the list of resource files and modules, which must be cleaned during the assembling (it will be left only the section of.rsrc). The principle of cleaning is examined respected Of ultrashot' ohm in the separate theme Files and modules can be added in the list both by hand and the aids of additional tools (cleaning -> To remove the code from the resource files). In this case will be automatically brought out the list of all mui of the modules/of files. Addition/allotment from the list is produced with the aid of the contextual menu. Certainly before adding module or file in the list, should be focused attention, does export functions the selected module or file and that this for the functions. On double-click it is opened BY PE Of file Of info or Module Of info (depending on object). Cleaning occurs in the process of assembling. The originals in this case remain unchanged
16. Everyone of " " functions (cleaning modules, cleaning Manila and cleaning resources) are now grouped in one point of the add. of tools - cleaning. COMPLETE VERSION:
17. In ModuleInfo is added the possibility of the reconstruction of file directly into the folder of module, or into the folder on the selection.
18. In ModuleInfo is added the possibility of the survey of the tables of import and of export
19. In PE Of file Of info there is a possibility of the survey of the tables of the import/of export by analogy from Module Of info
20. As results of search from the contextual menu it is possible to open the obtained file/module by analogy with the window of packet
21. In the contextual menu of packet is added the point of " To verify dependence on the files/of [moduley]". With its aid it is possible to verify the direct and inverse dependences of the usable files/modules of packet on the usable files/of the modules of other packets. In the left window the list of the usable files/of the modules of packet is shown. In the average window is shown the list of the files/of modules on which it depends the selected in the left window file/module. In right window showed the usable files/modules which they depend on the file/of the module, selected in the left window. 1 and 2 Dependences are built EXCLUSIVELY! on the basis the tables of import.
22. In Dump Of tool is added the additional tool, which makes it possible to extract divisions, packets, modules and files directly from the file ROM
23. In addition to mui (point 15) into the window of the files/of modules are derived dll, that import not more 2nd functions and exporting is not more than 1. if the import of [idet] from mscoree.dll (.NET CF), then this dll in the list is not derived.
24. To add/to remove file or module in the list for the cleaning is possible with the aid of the contextual menu in the window of packet ([Skrinshot]) Are added in the list or removed from the list they can be only dll and mui.
OS Builder V1.2.64 (26.10.2010):
Code:
1. Is corrected the problem, which appeared when the size of the logic unit of [ravern] to the size of sector - post [url]http://asusmobile.ru/board/viewtopic.php?p=322363#322363[/url]
2. With the creation of template from the file ROM (including with the dump), in which is present initialized FAT32[b] now always they are considered tuning FAT32
OS Builder V1.2.62 (25.10.2010):
Code:
1. In cmd-file, which is carried out at the end of assembling XIP' and the variable environments are transferred
2. In the menu of configuration is added the point of " To rename packets on the names of [papok]" - in the configuration will be renamed the grouped packets (files of dsm they do not change) - post [url]http://asusmobile.ru/board/viewtopic.php?p=321278#321278[/url]
3. In the contextual menu of packet is added the point of " To appropriate to packet the name of [papki]" - it works by analogy with point 2, only for the single packet. The dialogue of confirmation in this case is not derived - renaming occurs immediately.
4. Is added the support O2 Of xda Of zinc (theoretically)
5. Trifle, but… In the basic ravine after [reloka] is derived the information about the vacant place in slot 0
6. Are added several parameters into the file of osb, which are concerned forestalling reading of packets (possibly Scanning can someone strain, or to someone it is not simply necessary with the presence Of core i7 and OF RAID 0 of SCSI or SAS of disks). In the section [Of oSBuilder.Trees] Of nodesEnableStartupScan - it solves either forbids forestalling reading, NodesScanModules - it solves or it forbids forestalling reading of modules, NodesScanFiles - it solves or forbids forestalling reading of files.
7. Wrote its dumper IMGFS (at long last it got rid of ImgfsToDump). If in someone was the problem, described in the post [url]http://asusmobile.ru/board/viewtopic.php?p=321427#321427[/url], then it must disappear (i have this problem it was not observed).
8. [Pofikseny] any trifles
9. [Izmenen] the cursor of assembling - files now in TEMP are not copied (with exception of those, which must be signed or reconstructed from the modules) Attributes are observed (about the attribute R now it is possible not to think generally), original files they do not change. Also [izmenen] the sequence of files and modules in IMGFS (for help the enormous thanks of airextreme)
OS Builder V1.2.50 (05.10.2010):
Code:
1. With preview of the list of rgu and provxml they are checked against the exceptions. If the file of rgu or provxml is present in the list of exceptions, then data from it will not be imported for [predprosmotra] - post [url]http://asusmobile.ru/board/viewtopic.php?p=319740#319740[/url]
2. Is solved problem with UL in the assembled by hand template - posts [url]http://asusmobile.ru/board/viewtopic.php?p=313397#313397[/url] [url]http://asusmobile.ru/board/viewtopic.php?p=313554#313554[/url]
3. Are removed the tuning, which relate to .VM and .ROM - now .VM and .ROM automatically are corrected or are created on the basis given XIP
4. Is [optimirovan] the algorithm of assembling the file of division IMGFS and files ROM NB0 (payload), nb and nbh
5. Is added the possibility ofredirection of folder TEMP - see tuning - > Packets and configuration ([Skrinshot]). For the folder TEMP are permitted ONLY absolute ways! [Perenapravlenie] of folder TEMP to RamDisk can substantially accelerate the process of assembling. For the optimization of the use Of ramdisk is added [chekboks]. If it is noted, then in the process of assembling temporary components ROM will be automatically moved away. Both these tuning are written in the list, but not into the file of osb!
6. For the use in [komandnikakh] is added the variable of the environment of _TEMPDIR (complete way to the folder TEMP)
7. Is added the possibility of " fast" assembling list - see tuning dump and ROM. Significant acceleration is perceptible with the large number of packets (but respectively the files of dsm and rgu). The parameter works only when selected the association of packets into one (in the tuning or in the panel of the tools of builder). If the rapid assembling of list is selected, then it is better to first ascertain that the files of list do not contain errors, for example to cause the preliminary survey of list.

CHANGELOG (web translation)
OS Builder V1.2.43 (24.09.2010):
Code:
1. Is corrected situation with the search for values in the list (Complex RGU) - post [url]http://asusmobile.ru/board/viewtopic.php?p=318704#318704[/url]
2. Is added the support Of hTC-RhodiumW (date and version into nk.exe)
3. Is added the possibility of correcting the version ROM for HTC Of touch HD (only for nucleus 6.5)
4. On the especially persistent requests is added the possibility of the complete removal of folder TEMP at the end of assembling and copying file ROM from TEMP into the folder on the selection. C[m]. Tuning dump and ROM - > Sizes and the designation of files ROM
5. Is added the possibility of the conversion of initflashfiles.dat from delirium (codes of the symbols of unicode) into the usual text. See additional tools - > Initflashfiles.dat
6. Analogous possibility is added into DumpTool - with the forming of the packets of initflashfiles.dat it can be automatically converted. See tuning - > Dismantling of dump.
7. Is added the possibility of the record of the tuning and configuration, with which it is gathered BY ROM, directly in ROM - post [url]http://asusmobile.ru/board/viewtopic.php?p=318987#318987[/url] After the starting of [devaysa] the files will be located in the folder Windows \ Of oSBuilder. See tuning dump and ROM
8. Are a little changed tuning NBH - now it is possible to add several components (sections) of piercing in the list and to note for the assembling only necessary ([skrinshot]) - see tuning dump and ROM - > Sizes and the designation of files ROM
9. Is added [vozmnozhnost] of dialogue during assembling of nbh for the selection of the components of [sm].[Nastroyki] of dump and ROM - > Sizes and the designation of files ROM) - post [url]http://asusmobile.ru/board/viewtopic.php?p=319418#319418[/url] In this dialogue it is possible to select for the section of piercing only. (Version, CID, Lang and so forth cannot be changed - they they are derived only for the information)
10. In the tuning is carried out control of all timers (specially for those, who their " dully [sozertsaet]" - is given quotation from post 319679 - and it does not read changelog). If is selected checkbox of " [Otklyuchit]" (value of timer it is automatically set equalequal to -1), then process it will expect the reaction of user - pressure OK, cancellation so forth if the value of timer is equal to zero, process begins immediately.
11. Is added the possibility of removal of files with unnecessary languages from packets of Manila Files it is possible either to add in the list of exceptions or to physically remove from the disk - see additional tools - > Manila
12. In last [komandnik] is added the variable of the environment of _ROMVERSION - version ROM in that form, as it appears in ROM Of builder' e. if in ROM Of builder' e version ROM is not reflected or empty, then variable _ROMVERSION into [komandnik] will not be transmitted.
13. Is added support SE X1 (HTC-Kovsky, date and version ROM) COMPLETE VERSION:
14. Is corrected problem with the auto-signature of the files Of custom by certificate with the work of program in Windows XP.
15. In the editor of iniflashfiles now can be transferred the number of line, for example with the preliminary survey of files. Example of tuning for notepad2 - " C:\Program Files (x86) \ Of notepad2 \ Of notepad2.exe" /g %2 " %1" - if in the command is present argument %2, then it will be [zameshchen] the number of line (with the usual discovery of file - [nulem]).
16. Is added the possibility of [predprosmotra] of files - is analyzed initflashfiles.dat initflashfiles.txt in the selected packets. Window is analogous with the window Of complex RGU. The command is reflected during the guidance of cursor to the number of line in the right lower part of the window. On double-click on the line is opened corresponding initflashfiles (dat or txt)
OS Builder V1.2.35 (10.09.2010):
Code:
1. Added ability to import settings from a file osb and export settings to a file osb - see Settings -> Packages and configuration
2. Add-in DumpTool: if layout dump the packets to the root of a new kitchen is recorded file OSBuilder.osb c default settings. If the dump file is derived from NBH, then OSBuilder.osb will contain all necessary information for an assembly file NBH (CID, version, Lang, model, data block size and code sections, OS)
3. Fixed a problem with the search date and version in ROM XIP'e HTC HD Mini
4. Fixed bug DSM Editor context menu when running in Standalone mode - post http://asusmobile.ru/board/viewtopic.php?p=318529 # 318529
5. Fixed bug in DumpTool (Automatic generation of a template for the dump nb0 (payload), nb, nbh) - Post http://asusmobile.ru/board/viewtopic.php?p=318554 # 318554
FULL VERSION:
6. Added ability to save settings in the registry editor and the possibility to import these settings from the registry - see Editor Options
OS Builder V1.2.32 (07.09.2010):
Code:
1. Added ability to copy the ROM file to a folder of your choice. See assembly dump and ROM-> formats and file naming.
2. In DumpTool added output vesii OEM package (key HKEY_LOCAL_MACHINE \ SOFTWARE \ OEM \ MASD), if it is registered in rgu package
3. Fixed bug in ComlexRGU - post http://asusmobile.ru/board/viewtopic.php?p=318367 # 318367
4. Fixed a glitch that caused crash if OSBuilder running on a computer with a single core processor.
5. Corrected entry routes in the settings
OS Builder V1.2.30 (06.09.2010):
Code:
1. Corrected parser provxml, so no problems with Int / UInt - post http://asusmobile.ru/board/viewtopic.php?p=312974 # 312974
2. Corrected the situation with the utility menu User - post http://asusmobile.ru/board/viewtopic.php?p=313364 # 313364
3. Fixed bug - when creating a group at the root of the tree was necessary to press the refresh button to make the shortcut menu for the new group - the post http://asusmobile.ru/board/viewtopic.php?p=312987 # 312987
4. Corrected spelling while maintaining dsm without certification - a post http://asusmobile.ru/board/viewtopic.php?p=314564 # 314564
5. If you check for files and modules in the editor dsm hand icon file or module is updated in accordance with the flags - the post http://asusmobile.ru/board/viewtopic.php?p=314564 # 314564
6. In setting the Dsm added an additional item "When you save a file in the editor DSM automatically set the attributes of S and H for the modules and files in accordance with entries in the DSM"
7. Corrected the situation sometimes arises when you move the group to itself (disappearance)
8. Corrected the situation with the files. Osb - post http://asusmobile.ru/board/viewtopic.php?p=315819 # 315819 (last sentence)
9. In setting the editors added item "Before you edit the file to remove the attribute Read-only". After editing an attribute can not be restored, if necessary, to bring back his hand. Setting up correctly grown for all editors package files
10. In the Registry Editor can now be transferred to line number, for example, when previewing the roster in case of error or when viewing a registry file from ComplexRGU. Example settings for notepad2 - "C: \ Program Files (x86) \ Notepad2 \ Notepad2.exe" / g% 2% 1 "- if a team is present argument% 2, it will be replaced by the row number (the usual opening a file - zero).
11. In ComplexRGU added the ability to export a key in a file rgu (context menu key)
12. Corrected the situation with the files. Osb - post http://asusmobile.ru/board/viewtopic.php?p=315819 # 315819 (last sentence)
13. In the configuration menu added to the list REVERSMOD - files that are present in this list in the assembly will be automatically converted into modules.
14. Added the ability to build a file NB (by analogy with NBMerge or osnbtool-extra) - see Settings dump ROM (formats and file naming ROM), you can also specify the file names nb0 (payload) and nb.
15. FOR OWNERS HTC! - Ability to Build File NBH (Screenshot). Build options (version, language, CID, data block size) can be imported from a factory NBH file or manually. OS, RADIO, SPLASH tested on HTC Leo and HTC Touch Diamond2. Attention! Attention! Code sections (eg 0x400 OS) are not automatically imported, so when you import carefully check box with the data.
16. In setting the item was added to the "Automatically determine the type of nucleus (WM6.1/WM6.5)". If this is checked (and it is selected by default), then choose the type of nucleus in the toolbar will not.
17. In batch files that run before assembly and after assembly ROM, passed environment variables:
_ROOTDIR - Full path to the root of the kitchen
_SYSDIR - Full path to SYS (may be useful in the regime multibild)
_LANG - Selected language ROM, for example 0419. If the setting is prohibited choice of language or language ROM ROM is not defined, then the variable is passed to komandnik will not be
_BUILD - Build number of the dsm package OS type xxxxx, for example 22040. If the package is missing OS or dsm is damaged, this variable is passed to komandnik will not
_INITFLASH - Full path to iniflashfiles.dat (for the selected language)
Example komandnika:
Code:
@ Echo% _ROOTDIR%
@ Echo% _SYSDIR%
@ Echo% _LANG%
@ Echo% _BUILD%
@ Pause
Result:
Code: Code:
D: \ WM_MULTIBUILD
D: \ WM_MULTIBUILD \ SYS \ SYS_23563
0419
23563
Press any key to continue. . . . .
Environment variables can be used to invoke external tools or editors. Just as an example of "Notepad.exe"% _INITFLASH%
Naturally permennye environment can be used if a OSBuilder'e open the folder with the kitchen.
18. In DumpTool added the ability to dump file "turnkey" (menu File-> Open File). Supported formats. Nb0,. Payload,. Nb, nbh.
When you open the file you will see information about it, checked and unpacked section IMGFS and then you will see information about the packages IMGFS, while in the folder where the file will create a folder called ROM Dump. Then, when you click on "Arrange a dump of the packets in the folder Dump will create a folder structure, ready for OSBuilder'a (OEM, ROM c pattern and packages XIP'a and SYS).
19. In setting the parameter "Automatically delete the folder Temp \ Dump and Temp \ XIP in the background." If this option is selected, deleting folders will happen after the assembly file section IMGFS in the background.
20. On the File menu item added "recent" - is stored up to 10 public folders. Last open folder will be the first in the list. The menu item is displayed only when OSBuilder
21. Altered the internal algorithms (all-rounder did not reach) - Open kitchen, Relocation, merging packages is now much faster.
Also slightly changed the build order - register now going before the packages are copied to the Dump, so that if the assembly Registry is an error, it will become clear before it begins copying files.
Only the full version:
22. In the popup menu item was added to the package - Displays a list of files and modules - in the log window displays a complete list of objects in your package. Can be useful eg for lists of files, exceptions
23. In setting the editors added items and HEX editor, resources editor and additional editor (screenshot). These editors can use the box to the contents of the package. In addition HEX Editor can be used in ModuleInfo (dablklik on sections of the module)
24. Added the content window of the package (screenshot) in the style of the conductor (right window can be switched in either log or in the mode of content is really a package). In this window you can delete and rename files and modules, add and remove them from lists RECMOD, REVERSMOD, Auto signature, Slot 0, and edited with podklyuchemyh HEX editor, resources editor, and additional editors. By dablkliku on the module will ModuleInfo. By dablkliku on section modulus section will open in a plug HEX editor.
OS Builder V1.1.5 (24.06.2010):
Code:
1. Removed checking for folders DONOR when rebuilding. Checked only when actual use folders DONOR (porting)
2. Corrected parser registry - a post http://asusmobile.ru/board/viewtopic.php?p=312791 # 312791
3. Added check blank line at end of file rgu preview the registry (see Settings -> Preview Register)
4. Configuration files and settings for the Public and the full version is now fully compatible - a post http://asusmobile.ru/board/viewtopic.php?p=312808 # 312808
5. For a complete feng shui ... if user selected XIP Rebuilding, not ported, then the path to the folder DONOR
OS Builder V1.1.02 (22.06.2010):
Code:
OSBuilder will now only available as an installer. OSBuilder will now only available as an installer.
We strongly recommend not to install OSBuilder the root of drive! We strongly recommend not to install OSBuilder the root of drive! Leave the installation folder, which is offered by the installer. Leave the installation folder, which is offered by the installer.
If you have a previous version OSBuilder'a (1.0.94-1.0.96), delete it manually via the control panel! If you have a previous version OSBuilder'a (1.0.94-1.0.96), delete it manually via the control panel!
Now there is no need for every kitchen to keep exe-Schnick OSBuilder'a and puzzle what version of this file. Now there is no need for every kitchen to keep exe-Schnick OSBuilder'a and puzzle what version of this file. Simply rename the file in OSBuilder.ini OSBuilder.osb and run the kitchen with the help file. Osb, while OSBuilder automatically finds the settings from this file. Simply rename the file in OSBuilder.ini OSBuilder.osb and run the kitchen with the help file. Osb, while OSBuilder automatically finds the settings from this file.
Can be kept in a kitchen, a few files. Osb c different settings. Can be kept in a kitchen, a few files. Osb c different settings.
Can also be used as open kitchen from the menu File-> Open. Can also be used as open kitchen from the menu File-> Open. In this case OSBuilder first looks for an open file folder settings OSBuilder.osb. In this case OSBuilder first looks for an open file folder settings OSBuilder.osb. If no such file exists, will be searched for a file OSBuilder.ini, and if the file OSBuilder.ini be found, it will be renamed OSBuilder.osb and then it will be read from the configuration. If no such file exists, will be searched for a file OSBuilder.ini, and if the file OSBuilder.ini be found, it will be renamed OSBuilder.osb and then it will be read from the configuration. If neither OSBuilder.osb, nor OSBuilder.ini not be found, then create a file OSBuilder OSBuilder.osb with default settings. If neither OSBuilder.osb, nor OSBuilder.ini not be found, then create a file OSBuilder OSBuilder.osb with default settings.
Which configuration file used at this time indicated at the bottom of the window. Which configuration file used at this time indicated at the bottom of the window. Configuration file. Osb, you can edit as well as ini. Configuration file. Osb, you can edit as well as ini.
OSBuilder now supports both Russian and English interface. OSBuilder now supports both Russian and English interface. Language can be selected when you first start. Language can be selected when you first start. The same interface language can be changed in Options - tab "Packages and configuration", click "Select interface language when the program starts." The same interface language can be changed in Options - tab "Packages and configuration", click "Select interface language when the program starts." To change the language interface to close OSBuilder and the next time he will propose to select the language. To change the language interface to close OSBuilder and the next time he will propose to select the language. The language for the program, rather than for specific settings. The language for the program, rather than for specific settings.
When installing OSBuilder automatically create associations with the files. Dsm,. Sof and. Cif, that allows you to edit these files by simply dablkliku in Windows Explorer. (Viewing and editing sof and cif without running OSBuilder'a only available in full version) When installing OSBuilder automatically create associations with the files. Dsm,. Sof and. Cif, that allows you to edit these files by simply dablkliku in Windows Explorer. (Viewing and editing sof and cif without running OSBuilder'a only available in full version)
OTHER CHANGES: OTHER CHANGES:
1. The general assembly of the log is written to the TEMP TEMP folder only if present at the time of writing - the post http://asusmobile.ru/board/viewtopic.php?p=306058 # 306058 The general assembly of the log is written to the TEMP TEMP folder only if present at the time of writing - the post http://asusmobile.ru/board/viewtopic.php?p=306058 # 306058
2. In the configuration menu item was added to the "Advanced" - allows you to save the configuration version of the ROM, the size of PP (including 0xFFFFFFFF) and the description of the configuration (for the full version is also available to install and KernelFlags FsRamPercent). In the configuration menu item was added to the "Advanced" - allows you to save the configuration version of the ROM, the size of PP (including 0xFFFFFFFF) and the description of the configuration (for the full version is also available to install and KernelFlags FsRamPercent). Description of the configuration will be shown when you hover over the configuration file in the lower right corner OSBuilder'a. Description of the configuration will be shown when you hover over the configuration file in the lower right corner OSBuilder'a. ROM version, it makes sense to set in the configuration for the supported handheld device. ROM version, it makes sense to set in the configuration for the supported handheld device. To search for PP in XIP'e can be selected as the automatic mode, and manually specify which section nk and at what offset in this section is the size of PP. To search for PP in XIP'e can be selected as the automatic mode, and manually specify which section nk and at what offset in this section is the size of PP. These settings will be saved to a file xip_new.bin during assembly. These settings will be saved to a file xip_new.bin during assembly.
If you are porting XIP separately (Additional Tools -> To port XIP), in which case these parameters in the XIP not be recorded. If you are porting XIP separately (Additional Tools -> To port XIP), in which case these parameters in the XIP not be recorded.
Due to the fact that it is now possible to keep the size of PP in the configuration file settings are removed from the parameters of PP, except for the CheckPagePoolSize, PP isolates search all. Due to the fact that it is now possible to keep the size of PP in the configuration file settings are removed from the parameters of PP, except for the CheckPagePoolSize, PP isolates search all.
3. In the build configuration XIP'a item added "Delete spaces between sections nk in RAM" - in some cases allow more densely arranged sections, and free up a little extra space RAM In the build configuration XIP'a item added "Delete spaces between sections nk in RAM "- in some cases allow more densely arranged sections, and free up a little extra space RAM
4. In the build configuration XIP'a added item "Use the direct search for addresses nk" - this method can also try to use, if any patch in the pre-patched nk after porting / rebuilding XIP'a not working as it should. In the build configuration XIP'a added item "Use the direct search for addresses nk" - this method can also try to use, if any patch in the pre-patched nk after porting / rebuilding XIP'a not working as it should. I warn in advance that this method could lead to inoperability XIP'a or unexpected glitches. I warn in advance that this method could lead to inoperability XIP'a or unexpected glitches.
5. Fixed a glitch with the print version DSM (and HTC) in the description window when you move to the package by using keys UP / DOWN - post http://asusmobile.ru/board/viewtopic.php?p=306717 # 306717 Fixed a glitch with the print version DSM (and HTC) in the description window when you move to the package by using keys UP / DOWN - post http://asusmobile.ru/board/viewtopic.php?p=306717 # 306717
6. Added option to remove the packages and groups from the grouped keys Del or Backspace. Added option to remove the packages and groups from the grouped keys Del or Backspace. Added a context menu of the package and the <Context> Added a context menu of the package and the <Context>
7. Added ability to edit the properties of a group or package (bundled in packages) by pressing F2 Added ability to edit the properties of a group or package (bundled in packages) by pressing F2
8. Reached his hands to a more thorough check on the membership package to the language (tested only on a special list of languages) Reached his hands to a more thorough check on the membership package to the language (tested only on a special list of languages)
9. In the settings (packages and configuration) is now generally possible to disable the check for membership to the language. In the settings (packages and configuration) is now generally possible to disable the check for membership to the language.
10. Corrected popup menu package, and the group - post http://asusmobile.ru/board/viewtopic.php?p=308167 # 308167 Corrected popup menu package, and the group - post http://asusmobile.ru/board/viewtopic.php ? p = 308167 # 308167
11. Fixed a glitch with retention of configuration (for loading the new configuration) - Post http://asusmobile.ru/board/viewtopic.php?p=309425 # 309425 Fixed a glitch with retention of configuration (for loading the new configuration) - Post http: / / asusmobile.ru / board / viewtopic.php? p = 309425 # 309425
12. Added progress window assembly file section IMGFS (thermometer) Added progress window assembly file section IMGFS (thermometer)
13. Fix a glitch with porting SYS (stop, if the packets are marked yellow) - Post http://asusmobile.ru/board/viewtopic.php?p=305775 # 305775 Fixed a glitch with porting SYS (stop, if the packets are marked yellow) - Post http://asusmobile.ru/board/viewtopic.php?p=305775 # 305775
14. Added support for Garmin-Asus M10, M20 (PP, date and version of the ROM) Added support for Garmin-Asus M10, M20 (PP, date and version of the ROM)
15. Packages are not included in packages.sof (cif) can now be sorted in the editor sof and cif for GUID - post http://asusmobile.ru/board/viewtopic.php?p=309858 # 309858 Packages are not included in packages.sof (cif) can now be sorted in the editor sof and cif for GUID - post http://asusmobile.ru/board/viewtopic.php?p=309858 # 309858
16. In additional instruments added item "Files provxml" (available only in full version). In additional instruments added item "Files provxml" (available only in full version). When you select a window appears with a list of files provxml in the order in which they are executed. When you select a window appears with a list of files provxml in the order in which they are executed. Files provxml, containing the registry settings and / or certificates that are marked with the icon. Files provxml, containing the registry settings and / or certificates that are marked with the icon. Double click opens the file for editing. Double click opens the file for editing. Using the context menu to open the file for editing, see the registry settings in Complex RGU, export the registry settings to a file rgu or browse the registry of all the files in provxml Complex RGU. Using the context menu to open the file for editing, see the registry settings in Complex RGU, export the registry settings to a file rgu or browse the registry of all the files in provxml Complex RGU.
17. Added the ability to both manual and automatic signature files or a built or self-signed certificate (only available in full version). Added the ability to both manual and automatic signature files or a built or self-signed certificate (only available in full version). In additional instruments added item "Create your own certificate to sign files. In additional instruments added item "Create your own certificate to sign files. In the configuration menu, added the ability to create a list for avtopodpisi (by analogy with the list RECMOD), and in the popup menu item was added to the package" to sign a file, with which you can either immediately sign files in the package (optional), or add files to the list for avtopodpisi. In the configuration menu, added the ability to create a list for avtopodpisi (by analogy with the list RECMOD), and in the popup menu item was added to the package " to sign a file, with which you can either immediately sign the files in the package (optional), or add files to the list for avtopodpisi.
ALL THE FACTS IN ADDITION TO MANUALS IN THE SECOND post topics. ALL THE FACTS IN ADDITION TO MANUALS IN THE SECOND post topics. MUST READ, Do not be lazy! MUST READ, Do not be lazy!
18. Removed from the settings option BuildImgfsV2. Removed from the settings option BuildImgfsV2. Assembling IMGFS made as if this option was set to True - see ChangeLog - OS Builder V1.0.65 RC4 (24.03.2010) para 14. Assembling IMGFS made as if this option was set to True - see ChangeLog - OS Builder V1.0.65 RC4 (24.03.2010) para 14.
19. As an OEM XIP porting is now also possible to use the packages in a folder ROM \ XIP - see the settings for an assembly XIP. As an OEM XIP porting is now also possible to use the packages in a folder ROM \ XIP - see the settings for an assembly XIP. The presence of files and romhdr.bin parthdr.bin in your ROM \ XIP necessarily. The presence of files and romhdr.bin parthdr.bin in your ROM \ XIP necessarily. Type settings XIP'a little has changed - see the updated manual on XIP'u second post topics. Type settings XIP'a little has changed - see the updated manual on XIP'u second post topics.
Attention! Attention! After the transition to the new version OSBuilder sure to check the configuration of assembly / porting XIP. After the transition to the new version OSBuilder sure to check the configuration of assembly / porting XIP.
20. Added mode multibild - in one kitchen, one can use several builds SYS - manual in the second post topics. Added mode multibild - in one kitchen, one can use several builds SYS - manual in the second post topics. Be sure to read and not lazy, it is important! Be sure to read and not lazy, it is important!
21. The full version adds a database GUID'ov package (currently only MS), which allows more accurate identification of dependencies and shadow in the dsm, and quickly change the DPI, LANG and RES in packages.sof and packages.cif. Planned to make the base through the Inet recharged. Planned to make the base through the Inet recharged.

RC CHANGELOG (web translation)
OS Builder V1.0.78 RC4 (23.04.2010):
Code:
1. In the form of packages combining fixed glitch with the "Cancel" In the form of packages combining fixed glitch with the "Cancel"
2. In setting the porting / assembly XIP'a item added "After the run" - you can specify komandnik, which will be executed at the end of the assembly XIP'a. In setting the porting / assembly XIP'a item added "After the run" - you can specify komandnik, which will be executed at the end of the assembly XIP'a. Allowed relative paths. Allowed relative paths. (The current directory at startup komandnika - the root of the cuisine) (The current directory at startup komandnika - the root of the kitchen)
3. Corrected the spelling in an editor file certificates - Post http://asusmobile.ru/board/viewtopic.php?p=302202 # 302202 Corrected the spelling in an editor file certificates - Post http://asusmobile.ru/board/viewtopic.php ? p = 302202 # 302202
4. Added ability to set the size of PP = 0xFFFFFFFF Collector ROM - post http://asusmobile.ru/board/viewtopic.php?p=301812 # 301812 Added ability to set the size of PP = 0xFFFFFFFF Collector ROM - post http://asusmobile .ru / board / viewtopic.php? p = 301812 # 301812
5. In the ini in the section [OsBuilder] added option DisablePagePool, DisablePagePool = True - the size of PP is set to 0xFFFFFFFF. In the ini in the section [OsBuilder] added option DisablePagePool, DisablePagePool = True - the size of PP is set to 0xFFFFFFFF. This option has a higher priority to the parameter DefaultPagePool This option has a higher priority to the parameter DefaultPagePool
6. In the ini in the section [OsBuilder] added option CheckPagePoolSize. In the ini in the section [OsBuilder] added option CheckPagePoolSize. If set = False, then the search or change the size of the PP do not will be done (default = True). If set = False, then the search or change the size of the PP do not will be done (default = True). This option has the highest priority over all other parameters of PP. This option has the highest priority over all other parameters of PP.
7. Added ability to run the cmd-file before dump Relocation - see the settings for an assembly dump ROM Added ability to run the cmd-file before dump Relocation - see the settings for an assembly dump ROM
8. In previewing the roster reformed to delete keys and parameters (for care thanks NarkoZ) In previewing the roster reformed to delete keys and parameters (for care thanks NarkoZ)
9. Timer output for various operations are now customizable - a post http://asusmobile.ru/board/viewtopic.php?p=302881 # 302881 Timer output for various operations are now customizable - a post http://asusmobile.ru/board/viewtopic . php? p = 302881 # 302881
In the ini file in section [OSBuilder] options: In the ini file in section [OSBuilder] parameters:
Code: Code:
TimerXIP - sets the timeout at the end of rebuilding XIP'a. TimerXIP - sets the timeout at the end of rebuilding XIP'a. Default value = 10 Default value = 10
TimerRebase - sets the timeout after forwarding modules. TimerRebase - sets the timeout after forwarding modules. Default value = 10 Default value = 10
TimerMergePkg - sets the timeout after the association dsm. TimerMergePkg - sets the timeout after the association dsm. Default value = 10 Default value = 10
TimerRomStart - sets the timeout BEFORE assembling the file ROM. TimerRomStart - sets the timeout BEFORE assembling the file ROM. Default value = 15 Default value = 15
TimerRomEnd - sets the timeout at the end of the assembly file ROM. TimerRomEnd - sets the timeout at the end of the assembly file ROM. Default value = 10 Default value = 10
Values mean a second. Values mean a second. If the value is 0, then the process will be completed (or started) immediately. If the value is 0, then the process will be completed (or started) immediately. If the value is -1, the process will wait for user response (pressing OK, etc.) If the value is -1, the process will wait for user response (pressing OK, etc.)
10. In connection with the search for innovations modified the time-bomb (thanks SergeyLar) In connection with the search for innovations modified the time-bomb (thanks SergeyLar)
11. In the menu of additional tools added item "Create Template". In the menu of additional tools added item "Create Template". You can create templates based on files nb0 or payload. You can create templates based on files nb0 or payload. There is an opportunity to enter into a template XIP, delete, substitute or leave blank ULDR, set the size of PP, as well as the date, version, etc. There is an opportunity to enter into a template XIP, delete, substitute or leave blank ULDR, set the size of PP, as well as the date, version, etc. for supported handheld device. for supported handheld device.
12. Added ability to append to the file ROM partition FAT32 (the file or empty, scored FF in size in FAT32 Partition Table) - see the settings for an assembly dump ROM Added ability to append to the file ROM partition FAT32 (the file or empty, scored FF in size in FAT32 Partition Table) - see the settings for an assembly dump ROM
13. Added the possibility of reconstruction of files from the modules in the editor dsm and the context menu of package Added the possibility of reconstruction of files from the modules in the editor dsm on the shortcut menu package
14. Added the possibility of reconstruction of files from the list of modules during assembly. Added the possibility of reconstruction of files from the list of modules during assembly. The list is saved in the configuration. The list is saved in the configuration. Modules in the list dobavt both manually and a list from the context menu of the package or the context menu of the file dsm. Modules in the list dobavt both manually and a list from the context menu of the package or the context menu of the file dsm. Originals of the modules in SYS, OEM, or EXT remain unchanged, the reconstruction takes place directly in the Dump, while in the dsm files Dump adjusted accordingly. Originals of the modules in SYS, OEM, or EXT remain unchanged, the reconstruction takes place directly in the Dump, while in the dsm files Dump adjusted accordingly. - See - See manual in the second post topics. manual in the second post topics.
15. Added the ability to build the file section IMGFS no pattern, just the file-header IMGFS. File should be named imgfs.bin and be in a folder ROM.
16. When cleaning the module if there is also deleted imageinfo_pe.txt - post http://asusmobile.ru/board/viewtopic.php?p=304958 # 304958
17. In the context menu items added to the package "Create initflashfiles.txt" and "Create a registry file." These menu items are visible only when the package is missing initflashfiles.txt or registry file - post http://asusmobile.ru/board/viewtopic.php?p=304816 # 304816
18. When you open a folder with a kitchen, if not found the default configuration file, OSBuilder try to load a configuration from file Option.xml (if any). I do not remember who requested such feature, but just someone asked
19. Package or group in the tree to select the packages you can celebrate a key "gap"
20. Added support for ASUS P527 (size of PP and the date of ROM)
21. Added support for Dell Axim X51 (the size of PP, the date and version of the ROM)
OS Builder V1.0.66 RC4 (26.03.2010):
Code:
1. I think that the problem with calling komandnika at the end of the assembly (and up if someone was) - the post http://asusmobile.ru/board/viewtopic.php?p=301381 # 301381
Before running komandnika current folder is the root of the kitchen. Consider it in teams and in relative paths in komandnikah.
2. Possible to run multiple instances OSBuilder (naturally in various kitchens icon_smile) - Post http://asusmobile.ru/board/viewtopic.php?p=301224 # 301224
OS Builder V1.0.65 RC4 (24.03.2010):
Code:
1. When you import configuration files from Option.xml Option.xml also searched in the folder EXT
2. Fixed a problem with the search for packages in a folder EXT - post http://asusmobile.ru/board/viewtopic.php?p=295521 # 295521
3. Fixed a problem with the "Build" and start a timer at the collector ROM - post http://asusmobile.ru/board/viewtopic.php?p=291362 # 291362
4. Fixed a problem with an error when creating a dsm, when empty or damaged dsm has an attribute ReadOnly (interestingly, some on an empty dsm took place ReadOnly icon_smile))
5. In the derivation of textual information about XIP'e displays information about devayse, date, version, PP, etc. (If the device is identified)
6. At the request of workers in the extra tools added item "Auto DSM". The settings are quite flexible - you can rebuild all the damaged and empty dsm, correct names and GUID's packets, synchronize files and modules. In essence - this synchronization as the editor DSM, not just for one but for a variety of packages.
7. Slightly changed parser provxml (hope that got rid of the error message described in this post.
8. In additional tools removed the item template \ Extract dsm and rgu. Instead, he added, click Templates \ extract the package into a folder XIP ROM \ XIP. In fact, it's a dump XIP'a template packages. In the folder ROM \ XIP also extracted ROM Header and PartHeader (data from the address physFirst and physFirst + 0x1000).
9. In additional instruments added item XIP (ROM \ xip.bin). The submenu items are the same as the template.
10. In the build configuration item was added to the Copy ROM file in the root folder (previously it was necessary to prescribe manually in ini)
11. Change search size PagePool (for ASUS P526) - Post http://asusmobile.ru/board/viewtopic.php?p=291932 # 291932
12. Added support for ASUS A696
13. Added ability to run a batch file to build (see build configuration).
14. Reduced assembly time file section IMGFS (thank AnDim and airxtreme). In the ini file in section [OsBuilder] option BuildImgfsV2 = True - a new method (the default), BuildImgfsV2 = False - the old method
15. Implemented rebuild / avtoportirovanie XIP'a - tested at various devaysa. During the tests many thanks to Alexx ~, AndrewSh, Feropont, Anper. A separate manual porting / rebuilding XIP'a here.
16. Changed build - you can explicitly specify what kind of XIP will be used to build - XIP from a template file ROM \ xip.bin or ported (rebuilt) XIP.
OS Builder V1.0.56 RC3 (21.01.2010):
Code:
1. Corrected job with the template (many thanks Anper 'y). Who had jumped out a bug related to the fact that the size of FLASH in the region 0 is zero, try ...
2. At the root of the kitchen at will, you can create a folder EXT for their packages. If the folder exists, then it will also be used autosearch packages. Requirements for the package in the EXT are the same as the OEM and SYS (not to be confused with the EXT packages EVK!!!!)
3. In the toolbar button added to expand / collapse the tree grouped packages.
4. Collector ROM file added to start the timer. If within 15 seconds. has not been altered by hand or one parameter, the assembly will start automatically.
5. Search box in the editor and sof cif made no modal
6. Fixed minor bug - box version definition dsm displayed only if the settings were set to "Show package versions HTC"
7. Now you can force the name of the file ROM. In the configuration file in section [OSBuilder] option RomFileName. For example RomFileName = OS.nb as a parameter, you can use the file name only, with no roads. If you no longer need this - leave this blank: RomFileName =
OS Builder V1.0.54 RC3 (14.01.2010):
Code:
1. Made drastic changes in reloker.
2. Substantial changes in the algorithm combining packages.
3. Something corrected in the parser for previewing the roster.
OS Builder V1.0.50 RC3 (19.12.2009):
Code:
Fixed bug in relokere - the distribution of the modules on the actual e32_vbase in some cases, could turn out intersection.
OS Builder V1.0.49 RC3 (15.12.2009):
Code:
1. Added ability to change to a blank section UL, a 1 logic block (filled with bytes of FF)
2. Relocation implemented by packages.cif - details of additional Manuale
3. Added exception for modules configured relocation. Modules specified in the exemption will always be placed in slot 0, even if there is room to another slot and selected "Break-ins L". In addition, you can choose the form of exclusion from the package and OEMDrivers OEMDriversHigh - details in the supplementary manuals.
4. Added function to port SYS (toolbar - additional instruments). SYS porting the new packages do not coincide with Lang, DPI, resh and resv not shown at all, if the ini file in section [PortEngine] option SysShowAllPackages = False. If SysShowAllPackages = True, show all the packages.
5. Added output versions dsm (by analogy with the versions of HTC) - in the right window will be derived dsm versions of all packages. If any files dsm replace or edit - just in case before the print version dsm better to update the information.
6. In settings (packages and configurations) item was added to the "Show version of DSM package in the Description window.
7. Added support for HTC Leo (while theoretically, almost as long as there is no way to verify icon_smile))
8. In the setting adds the ability to specify the name of the package when combined into one package.
9. Setting the boundaries of slots in a separate form
10. When the Preview. Browse registry in case of error. provxml treatment. provxml not stop and process the following file. provxml
11. Rewritten search and patch time-bomb - a huge spacibo SergeyLar
12. When combined into a single package in the combined DSM will be copied information about all files
OS Builder v1.0.42 RC2 (09.11.2009):
Code:
1. Added settings to a file ini:
- Section [OsBuilder], setting DisableCritical. DisableCritical = True denies access to "risky" settings. DisableCritical = False allows access to all settings. This option is useful if OsBuilder laid out in the kitchen, and the need to "protect" the end user of the reckless action, naprimet of change of noodle minimum limits slots.
- Section [OSBuilder] option DefaultPagePool. To ensure that every time you build does not change the size manually PagePool, you can enter it in the file ini. The size in megabytes in the range from 0 to 64. Fractional values are illegal. If you specify DefaultPagePool =- 1, the parameter is not used and the size PagePool will be taken from XIP'a (template). Exceed the value of 64 is impossible!
2. Packages HTC
- The settings (packages and configurations), added item "Show package version of HTC's description window. Clicking on the package (in both trees) will attempt to consider the key HKEY_LOCAL_MACHINE \ SOFTWARE \ OEM \ MASD and if one exists, the version will be added to the description of the package and displayed in the window description.
- A tool in the toolbar to add an item Version HTC - if they found bags HTC, a list of versions will be displayed in the right window
3. Fixed search engine time-bomb (stumbling and outreach to build of 23085)
4. At the beginning of the assembly collapses window ungrouped package, if it is open
5. Made a small change in the mechanism of correction and autogenerate. VM and. ROM
6. In Builder'e ROM ROM date is automatically set to the "Today". To date, actually prescribed in the NK Collector added to separate the "Date (nk)"
7. Fixed an issue with the record date of ROM for HTC devices
8. Fixed a few little things implicit
OS Builder v1.0.40 RC1 (25.10.2009):
Code:
the first Public version

HD2Owner, thank you very much for publishing and support.
Glad to see OSBuilder thread on XDA-DEVS

I have been using OSBuilder since its initial release and have successfully cooked ROMs for Topaz. This is a fantastic kitchen. Thanks to Barin and others who have supported him in the development.

This is, by far, the most advanced visual kitchen I have used

Great work indeed!

Has anyone tried this kitchen with Omnia II roms? There is one primitive kitchen only for this device on modaco forum.

javichampi said:
Has anyone tried this kitchen with Omnia II roms? There is one primitive kitchen only for this device on modaco forum.
Click to expand...
Click to collapse
i asked barin and this is what he told me:
it's the only way to try. OsBuilder can build NB0 for any device and then you need conversion tools to convert nb0 to omnia format.
if there is any old kitchen for omnia you can try to get conversion tools from it. i'm sure that every kitchen builds partitioned nb0 and then uses device specific tools to make special format rom file.
edit:
tutorial videos and more links from mobileunderground thread (by indiagroove) added.
edit2:
changelog added (old versions where missing). re-ordered changelog to save space for future changelogs.

HD2Owner said:
i asked barin and this is what he told me:
it's the only way to try. OsBuilder can build NB0 for any device and then you need conversion tools to convert nb0 to omnia format.
if there is any old kitchen for omnia you can try to get conversion tools from it. i'm sure that every kitchen builds partitioned nb0 and then uses device specific tools to make special format rom file.
Click to expand...
Click to collapse
Thank you for your response,
well, the Omnia II can be flashed with nb0 files, that isn't the problem. But OmniaII's stock rom file is a .MST with multilingual support, and you can only extract english part directly from this file. So for non-english roms there is a tool that can create a dump directly from device, but it creates a .BIN file. As you said, if I convert this .bin file to .nb0, will I be able to make the dump with OSBuilder?
I'm a newbie cooker, and Omnia II dump is different to dump of HTC devices(even Omnia I too), for this reason I make the first question to anybody who have an Omnia II and can help me with possible specific configurations of the kitchen with this device.
Sorry for my poor english!!

osbuilder should work with nb0, nb and nbh.
you should give it a try..

HD2Owner said:
osbuilder should work with nb0, nb and nbh.
you should give it a try..
Click to expand...
Click to collapse
Well, finally I can make the dump, but when I try to open the build to work with it, I obtain this error and OSBuilder closes.

If os Builder create better rom from PlateformeRebuilder, i will test it
I'm waiting for EXT packages support

Nixeus said:
If os Builder create better rom from PlateformeRebuilder, i will test it
I'm waiting for EXT packages support
Click to expand...
Click to collapse
afaik, osbuilder does not support ext-format for various (good) reasons.
you have to convert ext to oem packages if you are adjusting a previous prb kitchen for osbuilder.
if you dump the rom with osbuilder it's not needed (osbuilder creates oem pkg's).
there are ext to oem conversion tools out there.
ultrashot is working on a nice tool to do this (i already used it to convert my evk based kitchen).

I had been using EVK for over a year before I switched to os builder. I had close to a hundred EXT's that I had put together, and making the switch was daunting. I first decide to play around with OS Kitchen (easy switch), and found that it created dsm's for all of my EXT. Once I had the dsm's, it was very easy to convert my EXT's to OEM's, so that's why I switched over to OS Builder.

I want to try this kitchen, but it seems like I can't dump a stock ROM RUU in the kitchen? How can I extract the NBH file out of the RUU and dump it in the kitchen?

_Madmatt said:
I want to try this kitchen, but it seems like I can't dump a stock ROM RUU in the kitchen? How can I extract the NBH file out of the RUU and dump it in the kitchen?
Click to expand...
Click to collapse
first extract the content of ruu...exe with winrar.
then switch to "mode-dump tool" in osbuilder (upper right) and chose file->open file->open your nbh->create packages
a new "dump" folder will be created (this is your kitchen folder, time to move and rename it)
then switch to "mode-os builder" (upper right) and chose file->open folder->select kitchen folder (previously created "dump" folder)

Database Users

welcome