[ 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
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:
<!--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_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:
<!--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_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:
<!--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 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.
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