Database Users

Remove files from ROM

How can I remove from the original ROM some files like T-Mobile, AIM ... etc. ?
I cooked up a 4.00.10 T-Mobile with GPRS monitor and batterypack but i want some more addons.
Can someone tell me what steps are required to remove from the ROM some files ?
Thanks,
Decebal

ROM = Read Only Memory.

But, i've we're able to add Programs to the ROM in the ROMkitchen, i think we're also able to remove programs.
Regards
Stefan

cruisin-thru said:
ROM = Read Only Memory.
Click to expand...
Click to collapse
obviously i do not deserve that
i was talking about the ROM image and since i've already succeded in putting into the ROM two apps i want to try something else.
so if anyone know how to remove at least T-mobile and AIM files from the image i'll be happy.
thanks,
Decebal

I believe they are in an area not able to be modified.

I was just quoting from that site, it does state that it cannot be erased, modified etc, no offence meant here. :roll:

The mkrom tools will allow you to 'unpack' a rom, i.e. extract all the files that are in it.
A rom, to the best of my understanding, has a 'native' or stock part to it, and then a series of XIP chains -- programs that are added into the free spaces of the rom.
I dont know what happens if you try to remove files from a rom that are part of the standard build...
Maybe the TMobile stuff is in a 'removeable' section of the ROM... there is also the 'operator' section... I am assuming that is a location that will give the 'operator' or creator of the rom space to put specialized programs, such as TMobiles phone apps, etc.
So, it seems that your best bet is to get the mkrom tools and read about how to extract/remove files/rebuild a rom.
Hey, it may even work!
J

You can rebuild a rom image from extracted files and leave some files out but Mkrom does not use compression and therefore the rom you end up with will probably be bigger than the rom you started with.
Richard

If I am correct, an eeprom is something else than a flash-rom.
so the article at least states it incorrectly.
if it is flash, you should be able to modify it.

XDA developer Itsme said:
If I am correct, an eeprom is something else than a flash-rom.
so the article at least states it incorrectly.
if it is flash, you should be able to modify it.
Click to expand...
Click to collapse
Now, I do think that the real question is "How do we unlock the 'ROM' so that it can be modified being that it is an eeprom?"
Misterdollymaker

you need backup the ROM to *.nb1 or *.nbf file, than using tools to add/delete file to *.nb1 , write the new file back to XDA ROM. it is fun to add/delete file to your personized ROM!

cgigate said:
you need backup the ROM to *.nb1 or *.nbf file, than using tools to add/delete file to *.nb1 , write the new file back to XDA ROM. it is fun to add/delete file to your personized ROM!
Click to expand...
Click to collapse
this is quite interesting...can you elaborate further?? I wish to learn more...

cgigate said:
you need backup the ROM to *.nb1 or *.nbf file, than using tools to add/delete file to *.nb1 , write the new file back to XDA ROM. it is fun to add/delete file to your personized ROM!
Click to expand...
Click to collapse
Yes, please! I wish to learn more too! I am looking to remove the standard sounds and replace them with my own (using same names) as well as the boot image and desktop.

yea, no kiddin, i'd like to know how too!
im sure its not impossible, 'they' did it the first time arround.
why not hacking it? and since its all at no charge (no profit) are we realy breaking any patents?

I wanted to know if there is an easy :wink: way around, to put our own programs in the rom. xda-developers certainly can't put ezwap2.5, and the total commander appears to be older version, while new version is much better. There are some more freeware application I'd love to put in there

xda-developers already posted some tools to do job, such as MKROM ...

cgigate said:
you need backup the ROM to *.nb1 or *.nbf file, than using tools to add/delete file to *.nb1 , write the new file back to XDA ROM. it is fun to add/delete file to your personized ROM!
Click to expand...
Click to collapse
I'm interested too
How can i add/delete file from nb1 file?
Thanks
Fabio

I've used mkrom suite to do this (even for Smartphone2002). This are great tools.
Unfortunately it's not as easy as you might think. It's nearly impossible to build a ZERO-KNOWLEDGE ROM file explorer which can add or delete files "on the fly".
You will still have to look for valid gap's in the original rom where you can add a new XIP block.
All .exe and .dll files are "fixed up" that means they MUST run at THE fixed ROM position where they have been initially placed (execute in place). If you dump an exe or dll file you can't use it for other than disassembly to see how things work.
Removing files is a very hard task (they are splitted over the whole rom). And the resulting gap's are mostly not more than 10-16 kB. All you can do is to "hide" files (simply patch the directory entry).
So you see compression is not the real problem (see programers corner for a .bib file which can be used with romimage.exe - a Microsoft Tool to build XIP blocks, this tool supports compression)
John Smith

only the kernel actually runs in the virtual memory area mapped to rom,
all the other XIP stuff runs from a virtual memory area mapped somewhere
in the top of each processes memory space.
( look at the 'real=' values in the output of dumprom )
so for all the other modules it should be possible to move them around
in rom a bit, I think you only need to keep the pagealignment the same.

Hi,
The virtual memory address is also fixed in the module. (That's why I've to rebuild all the stuff I want to copy from other roms).
Since all relocation info is gone the module can't run from another memory position. So the only thing you can do is to move it in it's own XIP section...
John

WM5 ROMfiles dumps [files, modules and registry]

Hello.
History:
My Qtek9090 running WM5 has good CPU, fast graphics and very, very slow filesystem. I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
There exists very handy utility WM5 Files Dumper [thanks buzz_lightyear ]
I think it is a good idea to upload dumps of all files from our PDA's. It would be a good source of information and source of code bricks to cook patches and updates.
Such a dump should contains all files and modules [extracted both from bootloader and OS] and full dump of registry. It should be as clean as possible - just after hard reset, before entering PIN, before adding any contacts and any patches.
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
And again - thanks to our master hackers

I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
And it would not speedup your device - it has a slow ROM.

mamaich said:
/me said:
]I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
Click to expand...
Click to collapse
Probably you are right I'm a lame, but I afraid, that it is true.
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
We have plenty of RAM, so [probably] it is possible to load a lot of dll's into RAM instead executing them from [slow] ROM.
Dlls created with "WM5 Files Dumper" - looks good. I would have to analyze them several times, I would have to ask master hackers is it true, but I would try to load them into RAM.
mamaich said:
/me said:
I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And it would not speedup your device - it has a slow ROM.
Click to expand...
Click to collapse
Yes, of course.
But SPB benchmark told me:
Reading files from \somewhere is 4 times slower then WM2003. It is a good value.
Write files into \somewhere is 6 times slower then WM2003. It is also a good value.
But:
Copy files [OS level] is two times faster than read them and write back. It is not good value.
Retrieve filenames from huge directory is 10-12 times slower, than WM2003. It is also not a good value [it should be comparable to reading files, ie. 4 time slower]
There are two ways:
1. there is something wrong within fatfsd.dll,
2. overhead of executing fatfsd in place is not acceptable,
3. my benchmarks are wrong [I have not enough time to benchmark filesystem without cache

/me said:
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
Click to expand...
Click to collapse
It is here: ftp://xda:[email protected]_WWE_built_1337_42_BlueAngel_by_mamaich.zip
If you think it is a good idea to share WM5 code bricks, upload your your clean dump into
ftp://xda:[email protected]/Uploads/RomFiles_dumps
UserName and Password is here: http://wiki.xda-developers.com/index.php?pagename=BA_FTP_Site search for "xdaupload".

baniaczek said:
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
Click to expand...
Click to collapse
There are 3 types of DLLs used on WM5. First type - normal files, they are loaded into RAM, fixups are processed, etc. They are slow to load (due to fixup processing), but would execute from RAM. Second type - XIP, which are executed directly from ROM and would work slowly. In BA this set of files is executed directly from ROM:
Code:
device.exe
filesys.exe
nk.exe
busenum.dll
cecompr.dll
ceddk.dll
certmod.dll
coredll.dll
crypt32.dll
devmgr.dll
diskcache.dll
fatfsd.dll
fatutil.dll
fsdmgr.dll
fsreplxfilt.dll
hd.dll
imgfs.dll
msflash.dll
mspart.dll
osaxst0.dll
pm.dll
regenum.dll
relfsd.dll
It is much less than was in WM2003.
And WM5 added a new filesystem - IMGFS. It contains compressed modules split to sections, but they are fixed to specific addresses in RAM, they are decompressed to these constant areas and executed from RAM. They are similar to XIP as they also don't contain relocations, but would work fast. I don;t know the correct termin for this type of files.
To replace files in XIP section you'll need this tool - http://forum.xda-developers.com/viewtopic.php?t=33321
if you overwrite any of files I've wrote here by a CAB file or other method without modifying ROM - their old versions would be used instead because they are loaded much earlier than all filesystem drivers.

Thanks mamaich

Registry Question
thanks for the files baniaczek!
does anyone know which file or how the other OS registry entries (the ones not in the boot.hv) get created? There are so many more in a full registry.
thanks!
P.S. thanks mamaich for the great tools!

Re: Registry Question
OS imports *.RGU files on hard reset, and it also reads mxip_*_*.provxml files that also can setup registry items. On Universal and similar devices registry can be set by CAB files in extended ROM.
If you add a new RGU file to OS image it would not be processed. Maybe they should have DSM file with the same name, or be mentioned in [HKEY_LOCAL_MACHINE\System\ObjectStore\RegistryUpdate] key or in packages.sof. I don't know. I always add keys to default.hv/user.hv or edit existing RGU files.

[REF][TUT] Improve program launch times - UPX Squeezer BATCH

this is an old trick that was/is used for older devices to fit WinMo 6 on them
but a side effect is faster application load times
i figured i'd try it on the Blackstone and difference is noticeable
HTCAlbum loads in about 1 Second, before it took about 4
so i'm sharing this with anyone who is interested
The batch file is kept as simple as possible for everyone's ease of use
but this is pretty advanced tweaking, so all common warnings apply
and/or
if you are not comfortable with getting files from/to your PocketPC
and/or
can't figure out how to extract this zip and read the "read me.txt"
and/or
don't know what “any key” is DO NOT TRY THIS!
(read the forum and the wiki a bit more, and you'll gain the knowledge)
Version History:
v 1.0 - initial release
v 1.1 - no icon compression switch added to the batch, for more general compatibility
v alt - here geistteufel has released a new branch of the batch file,
this version uses a different method for packing files and may achieve better compression.
At the same time problems have been reported in the past with this method so all usual warnings apply.
a short list of EXEs that i have UPXed and work well for me
AdobeReaderLE.exe
ASyncKiller.exe
BCR.exe
Camera.exe
FMRadio.exe
GoogleMaps.exe
HTCAlbum.exe
iContact.exe
KeePassPPC.exe
kinoma.exe
Labyrinth.exe
LongPressEndKeyApp.exe
MP3Trimmer.exe
MusicID.exe
Opera9.exe
OperaL.exe
QuickGPS.exe
RSSHub.exe
s2p.exe
s2u2 Settings.exe
s2v.exe
StreamingPlayer.exe
TomTom Navigator.exe
USBtoPC.exe
WMRegOptimizer.exe
YotaCenter.exe
YotaCenterUpdater.exe
YouTube.exe
and here is a list of things NOT to compress
manila.exe
cprog.exe
thumbCal.exe
calculator.exe
wt5jetpr.exe
any DLL
Please share your findings so that others can benefit from it
(SEARCH this thread for your application name or EXE filename)
note: you'll have to repeat this proses after upgrading your applications
big thanks to;
edhaas - for the original simple to use batch file More info in this THREAD
UPX Team - a lot of technical info on the Website
kwbr - for a great ROM
and especially XDA-DEVELOPERS as a whole

Wow!
Thank you for sharing this. This also works great for S2U2. I noticed a difference in loading times. Also applied to this to iGO.exe and a few other .exe's
Thanks again for posting this.
Looks like hdtweak.exe and fdotfreds taskmanger have this done already.

Thanks for your explanations, everything worked fine till I had to copy files to Windows directory: access denied. What must I do to be able to copy files to WD?
Thanks and kind regards,

very very good! I try with commManager, yota contact, opera 9, resco explorer 2008 .....there is a time reduction in all! best performance in yota contacts from 5 seconds to 1 second

If this works so well I wonder why Microsoft doesn't implement it?

upx also works for large dll files!

andrewk21 said:
Thanks for your explanations, everything worked fine till I had to copy files to Windows directory: access denied. What must I do to be able to copy files to WD?
Thanks and kind regards,
Click to expand...
Click to collapse
for that you'll need something along the lines of total commander

i wish we could do this with manilia.exe but i tried and failed, it doesnt load, so had to restor it

I'm also having problem removing protection from some of the files :/
I tried to change properties via Resco Explorer, but without succes. As soon as I remove "Read only" attribute and click "Done", the attribute restores itself and I can't overwrite the new files.
I managed to update Yota; GoogleMaps, Nimbuzz and Opera - all load with visible speed improvement.
Tried Total Commander but can't get it to see my phone

It isnt working on the diamond saber. Icontacts and Yota center went well
WAUWW!!! my TomTom is now really fast!!
Thanks for sharing this app.

andrewk21 said:
Thanks for your explanations, everything worked fine till I had to copy files to Windows directory: access denied. What must I do to be able to copy files to WD?
Thanks and kind regards,
Click to expand...
Click to collapse
some files maybe in memory (used by your phone)
a trick to try is
connect with ActiveSync to the phone
browse into windows folder
rename the file you will be replacing (ex. HTCAlbum.exe to HTCAlbum.old.exe)
copy the UPXed version
restart device and test
if everything works delete the ".old." file
usrname said:
upx also works for large dll files!
Click to expand...
Click to collapse
it does indeed,
but in my experience with less noticeable results and much less reliability
so i didn't mention this
please list any DLLs that you have UPXed with us so that we can all benefit
elite-fusion said:
i wish we could do this with manilia.exe but i tried and failed, it doesnt load, so had to restor it
Click to expand...
Click to collapse
i had the same experience, but
best performance boost for Manila/TouchFLO is CFC compression of images (more info here)

Sir.B, can you please share info on how to remove attributes from System files? Tried through Resco File Explorer, but no effect - still can't overwrite old files, always having errors :/

Wow. This is great!
TomTom V7.450 From 6 down to 3 sec to splash screen!
I wonder if it would be possible to do this to all the exe and dll before cooking.
PocketPlayer also works. But most startup time is the drive scanning.
Google Maps also works, but it started up fast anyway. (also the 2 largest dll worked)
gpsVP works, but was already subsecond.
CommManager.exe worked, was a little faster
AdobeReaderLE worked but despite being a huge program, loaded fast to begin with.
PowerPoint worked but also despite being a huge program, loaded fast to begin with.
CorePlayer reports 'Already compressed'
G-Alarm reports '.net not (yet) supported), except for 2 dll's, they worked.

cybermaus said:
Wow. This is great!
I wonder if it would be possible to do this to all the exe and dll before cooking.
Click to expand...
Click to collapse
yea true, that would be GREAT!!!!! the roms would be superfast!!!!

thanks much for this tutorial. i upxed most of the exes u had listed and MAN, it really changed launch times in the apps. htcalbum is awesome and even s2p is launching faster

Rozenthal said:
Sir.B, can you please share info on how to remove attributes from System files? Tried through Resco File Explorer, but no effect - still can't overwrite old files, always having errors :/
Click to expand...
Click to collapse
i recommendation you read the WIKI and FORUMS,
this is a general question that has been addressed better than i can many times
cybermaus said:
...I wonder if it would be possible to do this to all the exe and dll before cooking.
Click to expand...
Click to collapse
elite-fusion said:
yea true, that would be GREAT!!!!! the roms would be superfast!!!!
Click to expand...
Click to collapse
to replace all EXE & DLL files would be quite an undertaking
because it's such a trial and error process (manila.exe and mode9.dll don't like to be UPX-ed, maybe many more)
and benifits are only noticeble for the largest of files
never hurts to talk with your chefs

Sir.B said:
some files maybe in memory (used by your phone)
a trick to try is
connect with ActiveSync to the phone
browse into windows folder
rename the file you will be replacing (ex. HTCAlbum.exe to HTCAlbum.old.exe)
copy the UPXed version
restart device and test
if everything works delete the ".old." file
Click to expand...
Click to collapse
No matter what software I tried, I just can't get to replace the protected system files.
I tried Resco, I removed the attributes but they're back as soon as I click "Done".
I also tried your described method, but clicking on "rename" in Windows Explorer via ActiveSync - nothing happens. The files seem to be permanently locked

Sir.B said:
i recommendation you read the WIKI and FORUMS,
this is a general question that has been addressed better than i can many times
Click to expand...
Click to collapse
Actually, I have been searching all over forums, but none of the methods described worked for me. Most recommend using Resco or Total Commander, both of which don't work for me. All of the files that have "ROM" attribute simply refuse to be modified in any way.

Thats right. You cannot modify ROM files. You cannot even copy ROM files. You'd have to dump the ROM to PC, which is not trivial. Best to only use this on post-installed programs that are not in ROM.

Interesting: Coreplayer gives me an "already packed by UPX"
Seems they learned this trick before.....

[Solved][Q] EXT packages + app.dat = duplicates of files in \windows\

I tried to keep the title as descriptive and short as possible, I hope it makes sense
I picked up the kitchen of nhathoa (a retired Topaz cook) hoping to get it customized to make it exactly the way I want but I'm running into some issues.
Long story short, I'm using Ervius Visual Kitchen (1.8.2) and I noticed that the EXT packages I added end up leaving two copies of the files, a copy under \windows\ and another one in the places I specified using app.dat using:
Code:
Directory("\Program Files\bla\"):-File("bla.exe","\Windows\bla.exe")
Is there some way to get rid of the copy under \Windows\ ??
I know that I could simply leave everything there and discard the app.dat files but I would really prefer having everything organized properly (I have a bit of an OCD when it comes to organizing everything neatly ).
I'm pretty sure that this is a rather simple and noobish issue but I couldn't find anything relevant by searching and I took a look at some ext packages by various cooks and noticed the same behaviour.

MusikMonk said:
I tried to keep the title as descriptive and short as possible, I hope it makes sense
I picked up the kitchen of nhathoa (a retired Topaz cook) hoping to get it customized to make it exactly the way I want but I'm running into some issues.
Long story short, I'm using Ervius Visual Kitchen (1.8.2) and I noticed that the EXT packages I added end up leaving two copies of the files, a copy under \windows\ and another one in the places I specified using app.dat using:
Code:
Directory("\Program Files\bla\"):-File("bla.exe","\Windows\bla.exe")
Is there some way to get rid of the copy under \Windows\ ??
I know that I could simply leave everything there and discard the app.dat files but I would really prefer having everything organized properly (I have a bit of an OCD when it comes to organizing everything neatly ).
I'm pretty sure that this is a rather simple and noobish issue but I couldn't find anything relevant by searching and I took a look at some ext packages by various cooks and noticed the same behaviour.
Click to expand...
Click to collapse
No, it's call Read-Only-Memory (ROM) and is the reason you can hard-reset your phone. Every file you cook into the ROM is in \windows. Two ways I know of to reduce the amount of files would be to zip them and have a mortscript unzip them to the proper location during customization or cook in a cab containing all of the files and have it run during customization.

That makes a lot of sense, I really feel ashamed that I didn't figure it out earlier
EXT packages seemed easier than bothering to read about customization but I guess it's time to start reading about this kind of stuff.
Thread marked as solved.
Thanks for the quick reply!

Yup, files in rom are in rom forever, or until you flash again, lol. The trick is to just run bla.exe from \windows. I would say that 90% of the time, bla.exe runs just fine out of the windows directory (especially if it's the only file in the package). When people create cabs, they naturally install the app in \program files, but in general apps don't need to be in a specific folder. If there are other files present, usually an .exe will search within its own folder for those files. So, if you just cook everything straight into windows, you'll be good to go. It's easy enough to test: just move all the files from program files to windows after installing a cab, fix the shortcut in the start menu, and then try to run the app. It's always a good idea to do a soft reset and try again (found this out the hard way many times). The one thing you have to watch out for is settings files, like .dat files. These files frequently have to be archived (not read-only). Particularly with apps that use net 3.5, if there's a setting file that is read-only, the app won't boot and you'll get an error message. The fix is to name the file settings-1.txt (or whatever) and have an app.dat rename it to settings.txt (and keep it in \windows).
Also, remember to fix the shortcut path in the start menu, and examine the registry entries to see if there are any paths for files present-you may need to change them to point to \windows (this could also be true in settings files).

mwalt2 said:
No, it's call Read-Only-Memory (ROM) and is the reason you can hard-reset your phone. Every file you cook into the ROM is in \windows. Two ways I know of to reduce the amount of files would be to zip them and have a mortscript unzip them to the proper location during customization or cook in a cab containing all of the files and have it run during customization.
Click to expand...
Click to collapse
This actually made me think a little bit. When you think about read only, I always thing can't delete or overwrite. Obviously I can run a cab and replace a file that is located in the \Windows directory, that leads me to believe there is a way to delete a file or maybe even replaced with an empty file of the same name.

You can over-write a rom file, but the rom file is still there. The file system just flags it somehow or another and tells the device to ignore it and instead use the new file.

TMartin03 said:
This actually made me think a little bit. When you think about read only, I always thing can't delete or overwrite. Obviously I can run a cab and replace a file that is located in the \Windows directory, that leads me to believe there is a way to delete a file or maybe even replaced with an empty file of the same name.
Click to expand...
Click to collapse
The new file you copy over goes into the "user" partition of the file system and windows knows to use that file instead. Once you delete this newly copied file from \windows, the old one from the ROM will take its place back in the filesystem.

Farmer Ted said:
Yup, files in rom are in rom forever, or until you flash again, lol. The trick is to just run bla.exe from \windows. I would say that 90% of the time, bla.exe runs just fine out of the windows directory (especially if it's the only file in the package). When people create cabs, they naturally install the app in \program files, but in general apps don't need to be in a specific folder. If there are other files present, usually an .exe will search within its own folder for those files. So, if you just cook everything straight into windows, you'll be good to go. It's easy enough to test: just move all the files from program files to windows after installing a cab, fix the shortcut in the start menu, and then try to run the app. It's always a good idea to do a soft reset and try again (found this out the hard way many times). The one thing you have to watch out for is settings files, like .dat files. These files frequently have to be archived (not read-only). Particularly with apps that use net 3.5, if there's a setting file that is read-only, the app won't boot and you'll get an error message. The fix is to name the file settings-1.txt (or whatever) and have an app.dat rename it to settings.txt (and keep it in \windows).
Also, remember to fix the shortcut path in the start menu, and examine the registry entries to see if there are any paths for files present-you may need to change them to point to \windows (this could also be true in settings files).
Click to expand...
Click to collapse
First of all, a small question about the underlined part, just to make sure that I got it right: it won't be exactly a rename just a copy with a different name, correct?
Some of the apps I use need a specific directory structure for the resources and files they use, so just dumping them in one big folder won't work.
Another possible issue that I think I'll run into is having two files sharing a generic name (let's say settings.xml) while each belongs to a different app. I didn't personally encounter such a situation just yet but my packages are still a work in progress and I did see a post or two about this while searching.
I was still hoping there would be a simple way to arrange the files in folders while keeping them under \windows\ but I can't find such a method either. Doesn't seem like I have other options than to decided on a firstboot customization method: Runcc, autorun, xda_uc or something that I haven't read about yet...
"Runcc" is currently used in the base kitchen so that gives it an edge right now.
Edit:
Remembered that I had another question, and it's probably not worth a new thread.
I was looking at how to manually create .lnk files and I noticed something that I didn't understand and couldn't find info about.
For example:
Code:
21#"\Windows\MSDict.htm"
What exactly does the "21" refer to?? I tried changing it randomly to other values a couple of times and it didn't effect anything.

NRGZ28 said:
The new file you copy over goes into the "user" partition of the file system and windows knows to use that file instead. Once you delete this newly copied file from \windows, the old one from the ROM will take its place back in the filesystem.
Click to expand...
Click to collapse
Ok now that makes a lot of sense. I guess I'm just use to Android and being able to see that separate partition. Thanks for the explanation.
That sort of leaves me to another question. Can't someone develop a way to overwrite directly to the "system" partition? It would almost be like a root/superuser for WinMo.
Sent from my HTC Evo 4G!

MusikMonk said:
First of all, a small question about the underlined part, just to make sure that I got it right: it won't be exactly a rename just a copy with a different name, correct?
Click to expand...
Click to collapse
Yup, that's correct. Another approach is to take all similar files that go into windows and stick them in a zip file that unzips to the windows directory. I do that in a few cases (power radio comes to mind; it has an ini file). What I do in most cases though is use a backup/restore mortscript. The backup copies all settings files (and similar things) on my device to my sd card. During customization, the restore copies them back. It's convenient for apps where I change the settings a lot and I don't want to have to constantly fuss with the packages.
Some of the apps I use need a specific directory structure for the resources and files they use, so just dumping them in one big folder won't work.
Click to expand...
Click to collapse
What you do in that case is move the sub-folders into windows. In this case, I'll use a zip file to unzip those folders into windows. Using app.dat files to copy large numbers of files blows. It increases the rom file count as well as the storage used. A zip file is a single file, and usually it saves space.
Another possible issue that I think I'll run into is having two files sharing a generic name (let's say settings.xml) while each belongs to a different app. I didn't personally encounter such a situation just yet but my packages are still a work in progress and I did see a post or two about this while searching.
Click to expand...
Click to collapse
In that case, you're screwed unless there's a registry key that lets you change the name. I've run into a few complications; tcpmp and OMarket both use a common.dll. My solution was to buy Core Player, lol.
I was still hoping there would be a simple way to arrange the files in folders while keeping them under \windows\ but I can't find such a method either. Doesn't seem like I have other options than to decided on a firstboot customization method: Runcc, autorun, xda_uc or something that I haven't read about yet...
"Runcc" is currently used in the base kitchen so that gives it an edge right now.
Click to expand...
Click to collapse
Using cabs or zip files is the way to go if you want to copy large folders in one shot (with a mortscript; you can also un-rar rar files, but I don't know how. Yet, lol). Zips are easier to make and edit than cabs, but you need to have mortscript cooked in and know how to write the simple script (aka cut-and-paste).
Edit:
Remembered that I had another question, and it's probably not worth a new thread.
I was looking at how to manually create .lnk files and I noticed something that I didn't understand and couldn't find info about.
For example:
Code:
21#"\Windows\MSDict.htm"
What exactly does the "21" refer to?? I tried changing it randomly to other values a couple of times and it didn't effect anything.
Click to expand...
Click to collapse
The 21 is the number of bytes after the #. It doesn't matter. I usually just change the first number to 1. It works fine. Counting bytes blows.

That was extremely helpful. Too bad these boards don't use a rep system
Farmer Ted said:
Yup, that's correct. Another approach is to take all similar files that go into windows and stick them in a zip file that unzips to the windows directory.
Click to expand...
Click to collapse
Well, if I'm going to follow this method, and it seems like I am, I don't see why I would still have to limit myself to the \windows folder. I can just put everything the way I originally wanted to do. I only looked at arranging files under \windows when I found out that there's no way to get rid of the duplicates.
Farmer Ted said:
Using cabs or zip files is the way to go if you want to copy large folders in one shot (with a mortscript; you can also un-rar rar files, but I don't know how. Yet, lol). Zips are easier to make and edit than cabs, but you need to have mortscript cooked in and know how to write the simple script (aka cut-and-paste).
Click to expand...
Click to collapse
I haven't tried writing mortscripts yet but I've seen enough to figure out the basic and notice how easy it is. I'm gonna check how usable is the WM version of 7zip, as long as it accepts arguments combining it with mortscript will be easy and perfect for me.
7z archives can get smaller in size than half of the zip archives for the same files. And cabs are too annoying to work with and keep updated later on.
Only issue remaining now is checking whether I should put the archived files under \windows or use the sdcard for customization. I'm leaning toward the first but I'll have to wait and see how much memory I would be sacrificing that way.
Farmer Ted said:
The 21 is the number of bytes after the #. It doesn't matter. I usually just change the first number to 1. It works fine. Counting bytes blows.
Click to expand...
Click to collapse
Ah! I thought about counting bytes/characters and noticed that it works sometimes. But I thought it was a coincidence after I experimented in changing the value and noticed that it wasn't always the right count in the .lnk files that I found.
[rant]
Nice, I was messing around with some packages to free up ram and storage and I seem to have ended up with a rather b0rked up xTask. And then there's still convincing Resco Explorer that the registry add-in IS in fact there.
Figuring out the causes should keep me happily busy for a while (and probably heavily pissed for another while afterwards).
[/rant]
Edit:
Just for the record, I ended up using xda_uc it's a lot easier than doing things manually. Although it would help if there was some kind of documentation available, took me a while to understand what .xda, xdai, xdas & .xdaz files are supposed to be.

hi by the way is it possible to convert ext packages of QVGA phones to one another?

[Solved] how to speedup the first boot?

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.