hey there,
i created an oem package which contains an dll file, one that exists also in the sys-folder as folder (contains imageinfo.bin and s000), when cooking with my kitchen buildos gives an error, something about that the expected file already exists as folder...
what can i do?
It's not a good idea to over-write a module; in fact, it's a bad idea, because it crashes most kitchens (buildos will crash every time).
1. Why are you trying to over-write a module with a file?
2. If you really want to do it, you need to remove the module from the sys directory. I'm not sure it's a good idea myself; you should at least convert the file to a module. If you don't know the difference between a file and a module, then you should search and find the answer. It's easy enough to do.
It would help a great deal when you start a topic if you give more information. What build are you using? What device? Most importantly, what module are you trying to replace?
Thanks Ted,
sorry for the small amount if informations. I'm using EXEcutor von pako777, it's kitchen tool for the omnia 2... almost, it dissambles the dump-file, then i can delete/add files and then it assembles it again... some kitchens i saw over here a really great, but the executor get the work done...
i found the informations, thanks for the hint i will now try reversmode.exe
right now i want to convert a taskbar.cab to an oem package and so i need to replace shellres.192.dll and some other files
I think that kheb 1.1 (search, it's easy to find) is the best way to make a package for your cab. Just run a snapshot, install the cab, then run another snapshot (+difference). Select the 'make an oem' function. It doesn't make a working oem, but it will dump the reg keys that you need, and collect all the files (I assume they'll all go to windows). It sounds like you're building the rom straight from a dump, and not with full packages? Then you'll need to just swap the new files in for any old ones (as well as add new ones), and figure out how to add the registry keys, if there are any. I guess you can use ceregeditor or something similar to import the keys into the default.hv. Convert files to modules, if that's how the dll's appear in the dump.
You have to be a little careful with an app like kheb (or sk tracker): it may dump out some extraneous files or reg keys, as changes occur all the time to a device's registry and file system. Make sure you separate the wheat from the chaff. It's best not to soft reset after the cab install, if you're prompted to do so. That creates a butt-load of random new reg values that are irrelevant. If any certificates are installed by the cab, you can probably ignore them.
Thanks again, but i used the package creator from ervius to convert the cab, converted the rgu to an provxml and the dll-files with reversmode and everything worked fine
but i will take a look onto kheb, sound promising when converting a cab with setup.dll
Related
Hi there,
I'm pretty experienced with rom cooking, but need a bit of direction from the pros here in a project I'm working on.
I have a working WM6 rom that I'm looking to make a kitchen for in order to more efficiently customize the rom.
I've decoded the rom to nba/fat format (my device uses nba/nbf format) and dumped the imgfs to a dump folder without any issues and can edit the rom that way, but I'm looking to make a kitchen.
I've used bepe's package tool to convert my dump into OEM & SYS folders without any problems. I now just need to be pointed in the right direction on how to rebuild these packages back into a working nba/fat file.
I've tried putting the OS & SYS directories in an existing kitchen like the bepe/helmi/scoter kitchens and using the imgfs tools there building the packages back into a rom. The rom builds successfully but then won't boot past the initial splash screen after flashing it.
Is there something else I need to do? Is it possible Bepe's package tool isn't properly building the packages?
Any help is appreciated. Thanks for everything each of you does to help the community
anyone?
I'm no expert, but everytime I've tried to dump a rom then rebuild it and flash it, it freezes at the 2nd splash screen. I never could get it to work, then I read somewhere that if the RGU files are missing then it would fail to boot, and sure enough on every rom I tried to dump, the RGUs were gone
My advice would be to build your rom with an existing kitchen. Collect all the packages you can find, build the ones you can't. Save all your custom graphics, themes, sounds, ringtones. Export all the registry keys for the programs you have on your phone now and use them to tweak your packages. It really won't take you much longer than if you were able to use the one you dumped. Before you know it, the kitchen you put together will be so much better than the ROM you dumped that you'll forget all about it!
My kitchen is a work in progress, but right now it's SO close to the way I want it that I can do Hard Resets without a thought as the only thing that needs to be done afterwards is restore my contacts!
All my connection settings are there, all of the buttons are set the way I like, all the colors, graphics, themes...everything! I've even set up an extrended rom with custom cabs I put together with all my commerical software with the Registration keys built-in.
I can't recommend a kitchen since I haven't used them all, but I started with Octaivio's with a 1437 build rom, now I've replaced that base rom with the 1908 build one from his latest kitchen and it's worked fine. The reason I used Octaivio is because he used Pbar as a taskmanager instead of that awful useless HTC x button (remnants of it still pop up when switching from portrait to landscape and vice versa).
joemanb said:
I'm no expert, but everytime I've tried to dump a rom then rebuild it and flash it, it freezes at the 2nd splash screen. I never could get it to work, then I read somewhere that if the RGU files are missing then it would fail to boot, and sure enough on every rom I tried to dump, the RGUs were gone
Click to expand...
Click to collapse
I can easily dump a rom, change it, rebuild it and use it successfully. That's not my issue. And, by the way, you were given misinformation about the rgu's. The rgu files are supplementary registry files that are merged into the main hives for each specific package, to make the registry entries modular. Even if you were to delete some rgu files, your device would still boot but wouldn't have the desired behavior for the packages you installed as some registry entries would be missing
My advice would be to build your rom with an existing kitchen. Collect all the packages you can find, build the ones you can't. Save all your custom graphics, themes, sounds, ringtones.
Click to expand...
Click to collapse
There are still a number of devices where no kitchen exists--mine is one of them, and honestly I'm not looking to use someone else's--I'd prefer to make my own
I just need someone to tell me what needs to be done to convert the OEM & SYS directories generated by bepe's package tool back to a working rom.
Steps I'm attempting now:
1) Dump original rom to dump folder
2) Run Bepe's package tool to make SYS & OEM folders.
3) Add modules
4) Run G'Reloc to fix overlapping modules.
5) I run BuildOS which makes the dump in the temp folder from the SYS & OEM folders.
6) I copy the original rom's fat(nba) to a temp folder
7) I dump imgfs from fat(nba) to imgfs bin file in temp folder with prepare_imgfs.exe
8) I merge the dump back into imgfs bin file with buildimgfs.exe
9) I put imgfs back into the fat(nba) with make_imgfs.exe
10) I convert nba back to nbf to flash
11) I flash the rom successfully.
12) Doesn't get past splash screen
Can anyone tell me what I'm missing or what could be making this non-bootable?
Thanks.
So its not the RGUs..
Please, if you figure this out, post the solution. When I ran into this, I searched all over the forum for a solution and found at least 2 or 3 other posts with this problem, but never a response.
Good Luck
have you modified the Iniflashfile.txt? thats the step most leave out and then it wont boot past the second splash screen
austinsnyc said:
have you modified the Iniflashfile.txt? thats the step most leave out and then it wont boot past the second splash screen
Click to expand...
Click to collapse
No, at this point I'm not trying to change the initflash so I haven't modified it. I know that when the time comes to change it I'll need to do the hex edit thing for the first 2 bytes, the unicode and the last line empty,. etc.
Also I'm not even getting to the 2nd splash. I'm not getting off the initial splash screen.
I'm thinking at this point the imgfs isn't getting put back together properly.
There have got to be some old pros who can tell me what I'm doing wrong.
I think I found part of the problem. In step 5, CreateOS.exe is doing something wrong with the hives. After running it, default.hv which is 770K+ in sys/metadata goes down to like 42K.
Anyone know why this is happening?
source said:
I can easily dump a rom, change it, rebuild it and use it successfully. That's not my issue. And, by the way, you were given misinformation about the rgu's. The rgu files are supplementary registry files that are merged into the main hives for each specific package, to make the registry entries modular. Even if you were to delete some rgu files, your device would still boot but wouldn't have the desired behavior for the packages you installed as some registry entries would be missing
There are still a number of devices where no kitchen exists--mine is one of them, and honestly I'm not looking to use someone else's--I'd prefer to make my own
I just need someone to tell me what needs to be done to convert the OEM & SYS directories generated by bepe's package tool back to a working rom.
Steps I'm attempting now:
1) Dump original rom to dump folder
2) Run Bepe's package tool to make SYS & OEM folders.
3) Add modules
4) Run G'Reloc to fix overlapping modules.
5) I run BuildOS which makes the dump in the temp folder from the SYS & OEM folders.
Click to expand...
Click to collapse
At this point I think that you have the XIP extracted already, in order to create valid boot.rgu
6) I copy the original rom's fat(nba) to a temp folder
7) I dump imgfs from fat(nba) to imgfs bin file in temp folder with prepare_imgfs.exe
8) I merge the dump back into imgfs bin file with buildimgfs.exe
9) I put imgfs back into the fat(nba) with make_imgfs.exe
10) I convert nba back to nbf to flash
11) I flash the rom successfully.
12) Doesn't get past splash screen
Can anyone tell me what I'm missing or what could be making this non-bootable?
Thanks.
Click to expand...
Click to collapse
It's a suggestion, but i think you're missing the .rgu files.
Of course, those are not needed when flashing, but when BuildOS creates the default.hv and user.hv...these 2 being invalid, the OS can't boot.
Probably Bepe can clear you better on that one.
Cheers !
source said:
And, by the way, you were given misinformation about the rgu's.
Click to expand...
Click to collapse
Apparently not, after reading Anichillus' response (which agreed with mine) I converted the HVs to RGUs and it WORKS finally!
It's probably not a good idea to reject info out of hand like that..You almost had me convinced. Thankfully I always try to verify information before I accept it, or tell someone they're wrong, mistaken, or misinformed.
Thanks Anichillus!
Hello all. I'm looking for some pointers and I'd greatly appreciate any help you can give.
I'm starting to make some OEMs out of cab files, and I've pretty much got that part down. The problem I am having is making an OEM out of a cab that utilizes a setup.dll file.
I have taken a registry snapshot before and after installing one of these cabs, but it is still missing something. Am I just SOL? Does anyone know of an app that will "decompile" the .dll file so I can see the install_exit and install_init calls?
My other option was to modify these cabs so that they have hard coded paths and force them to install without user interraction. Then dump them in /windows, make a mortscript in /windows/startup that will install the cab, delete the cab, then auto delete the mortscript. Does anyone have a better way of doing this?
I do it the old fashion way. Dump registry, install app, dump registry again and then Use windiff to see the new reg entry's. Also grab all the files on the ppc from the cab. (sometimes Setup.dll renames files in cab)
After you do a few, it'd becomes as easy as a regular cab. If you need help let me know.
If there is an easier way i don't know it. I hope there is though.
Hi, I have a folder with a couple of folders in it that each contain a whole lot of files. I want to cook this folder (with its subfolders) in a rom and place it in the device root folder.
I wonder if there is a utility that can automatically generate a app.dat file from this folder?
Why not Zip it up with an unkown extension, then unzip with Mort (can handle unkown zip extensions).
Using initflashfiles file operations slows up filesystem.
(using unkown filetypes and folders does not)
Sorry if i sound like a broken record to some.
appelflap said:
Hi, I have a folder with a couple of folders in it that each contain a whole lot of files. I want to cook this folder (with its subfolders) in a rom and place it in the device root folder.
I wonder if there is a utility that can automatically generate a app.dat file from this folder?
Click to expand...
Click to collapse
you could make a cab with wince cab mgr(it supports drag n drop of folders) then convert the cab to ext pkg or run it in customization.
twopumpchump said:
you could make a cab with wince cab mgr(it supports drag n drop of folders) then convert the cab to ext pkg or run it in customization.
Click to expand...
Click to collapse
Brilliant! Thanks
twopumpchump said:
you could make a cab with wince cab mgr(it supports drag n drop of folders) then convert the cab to ext pkg or run it in customization.
Click to expand...
Click to collapse
For a more Freeware solution (but without the easier Drag and Drop support)
http://forum.xda-developers.com/showthread.php?t=530710
Extenddir Cab Maker.
Noonski said:
For a more Freeware solution (but without the easier Drag and Drop support)
http://forum.xda-developers.com/showthread.php?t=530710
Extenddir Cab Maker.
Click to expand...
Click to collapse
Thanks, fortunately wince cab maker has a generous trial period. For that one time I have to put all copilot map files in a cab, it is the best option. Thanks anyway
Cabs suck, they're a pain in the butt to make and take forever to install. Just do what Noonski said and make a zip file. They install in seconds, whereas big cabs can take minutes. Here's the basic format I use; this zip file goes to the device root, which is what you want (you need the right # of \'s to get it to work). First, I have a zip file named 'root.zip'. Then, I name the mortscript Unziproot.mscr. Here's the script:
Code:
UnZipALL("\Windows\root.zip","\\")
To get it to execute, I add this to an add2config.txt file:
Code:
EXEC:\WINDOWS\Unziproot.mscr
Zip files are a helluva lot easier to make than cabs; I do it all the time with total commander on the device, and it takes just a few seconds. They're trivial to edit, too. I've attached a zip file that has the add2config.txt, the mortscript, and also a simple mortscript package that works well. Seriously, just listen to Noonski.
Edit: Make sure the mortscript doesn't have any spaces in it. If you name it "Unzip root.mscr", it won't run during customization (been there, done that, lol).
Hey Noonski.. how about we make a script, or an executable that we can plug in a kitchen batch file right before IMGFS gets created, that can look at at an initflashfiles.dat, analyze it, line by line, then create a zip with all the files its supposed to move then copy an almost blank initflashfiles.dat back in the "dump" directory. We could even do this in mort for windows!
NRGZ28 said:
Hey Noonski.. how about we make a script, or an executable that we can plug in a kitchen batch file right before IMGFS gets created, that can look at at an initflashfiles.dat, analyze it, line by line, then create a zip with all the files its supposed to move then copy an almost blank initflashfiles.dat back in the "dump" directory. We could even do this in mort for windows!
Click to expand...
Click to collapse
TPC mentioned doing something like that in the extendir thread. I will say this, I've tried to install my entire start menu with a zip file, and the bugger wouldn't work. The script worked fine after bootup, but it wouldn't run during customization. I don't know what the deal was. I only tried it a couple of times, though, but I don't think that I just did something really dumb.
Farmer Ted said:
TPC mentioned doing something like that in the extendir thread. I will say this, I've tried to install my entire start menu with a zip file, and the bugger wouldn't work. The script worked fine after bootup, but it wouldn't run during customization. I don't know what the deal was. I only tried it a couple of times, though, but I don't think that I just did something really dumb.
Click to expand...
Click to collapse
That should be an easy thing to fix...
yeah i have actually made zips for every file that goes somewhere besides windows, you wont believe the amount of space this saves and how much faster your rom is it is alot of work, one way that makes it a lil easier is to make a list of all the files that are in your zips then have your .bat delete them from dump before imgfsfromdump.exe runs in kitchen....but we could do it better and easier im sure if we just all put our heads together
Wow good idea, that's taking it into a whole new level, automating it.
It's about time this method creeped it's way from the method of a few to something that everyone can take advantage of.
It's one of the most underused methods for a bit more speed, instead of improving filesystem cache settings, reducing the stress on the file system.
(totally made the above up, I just threw a few interesting words i have been reading here and there, before people start thinking I actually understand the file system at a low level) I just know from experience and just doing it that there's advantages.
It's batching beyond my expertise (low level but creative ).
But i'm pretty sure there's a few good men for the job.
HowdyKeith and RoryB come to mind when it comes to Mort Syntax and reading values from files.
Their Batching knowledge should also be good.
But if this is do-able, then why not also not try to get rid of .provxml files to, and speed up the first boot time. Provxml is the second killer of speedy first boots.
Noonski said:
Wow good idea, that's taking it into a whole new level, automating it.
It's about time this method creeped it's way from the method of a few to something that everyone can take advantage of.
It's one of the most underused methods for a bit more speed, instead of improving filesystem cache settings, reducing the stress on the file system.
(totally made the above up, I just threw a few interesting words i have been reading here and there, before people start thinking I actually understand the file system at a low level) I just know from experience and just doing it that there's advantages.
It's batching beyond my expertise (low level but creative ).
But i'm pretty sure there's a few good men for the job.
HowdyKeith and RoryB come to mind when it comes to Mort Syntax and reading values from files.
Their Batching knowledge should also be good.
But if this is do-able, then why not also not try to get rid of .provxml files to, and speed up the first boot time. Provxml is the second killer of speedy first boots.
Click to expand...
Click to collapse
it would be awesome to have a tool that reads initflashfiles.dat from dump, puts all the files that go in other folders besides windows in a zip file also would be nice to be able to select a list of files to go into extendir\windir as well.
Noonski said:
Why not Zip it up with an unkown extension, then unzip with Mort (can handle unkown zip extensions).
Using initflashfiles file operations slows up filesystem.
(using unkown filetypes and folders does not)
Sorry if i sound like a broken record to some.
Click to expand...
Click to collapse
Hi Noonski, I think these are really great ideas. One question about your comment on iniflashfiles slowing down the system, are you referring to the startup time on first boot? Because I fail to see where the speed would be effected in general terms as the only function of the iniflashfiles is to specify where files get placed other than windows. Once they are moved in to the correct places the files is useless. So I don't see how the speed could be any different than with a zip other than the customization time being reduced. Of course I could be wrong. lol
Meant it more in the way that you then do not actually need that file to be in Rom, and therefore in the Windows folder. That's where i meant the most gain was.
Not sure if there's any other extra difference between a file that has been copied from Windows to a sub-folder or an extracted one, other then that it won't be read only and not present in Windows.
Well if you have a zip file with folders and files inside that folders
and you make a script that copies these folders to the corresponding dirs on the device you accomplish what you are asking here isn't?
twopumpchump said:
it would be awesome to have a tool that reads initflashfiles.dat from dump, puts all the files that go in other folders besides windows in a zip file also would be nice to be able to select a list of files to go into extendir\windir as well.
Click to expand...
Click to collapse
Hmmm if every file in a rom was moved without leaving a copy on the windows root I wonder how many files would be eliminated. Im guessing quite a few. Im thinking the only way this would work would be for a mod to be made for EVK allowing all the initflashfiles.dat info and app.dat info to be compiled and a zip created from them.( Not sure a simple zip could properly place that many files?) Then the files placed inside the zip would need to be deleted before the rom is compiled. Theoretically I think its possible.
@L26
Yeah your right. However I think the biggest thing to look at is there a easier way than doing it all by hand It would take forever to take every file moved by the .dat files and make a zip. Not to mention updating the files for new versions would be a PITA
aruppenthal said:
Hmmm if every file in a rom was moved without leaving a copy on the windows root I wonder how many files would be eliminated. Im guessing quite a few. Im thinking the only way this would work would be for a mod to be made for EVK allowing all the initflashfiles.dat info and app.dat info to be compiled and a zip created from them.( Not sure a simple zip could properly place that many files?) Then the files placed inside the zip would need to be deleted before the rom is compiled. Theoretically I think its possible.
Click to expand...
Click to collapse
amazing, check my post and scripts in this same forum ... I was trying to do the same (only with shortcuts for now): cook shortcuts without leaving double files in windows folder, so I remove all shortcuts from the kitchen and once cooked I create the provxml with mortscript reading an ini file and inject the provxml files to the kitchen and the cook again. Of course I only include files present in the ROM. How can I avoid cooking twice?. the script also zips and copies all the files that will be needed for the scripts that run at first boot, including the files only if the modules are in the kitchen.
May be a mod in EVK to runwait scripts before creating the nbh could open a lot of new ways of cooking without using windows directory.
@noonski, do you care taking a look at my script building the provxml file? I am pretty sure you will have lots of suggestions on how to progress further.
cruiserrr said:
amazing, check my post and scripts in this same forum ... I was trying to do the same (only with shortcuts for now): cook shortcuts without leaving double files in windows folder, so I remove all shortcuts from the kitchen and once cooked I create the provxml with mortscript reading an ini file and inject the provxml files to the kitchen and the cook again. Of course I only include files present in the ROM. How can I avoid cooking twice?. the script also zips and copies all the files that will be needed for the scripts that run at first boot, including the files only if the modules are in the kitchen.
May be a mod in EVK to runwait scripts before creating the nbh could open a lot of new ways of cooking without using windows directory.
@noonski, do you care taking a look at my script building the provxml file? I am pretty sure you will have lots of suggestions on how to progress further.
Click to expand...
Click to collapse
isnt the simplest way just to go to your windows folder on your phone and copy Start Menu folder to your pc, create a list of the files that are in that folder and use .bat to delete them while cooking, zip that folder up and put it in kitchen or sdcard and use .mscr to unzip to windows directory at first boot? you only have to cook once this way
twopumpchump said:
isnt the simplest way just to go to your windows folder on your phone and copy Start Menu folder to your pc, create a list of the files that are in that folder and use .bat to delete them while cooking, zip that folder up and put it in kitchen or sdcard and use .mscr to unzip to windows directory at first boot? you only have to cook once this way
Click to expand...
Click to collapse
well, do not want to go offtopic of this post. The idea is to cook automatically with no errors. My method cooks only what is needed without putting files to windows folder. Basically I only have to run twice when changing modules included. If it is only about changing icons, order, etc I simply run the script and cook. If it is about customization I would certainly do like you say (I have done it many times in the past). If it is about cooking should be more automated. Is complex to build but now I only define the INI files parameters: icon, parameter, folder, order... (I have not touched the mortscript since I completed it). Anyway, my building method as its own post. I just found similar ideas behind in this thread and tought they could converge.
I was hoping someone could help me out. I've been trying for a while to make a working OEM out of a few sense 2.5 cabs. At the moment I have 2 to choose from, one posted on modaco(thread http://www.modaco.com/content/i8000...07676/noobody-and-rapid-sense-2-5-rom-nxxje2/ and file link http://www.4shared.com/file/uV-HPoiM/nOObody__Rapid_Sense_252011_Rh.html) and http://www.freeza-inc.com/freezaROM/OEMCAB/fi. Sense - 2.5.2011.3030 for WM6.1 beta.cab(makes it easier, these cabs include full package, I've tried grabbing oem's from ppcKitchen with limited success). I was hoping someone could post a tutorial about converting cabs like such ^^ to an oem package for use with buildOS. Thanks in advance for any help.
This should help
http://forum.xda-developers.com/showthread.php?t=467842
When I use that tool the oem will build but not work. I've tried a few other tools but they also don't create working oems. cab2oem, oemizer etc.
I don't use sense, so haven't installed the cab, but here's how I make more complicated packages: Run sk tracker, and take a system snapshot. Install the cab, and run sk tracker again and take a second snapshot and compare the first two snapshots. Copy all new files to your oem (or EXT). Export all new reg keys to an app.reg or .rgu. My guess is that all the files go into \windows, so you won't need to deal with initflashes.txt files or app.dat files. You may need to get sense running (if it isn't running after the cab install). If you have to start it up (may require a soft reset), then run it and take a 3d snapshot. Compare shots 2 to 3-there could be a few new registry keys. Most are going to be in obvious places, like HKCU(or LM)\software\HTC\Manila, but you may have some certificates installed in odd places as well as random crap you'd never find without sk tracker in HKCR. You probably need all of these keys. The problem with just using an oem creator is that there may be reg keys installed by a setup.dll, or reg keys installed when the program first launches, and you'll miss these.
Remove any setup.dll from the package-it won't be needed. And since you're using buildos, I guess you'll need to create a .dsm (have fun with that-nicest thing about EVK is you don't need them). I guess there may be a startup shortcut, so you'll need the initflashfiles to get it in \windows\startup, unless you use an HKLM\init key to start sense up.
look at the main stickie or kitchen tools repository thread search for cab converter it works... but if your cab has a setup.dll will be hard you need to see whats inside of the setupdll and try to add that things to the OEM mannually like resources or regs
Hi,
I've been cooking my own Roms for a few months and I'm happy with the results.
One big difference I've noted compared with shipped and other master cooks' roms is the first boot time. My last Rom (21683 + Sense) takes over 10min to boot the first time. After the fist boot, the booting time is normal.
Would you have some tips of how to improve it?
Can it be related to the order that the packages are cooked?
or just related to the size of the Rom (about 195 Mb for a Blackstone using LZX compression and CFC manila)?
what compresion do you normally use? LZX, XPR or none?
Anyway to 'slim' my packages more? (I'll try manual PNG compression on my next cook as OSkitchen PNG compression does not work for me)
Thanks in advance.
[Edit]: Thanks for your good advices. now my Blackstone Rom boots in less than 2 min. What I did was:
- Get ride off some provxml and change them for normal reg files.
- Reduce the size of the rom under 180 Mb.
- Manually reduce png and in some case replace by jpgs.
- S2U2 delay start 120 secs.
If someone have additional ideas, pls advise! I'll try!
Well, 195 mb for any LZX rom is a bit too much but this depends of what are you cooking into your rom.
Main things that slow down the boot up are:
provxml files, basically .reg files are much fastets.
Check your Config.txt file , as many files are you trying to install after first boot as ,many time it gets to boot up , these are cabs,mortscripts,provxml.
Dont use png compression if you dont want your theme ruined.
In my Leo i use both LZX and XPR and i have 134 and 158 mb roms.
Leave al the unecessary such default pictures in Album folder,some ringtones and wallpapers, these files are a lot bigs .
ypsmav said:
Hi,
I've been cooking my own Roms for a few months and I'm happy with the results.
One big difference I've noted compared with shipped and other master cooks' roms is the first boot time. My last Rom (21683 + Sense) takes over 10min to boot the first time. After the fist boot, the booting time is normal.
Would you have some tips of how to improve it?
Can it be related to the order that the packages are cooked?
or just related to the size of the Rom (about 195 Mb for a Blackstone using LZX compression and CFC manila)?
what compresion do you normally use? LZX, XPR or none?
Anyway to 'slim' my packages more? (I'll try manual PNG compression on my next cook as OSkitchen PNG compression does not work for me)
Thanks in advance.
Click to expand...
Click to collapse
Yup, provxml's slow things down a ton.
What not to do:
So, you have a reg setting that you put in an .rgu, but it never 'sticks', and you can't figure out why. Someone tells you to put it in a provxml named zzz-BandAid.provxml. Awesome, now the reg setting sticks.
Not so awesome. Now you have two provxml's that run during first boot, one that sets the reg setting to a default value, and a second that corrects the reg setting. XML's are slow (try running one during customization, and you can see just how slow they are).
What to do: Look through all of your provxmls; it's easy to do, just pull them out of the build dump. Find the ones that install reg keys-there are many, and some are huge (mostly the OEM provxml's). Just export the reg keys with a reg editor from your device and put them in an .rgu that gets compiled at the end of your build. Make whatever tweaks you want in that .rgu as well. Make sure you don't eff up the provxml's that install certificates and databases (there are a few that look like reg keys, but it's crap for the databases, so be careful of them). If you use Autorun during customization, there may be an oemprovxml with autorun reg keys in it. Leave that sucker alone; in my experience, it needs to run or else autorun didn't work (I don't use autorun anymore, so I've since deleted it). Put blank or editted (reduced) copies of the provxml's in a package that runs at the end of your build, so that the stock copies are over-written.
You should also look at the apps that run during startup. This slows down first boot a little bit. For instance, you really don't need to have MSVC to run at first boot. So, remove the line in initflashfiles.dat that sends the msvc shortcut into the startup folder. Figure out a way to get it into startup during second boot, like running a cab during customization (slow, though), or better, using a mortscript (fast). There's a lot of other crap that doesn't need to run, like tmail and poutlook (those never need to run at startup, imo). But you need to figure out how to get them to run after first boot, if that's what you want.
Finally, reduce the amount of crap that gets copied into \Program Files. Most apps run fine out of \windows, and using initflashfiles.dat to copy a ton of files is slow and it wastes memory. Just figure out how to make leaner packages. And don't use cab-2-oem converters. They always create packages that copy files out of rom into other directories, which is almost always unnecessary. It's much better to make packages manually (use kheb to find all the files and reg keys, if you can't do it on your own).
My first boot takes ~85 seconds to get to the alignment screen. Removing all the crap from provxml's saved around a minute on the first boot time. 10 minutes is crazy long, you should be able to drop it to 2 min, easy.
WOW
Farmer Ted said:
Yup, provxml's slow things down a ton.
What not to do:
So, you have a reg setting that you put in an .rgu, but it never 'sticks', and you can't figure out why. Someone tells you to put it in a provxml named zzz-BandAid.provxml. Awesome, now the reg setting sticks.
Not so awesome. Now you have two provxml's that run during first boot, one that sets the reg setting to a default value, and a second that corrects the reg setting. XML's are slow (try running one during customization, and you can see just how slow they are).
What to do: Look through all of your provxmls; it's easy to do, just pull them out of the build dump. Find the ones that install reg keys-there are many, and some are huge (mostly the OEM provxml's). Just export the reg keys with a reg editor from your device and put them in an .rgu that gets compiled at the end of your build. Make whatever tweaks you want in that .rgu as well. Make sure you don't eff up the provxml's that install certificates and databases (there are a few that look like reg keys, but it's crap for the databases, so be careful of them). If you use Autorun during customization, there may be an oemprovxml with autorun reg keys in it. Leave that sucker alone; in my experience, it needs to run or else autorun didn't work (I don't use autorun anymore, so I've since deleted it). Put blank or editted (reduced) copies of the provxml's in a package that runs at the end of your build, so that the stock copies are over-written.
You should also look at the apps that run during startup. This slows down first boot a little bit. For instance, you really don't need to have MSVC to run at first boot. So, remove the line in initflashfiles.dat that sends the msvc shortcut into the startup folder. Figure out a way to get it into startup during second boot, like running a cab during customization (slow, though), or better, using a mortscript (fast). There's a lot of other crap that doesn't need to run, like tmail and poutlook (those never need to run at startup, imo). But you need to figure out how to get them to run after first boot, if that's what you want.
Finally, reduce the amount of crap that gets copied into \Program Files. Most apps run fine out of \windows, and using initflashfiles.dat to copy a ton of files is slow and it wastes memory. Just figure out how to make leaner packages. And don't use cab-2-oem converters. They always create packages that copy files out of rom into other directories, which is almost always unnecessary. It's much better to make packages manually (use kheb to find all the files and reg keys, if you can't do it on your own).
My first boot takes ~85 seconds to get to the alignment screen. Removing all the crap from provxml's saved around a minute on the first boot time. 10 minutes is crazy long, you should be able to drop it to 2 min, easy.
Click to expand...
Click to collapse
Thanx for this tut Farmer Ted.
Seems like I also have a lot to do to speed up my first boot
Thanx
Grumps said:
Thanx for this tut Farmer Ted.
Seems like I also have a lot to do to speed up my first boot
Thanx
Click to expand...
Click to collapse
Also check the OEMLang directory for the initflashfiles.dat. Normally, this is 200kb... Mine is 40Kb, and first bootup on my HD2 is 20-30 seconds...
Later bootups are so fast that the HTC Quietly Brilliant animation stops at Brilli and boots the OS...
gotta love farmer teds his reps
i learn from almost every post he makes
think i need some things to be done in my rom to get a even faster boot time
edit: one question though
i just updated ervius kitchen to the latest and it has the future to make provxml files from reg files
if provxml makes the bootup slow wouldnt it be better to make it the other way arround?
all the provxml to reg(just asking as it could be handy for ervius to make it the other eay arround in the kitchen)
miniterror said:
all the provxml to reg
Click to expand...
Click to collapse
Hi,
I don't know if this helps, but there is a tool that you could use for converting some provxml to reg here. It was made for xml --> reg conversion but it is also useful for provxml files that contain "pure" registry settings.
Regards!
Sometimes I have taken the provxml and convert the registry portion to rgu file and delete it from the provxml. Now the provxml only has the file operation and certificate stuff in it.
The thing you have to be careful about is rgu happens early in the boot and provxml happens latter. I learned the hard way by not figuring out why my rgu tweak did not happen. It was another provxml that overwrote the reg settings. Once I found it and deleted those lines everything worked the way I wanted.
RoryB said:
Sometimes I have taken the provxml and convert the registry portion to rgu file and delete it from the provxml. Now the provxml only has the file operation and certificate stuff in it.
The thing you have to be careful about is rgu happens early in the boot and provxml happens latter. I learned the hard way by not figuring out why my rgu tweak did not happen. It was another provxml that overwrote the reg settings. Once I found it and deleted those lines everything worked the way I wanted.
Click to expand...
Click to collapse
For this, OSBuilder is the best. You can see the whole registry before you compile, and you can look up what file causes the changes. It really makes cooking a whole lot easier...
Great thread, thanks for the tips.
What I'm gowing to try is search all provxmls in my kitchen and convert them to one big reg.
Make a new EXT package and name it 'zzzSample' so I'm sure it overwrites all other regs.
If an error exist in the reg created by provxmltoreg the new integrity check in Oskitchen will point me to it so I can easy locate and fix.
After that I delete all provxmls.
But first a backup.
Cheers,
Leo
Edit; btw I think you need to take in consideration that some provxml's contain path which are language depended.
So here's my next tip, create a package which contain these regs in separate files.
zzzSample/
0409/app.reg
0413/app.reg
etc...
Farmer Ted said:
Yup, provxml's slow things down a ton.
Click to expand...
Click to collapse
Great info, just wondering should it be possible to build a rom and make a backup of the registry, once you have that backup, edit the backup and place it at the end of the kitchen and delete all the provxml-files.
I've recently tried to make a little application for converting provxml files to reg files.
Thanks to AlexVallat's XmlToReg this was possible and I'd like to share it with you guys. Still all the credits go to Alex!
It is supposed to handle all provxml files, meaning even those which have other entries along with registry entries.
The most important feature that I tried to implement is recursive conversion of provxml files in order to automatically do in a few seconds what Laurentius described here:
Laurentius26 said:
What I'm going to try is search all provxmls in my kitchen and convert them to one big reg.
Click to expand...
Click to collapse
Example :
To parse all provxml files inside OEM folder(and all included sub-folders) type in cmd prompt:
Code:
xml-2-reg_gui.exe r:OEM
When it's done, you'll get all the converted reg files in a subfolder where the application is placed.
If the provxml files had other entries along with registry entries, they will be left where they were but "reduced"(the registry entries will be removed).
If the provxml files didn't have any registry entries, they will be left where they were untouched.
If the provxml files had only registry entries they will be deleted after convertion.
Backing up of provxml files is done automatically.
So try it and see for yourself if it makes things easier or not...
Regards!
EDIT :
I've made a revised version of the tool which isn't based on AlexVallat's XmlToReg but does the same job plus the reverse here.