Database Users

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

question about packages and initflashfile.txt

Hi everybody,
I'm on the way to learn ROM-cooking. On that long trip I reached another hurdle. I've successfully created packages and put them into the OEM folder of the kitchen. So far so good, ROM has been created successfully. But after I've flashed the ROM to the device I found out that the files are exists twice. For example I've created a package from iContact_0.8.cab. Here is a part of the initflashfile.txt:
...
root:-Directory("Programme")
Directory("\Programme"):-Directory("iContact")
Directory("\Programme\iContact"):-File("default.png","\Windows\default.png")
Directory("\Programme\iContact"):-File("default.skn","\Windows\default.skn")
Directory("\Programme\iContact"):-File("english.lng","\Windows\iCenglish.lng")
Directory("\Programme\iContact"):-File("german.lng","\Windows\iCgerman.lng")
Directory("\Programme\iContact"):-File("iContact.exe","\Windows\iContact.exe")
Directory("\Programme\iContact"):-File("iphone.png","\Windows\iphone.png")
Directory("\Programme\iContact"):-File("iphone.skn","\Windows\iphone.skn")
Directory("\Programme\iContact"):-File("Settings.exe","\Windows\Settings.exe")
...
After flashing the ROM to the device I have file english.lng in folder \Programme\iContact and I also have file iCenglish.lng in folder \Windows, I have file iContact.exe in \Programme\iContact and I also have iContact.exe in \Windows. I thought an entry like Directory("\Programme\iContact"):-File("iContact.exe","\Windows\iContact.exe") means move file from \Windows to \Programme\iContact.
I found out that I have the same problem with a lot of other packages I've created with package-creator 2.7.
What am I doing wrong?
Tom

initflashfile.txt can not move a file it just creates a copy or a shortcut to the file.
If you want to move a file you must use a xml file.

NikMel said:
initflashfile.txt can not move a file it just creates a copy or a shortcut to the file.
If you want to move a file you must use a xml file.
Click to expand...
Click to collapse
@NikMel thank you for that hint. Is that part of provxml files or option.xml? Can you provide an example, please? And sorry that I'm so clueless.
Tom

Ok, I think it is the mxi_<package>_*.provxml what should be created to do this, is that right? Assuming that it is I've created such a file for my package and tried to use it instead of flashfiles.txt. But it seems that the file will not be executed while the ROM has been flashed to the device. Who or what is responsible to execute all the *provxml on the device? Are all *provxml files executed automatically? I found hints that mxip_ and mxipcold_ means that the files are executed during reflashing respect. cold-restarting the device while mxipupdate_ means executing each time the package has been updated.
I have to learn so much ....
Thanks for any help.
Tom

Hi everybody,
ok, it's the mxi_<package>_*.provxml what should doing the stuff. But it seems that it is not executed after flashing the ROM to the device.
I searched a lot of threads in the forum (for example this one: http://forum.xda-developers.com/showthread.php?t=398025&page=2). It seems that many other guys have the same problem but I couldn't find a solution.
In the meantime I'm totally confused about UC, Autorun, Autoshortcut etc. etc.. It would be very nice if someone could get me going on. What should be done to get this damned *provxml working??
Tom

Ok,
during further tests I found out that the mxip_<package>_*.provxml is being executed if it only contains Registry entries and/or MakeDir FileOperations. If I add a simple copy how it is done in for example this file: mxip_HtcApps_HTC_Ringtone.provxml the mxip-File is not been executed for whatever reason.
Is there somebody who knows what the reason for this behavior is? In the MS documentation I read something about access rights which could be restricted by OEM manufacturers. Could it be that the problem is caused by missing rights? And if yes, how change it?
Tom

Hi,
mxip_*provxml files are executed during flashing. Ok, that's a fact and it is working for me now. I found out that I only can use <characteristic type="Copy"> within the provxml. Once I used <characteristic type="Move"> the provxml will not be executed due to an error.
In fact all files from OEM packages goes into \windows and if someone uses a mxip_*provxml to implement those package for example in \Programme the files are duplicated. It seems not to be possible to remove the source files from \windows.
I did a test with rapiconfig.exe /p mxip_iContact08_100.provxml. If the provxml contains <characteristic type="Move"> I got an error message Config failed (0x80070005): Zugriff verweigert. After changing the provxml and replacing all "Move" with "Copy" the command works as expected.
Then I tried to delete a source file from the windows folder with TotalCommander running on the device. But it is not possible to delete the file.
Is there a way to delete the source files from the windows folder? Is it possible to put the source files from packages in an other folder than \windows?
Thanks for any advice.
Tom

Hi there,
Just want to tell you that i'm following this thread with great interest, as I also want to learn about cooking rom's, when I have some spare time.
So, please keep posting your updates on this matter.
@ all rom kookers and devellopers~
please share what you know, isn't that the spirit of Xda forum? It's the only way to get further, the more people thinking means more and faster advances been made.
Cheers

tomduke99 said:
Is there a way to delete the source files from the windows folder?
Click to expand...
Click to collapse
This is not possible becaue the files are part of the ROM I think. This has to be done before the ROM is created. But I'm not sure whether this is possible I don't think so, this would require the kitchen to do all the stuff with the mxip*provxml.
tomduke99 said:
Is it possible to put the source files from packages in an other folder than \windows?
Click to expand...
Click to collapse
All files from the kitchen stored in \windows. Does the kitchen knows something about the structure of the filesystem? Shouldn't this be provided by the package tool resp. by BuildOS? Or am I being completely off track?
Thanks for any advice.
Tom[/QUOTE]

I think the best workaround for this problem is to use the automated WM customization.
Cook your ROM with only the stuff you want to leave in the Windows folder. Check all initflashfiles.dat and *.provxml files, and remove them from the ROM! Leave only one initflashfiles.dat file, that will create the permanent folders (PermDir directive) and copy the checkautorun.lnk to the startup folder. This shortcut, in theory, is the only duplicate you will have in your whole ROM.
Then build a CAB file to install all files you need outside the windows folder.
Build an ExtROM with this cab file, a config.txt file and the autorun.exe file (see tutorials around the forums on creating an extrom).
Build your nbh file with os.nb and extrom.nb, and flash!
If all goes well, you will see the rom booting, then starting customization, then resetting, and when the phone comes back, you will have a nice, clean, duplicate-free ROM.
I didn´t try any of it, it´s just a theory.
Hope it helps.
Eduardo

Try the following:
<characteristic type="FileOperation">
<characteristic type="yourfile.foo">
<characteristic type="Move">
<parm name="Source" value="\Windows\yourfile.foo" translation="install"/>
<parm name="RemoveAttributes" value="R" />
<parm name="RemoveAttributes" value="S" />
</characteristic>
</characteristic>
</characteristic>

[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:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<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:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<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:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<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

easy provisioning tool

I made couple of templates and a bat for rapiconfig to pass it in.
result is you can drug&drop provisioning commands over activesync connection from pc to pda
e.g. drop "emails" file into "RapiConfig-DROP_HERE.bat", it creates xml file, edit it and put in rom or send back in pda
can do:
emails, connections, wifi & more (if you'll create another template POST IT please)
ref: http://msdn.microsoft.com/en-us/library/bb737572.aspx
edit:
sending back options:
- from PC: use the same BAT, just drop edited output.txt file and drop it into "RapiConfig-DROP_HERE.bat"
- for implementing in ROM (by cooking) you need to change format to ANSI (from UTF-8) of output file
- - same for fdc-taskman
- from PDA: I just added another BAT, "makeCAB-DROP_EDITED_OUTPUT_HERE.bat"
- - by dropping edited output.txt file into it, it will create YourXMLfile.cab file, to be executed in pda. (accepting both UTF-8 and ANSI formats, so you don't need to care)
look in post#3 for more details on possible incompatibilities
UPDATED attached file: added bat for creating cab for pda

Hi,
I allready had one IMAP4-email-Account configured and that one worked.
Well, i tried the follwing.
Downloaded and extracted provxml.zip.
Drag & droped "emails" onto "RapiConfig-DROP_HERE.bat"
I deleted my email-Account.
When i try to use the email-output.txt and rename it to email-output.xml and try to install it with DotFreds TaskManager it tells me "the xml input is invalid or malformed."
can som1 explain this?
best regards
fwt

yes. sure. change encoding to ANSI or look below for other options
thanks for pointing it out, I'll edit the post, add info about encoding.
i'll explain:
I can't say a word against fdc taskman, I love it!
Think is, "standard definition" is very wide and sometimes not precise subject.
like with registry, they should be unicode, pda version should have "REGEDIT4" header and default key should be "@" and not "default"
but resco is exporting v5 header, and some of others are exporting ANSI files, some creating "default" now, so far for keeping standard..
fdc taskman is importing ALL kind of registries "formats". that's great, but not so much with xml
theory:
xml should have header,
xml could be any format, and as MS stating for provisioning, it should be UTF-8 ref: http://msdn.microsoft.com/en-us/library/bb737422.aspx
BUT:
if you define header - it's not working
if you place UTF-8 format in ROM, (by kitchen), it's not working too
provxml though theory, needs to be ANSI without header, even against what ms is standardizing them to.
RapiConfig is accepting any encoding, and correctly creating UTF-8, but our pdas just don't like it. And fdc-taskman probably not as well.
other options:
Instead you can make a CAB file of it, that would accept both UTF-8 and ANSI
it's simple, rename xml to _setup.xml and pack with makecab.
I'll create a BAT for doing it and place in first post.
or just use the same method of dropping the output....txt into "RapiConfig-DROP_HERE.bat"
that accepts both formats too.
==
another trouble you could have with "connections" provs.
RapiConfig contains "options", provxml not.
like this:
<parm name="DestId" value="{9BAA043B-4019-6C3E-3552-1DA656689A34}" options="Telstra-mms{9BAA043B-4019-6C3E-3552-1DA656689A34}Home-mms{E482A778-1964-0A27-0AB8-7CCE196B9849}Telstra-wap{A1D5DA14-BA00-2A92-45E6-1A9EDAD2D7C5}Home-wap{18AD9FBD-F716-ACB6-FD8A-1965DB95B814}Internet{ADB0B001-10B5-3F39-27C6-9742E785FCD4}....etc....."/>
in provxml files it's without options:
<parm name="DestId" value="{9BAA043B-4019-6C3E-3552-1DA656689A34}" />
if this would make trouble with fdc porting or ROM implementing, or CABs, I didn't test.

First test with new version:
Changing email-output.txt to ANSI(Unix) with TextPad and renamed to email-output.xml => works fine with fdc Taskmanager
Account synced fine!
Account deleted again and tested with XDA_UC => nope ... didn't work
made a cab like described in first post => installed on Touch HD => works fine
great job so far.
Just one (really little) thing:
Could you please remove the "> null" behind the "pause" in your makecab batch.
Not so experienced User could get ... hm ... irritaded by "100.00% [flushing current folder]"
best regards
fwt

thanks for testing. I don't know the XDA_UC so can't say. maybe it keeps a copy in \windows folder and won't work twice with the same file. That was happening on one xml importer a have had once.
the flushing report is from makecab. it is not feeding last line, so pause would owerwrite it's output without redirecting output. But I'll make errorlevel trigger there instead. flushing folder doesn't sounds good, you are right

No Problem ... i'm happy if i can help with this.
Though i'm not really firm with XDA_UC process.
So can't really debug here
But i will test some more stuff like Active Sync.
Code:
<wap-provisioningdoc>
<characteristic-query type="Sync" recursive="true"/>
</wap-provisioningdoc>
but not today ... heading home
bye

More Provisioning Templates
Hello,
Thanks for your tool.
I was wondering if there are other templates for:
Owner Information
Windows Live Messenger
Active Sync Exchange
Facebook
Twitter
Regional Settings
Registry Options that can be set with ~Advanced Config~
It takes about 3 hours to set up my phone after a flash - time consuming controlling installation locations (most to SDCard) and manually registering all the apps I use. The roms usually have Tom's Autoinstall, but I need to have settings in xmls/cabs to be more efficient.
Thanks in advance!

.RGU file entries not applied.

While cooking my ROM for testing under emulator, i create a directory called "MyTweeks" and copy it under sys folder.
That directory includes the following files:
1- "mytones.mp3".
2- "initflashfiles.txt" --> empty.
3- "option.xml" --> contents are not necessary.
4- "7fd5181e-f7fc-4404-908a-7f71e2568c53.rgu"
The .RGU file includes:
REGEDIT4
;
; Set Default RingTone
;
[HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0]
"Script"="apr"
"Sound"="\\Windows\\mytones.mp3"
After the ROM boots-up, i found the .MP3 file copied successfully to \windows directory, but the registry tweak is not there
can any one tell me what's wrong with this .RGU?
Also, any registry entry is missing....

You should post this to the respective kitchen thread to get an answer.

you better check for duplicated GUID(number) or post your whole rgu contents. do you have enter(empty line) at its end?
eventually - another guid has priority because of overall number rule(thus your tweak is overwritten by another rgu).
and ignore posts like above...it's typical here;/(you know +1 to posts count, but 0 help given).

pupakota said:
you better check for duplicated GUID(number) or post your whole rgu contents. do you have enter(empty line) at its end?
eventually - another guid has priority because of overall number rule(thus your tweak is overwritten by another rgu).
and ignore posts like above...it's typical here;/(you know +1 to posts count, but 0 help given).
Click to expand...
Click to collapse
Your comment sounds good for me.
I already post all the content of the .RGU file as above, nothing more in the file.
Yes, i entered a blank line just before the end of the file.
There is no other GUID with the same name in the whole project at all, it is actualy unique number like this:
7fd5181e-f7fc-4404-908a-7f71e2568c53.rgu

How can i give this .RGU a priority? or make the changes after all other changes?
if this question couldn't be answer here, where exactly should i post (whitch Threads)?

higher number has higher priority(at last in normal kitchens), so ffxxxxxx- will overwrite 7fxxxxxx-.
just do search for HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0 on whole kitchen(UNICODE search) to determine, if that reg entry is doubled/tripled etc...also, make another search(ascii search) for same reg entry regarding provxmls(as it's another way of reg import, and this is overwriting all rgu's eventually).
on the other hand i wonder about mp3 as ringtone, are you sure, if that file is ok(i mean, if it really work as ringtone on your actual rom)? sometimes system sets ringtone to default, if file set is let's say..bad.
btw, do not make guid by yourself, use tool for this:
www.guidgen.com
ahhh, another thought:
try to add
"DefaultSound"="\\windows\\xxx.xxx"
to your reg.
|
v
Code:
REGEDIT4
[HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0]
"Script"="apr"
"DefaultSound"="\\Windows\\mytones.mp3"

pupakota said:
higher number has higher priority(at last in normal kitchens), so ffxxxxxx- will overwrite 7fxxxxxx-.
just do search for HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0 on whole kitchen(UNICODE search) to determine, if that reg entry is doubled/tripled etc...also, make another search(ascii search) for same reg entry regarding provxmls(as it's another way of reg import, and this is overwriting all rgu's eventually).
on the other hand i wonder about mp3 as ringtone, are you sure, if that file is ok(i mean, if it really work as ringtone on your actual rom)? sometimes system sets ringtone to default, if file set is let's say..bad.
btw, do not make guid by yourself, use tool for this:
www.guidgen.com
ahhh, another thought:
try to add
"DefaultSound"="\\windows\\xxx.xxx"
to your reg.
|
v
Code:
REGEDIT4
[HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0]
"Script"="apr"
"DefaultSound"="\\Windows\\mytones.mp3"
Click to expand...
Click to collapse
1- MP3 as a ringtone is working fine if i manually change it. why you're wondering about that?
2- I tried to do the registry manually after booting, it works great. but in kitchen it isn't.
3- I tried many time to Generate a UUID by the help of the site you sent me with no success.
4- I did a search in the project and found the following:
Search "RingTone0" (4 hits in 4 files)
G:\HTC-HD2\Work\SYS\OS\mxipupdate_metabase_001.provxml (1 hits)
Line 1: <?xml version="1.0"?><wap-provisioningdoc><characteristic type="Metabase"><characteristic type="FileOperation\%CE2%\MenuUpArrowDisabled.bmp\*" translation="install"><parm name="datatype" value="string" /><parm name="semantic-type" value="file" /><parm name="rw-access" value="3" /><parm name="access-role" value="88" /></characteristic><characteristic type="FileOperation\%CE2%\MenuUpArrowBackground.bmp\*" translation="install"><parm name="datatype" value="string" /><parm name="semantic-type" value="file" /><parm name="rw-access" value="3" /><parm name="access-role" value="88" /></characteristic><characteristic type="FileOperation\%CE2%\MenuUpArrow.bmp\*" translation="install"><parm name="datatype" value="string" /><parm name="semantic-type" value="file" /><parm name="rw-access" value="3" /><parm name="access-role" value="88" /></characteristic><characteristic type="FileOperation\%CE2%\MenuSelector.bmp\*" translation="install"><parm name="datatype" value="string" /><parm name="semantic-type" value...
G:\HTC-HD2\Work\SYS\Phone\2a6583ff-6047-46cc-b9be-b7deca1152c3.rgu (1 hits)
Line 125: [HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0]
G:\HTC-HD2\Work\SYS\Shell\mxip_system.vol (1 hits)
Line 71: 

G:\HTC-HD2\Work\SYS\zzz_MyTweeks\ffe8dc40-7d63-11e0-a411-0800200c9a66.rgu (1 hits)
Line 17: [HKEY_CURRENT_USER\ControlPanel\Sounds\RingTone0]
5- I tried "DefaultSound" with no success.
Thanks.

You didn't mention a .dsm. I suspect you need to create one with the same guid as the .rgu.

Farmer Ted said:
You didn't mention a .dsm. I suspect you need to create one with the same guid as the .rgu.
Click to expand...
Click to collapse
I used "totalfire" to create one but the same problem still there.
also, if i removed it from the folder, the BuildOS creates a dummy one with the same results.
really, i fed-up, but i'm thanking all of you whom tried to help

I just need any one of whom success to apply his own registry tweaks in his cooked ROM to tell me how he did it..
As Simple As this....
edit.. I attached the files that i need it to be installed...

ok, this may be weird what i am gonna write, but have you tried to place your ringtone in proper place designed for additional ringtones by initflashfiles?
here's catch - some things WONT work when not COPIED while first boot.
i have no time for explaining this, but try to edit initflashfiles to copy this ringtone to proper place, than edit reg to match.
and another interesting thing: try to rename Mytones to mytones.
before this - check one thing with rom that was not working earlier - make sr, and go into windows to see, if your file became..folder.
there's small chance of getting weirdness with files with capital letters in name, sometimes.
and finally - did you make softreset before checking, if ringtone is set after flash(do NOT check this before first softreset)?
and postfinally - convert your file to something native for WM(weak advice, but...).
btw, skip dsm for this, it is useless for such things.

@pupakota
I tried but still something wrong.
I have no problems with the file copy, the file copied successfully.
The problem with the registry entries... any registry entries within the .RGU file didn't applied after flashing the ROM or even First Softreset after first boot.......
There are nothing changed in the emulator registry for any of the registry entries.

one thing, you are making this for emulator(Oo)?
have you checked your pack on real device?
you shouldn't take emulator behaviour as sure mirror of real thing...

You should try putting another registry key into that .rgu; it could just be a dummy key (like hklm\software\test). Then see if it is parsed during cooking. It's starting to sound more like a provxml is over-writing your values during bootup.

Farmer Ted said:
You should try putting another registry key into that .rgu; it could just be a dummy key (like hklm\software\test). Then see if it is parsed during cooking. It's starting to sound more like a provxml is over-writing your values during bootup.
Click to expand...
Click to collapse
That's exactly what happened.
The Dummy was not posted.
So, Whitch provxml is over writing my REG? or how i could come over this prob?.

robekia1 said:
That's exactly what happened.
The Dummy was not posted.
So, Whitch provxml is over writing my REG? or how i could come over this prob?.
Click to expand...
Click to collapse
Search for all provxml in oem, and go through them!