ATT ships at least some of their Windows Mobile phones with a pre-populated contact list to a bunch of their services.
It is probably pim.vol which is not in the pda.bin, but is found in the root of the storage system after startup.
The goal is to have a blank contact list after hard reset or burning.
Is this something that can be accomplished in one of the control files during cooking or is it possibly a case of overwriting a default pim.vol that is copied from the extended rom during hard reset? The data does not appear to be in any of the *.rgu, *.xml, initflashfiles.dat, *.provxml files.
This is the last trace of ATT customisation in the current custom rom and it would be nice to get rid of it.
AT&T stores them in the file default_contacts.xml
I don't remember which OEM folder it is in, but you should be able to find it. I just create a blank file with the same name and store it in my personal EXT folder. That way it overwrite the AT&T file.
Thanks for your quick reply.
There is no file named default_contacts.xml in the dump here.
The dump is of the pda.bin only because that is all that is available for that version in vanilla factory form.
When you say "OEM folder" is that in some other area of the rom?
Are you cooking a ROM or what exactly are you trying to do?
In the kitchen, the file is in the OEM\<Device Name>\OEM\409\OperatorPkg folder.
If you can't see the file in your kitchen, make sure you have your file explorer set to show all hidden files as well.
I can assure you that the file is there in my kitchen and I just dumped it from the new Tlit2 ROM. Was also there in the original stock ROM for the Tilt2
I'm cooking a pda.bin which is loaded using USDL Grandprix.
The source is a dump from a Samsung Epix device, not the update file.
This is because it is an Omnia kitchen which does not seem to know everything about the file structure, but is able to cope with the pda.bin in both directions when supplied with an OS.NB from a rom dump.
Exploder is showing all files with hidden and system attributes. attrib.exe was also used to double check for the existence of the file in the entire tree.
There is no OEM directory.
If the OEM directory actually represents another partition on the flash, then which one?
All WinMo devices are similar. Find where all the pplication packages are (EXT) and there shoud be one with all the AT&T customization.
DJGonzo said:
All WinMo devices are similar. Find where all the pplication packages are (EXT) and there shoud be one with all the AT&T customization.
Click to expand...
Click to collapse
Well of course they are. They all start with the same code base from Microsoft.
The point of the question is to find out whether the files are in a partiition that the software has not managed to dump.
Post your stock rom and/or dump please.
plumsauce said:
Well of course they are. They all start with the same code base from Microsoft.
The point of the question is to find out whether the files are in a partiition that the software has not managed to dump.
Click to expand...
Click to collapse
Post a dump then buddy.
What you should do is just look in the \windows folder (you can flash the rom, right?) and then just copy out all of the provxml's and xml's. Look through them, and you'll probably find the one that's buggering up pim.vol. My guess is that it will have a name suggestive of its purpose.
If you have mortscript, then you can just do it automatically with this script:
Code:
XCopy("\Windows\*.provxml","\Temp\",TRUE,TRUE)
XCopy("\Windows\*.xml","\Temp\",TRUE,TRUE)
They'll end up in the temp folder; you can copy them to a pc and then open all of them up and search for the contact names.
Farmer Ted said:
What you should do is just look in the \windows folder (you can flash the rom, right?) and then just copy out all of the provxml's and xml's. Look through them, and you'll probably find the one that's buggering up pim.vol. My guess is that it will have a name suggestive of its purpose.
If you have mortscript, then you can just do it automatically with this script:
Code:
XCopy("\Windows\*.provxml","\Temp\",TRUE,TRUE)
XCopy("\Windows\*.xml","\Temp\",TRUE,TRUE)
They'll end up in the temp folder; you can copy them to a pc and then open all of them up and search for the contact names.
Click to expand...
Click to collapse
Yes, flashed it 20+ times yesterday while debugging
The latest is that there are a couple of mxip*.xml files that appear in the root of the pda storage area. The content has not been looked at yet because it was discovered at the end of the session. But, one of them is mxip_initdb.xml. As you said, "highly suggestive". These files are not part of the dump. So, they must be getting copied or written by a process instead of being static.
update
actually, they are in the dump, just not *.xml, they are *.vol.
binary format, so I guess I'll have to troll around in there using a hex editor.
/update
The device already has a tricky piece of code. It runs a process on cold restarts that rewrites imei* files. The trick is to disable the process. Then, modified imei* files will work properly without being overwritten.
There are also some registry entries that cannot be touched on a flash/restart because there are insufficent permissions at the time. Entries that are known to work after reg unlocking will fail to work at that stage. Touching any one of the restricted entries with a mxip* file will fail everything in the whole file.
DJGonzo said:
Post a dump then buddy.
Click to expand...
Click to collapse
And what would you look for in the dump?
plumsauce said:
And what would you look for in the dump?
Click to expand...
Click to collapse
The stuff you've missed.
indagroove said:
The stuff you've missed.
Click to expand...
Click to collapse
wouldn't it be more productive to at least describe what area to look in?
plumsauce said:
wouldn't it be more productive to at least describe what area to look in?
Click to expand...
Click to collapse
You are saying that your stock device rom is different than most. Other chefs have already described what to look for. You have been offered help to look through the rom and the dump, but you seem to be declining the offers, so never mind.
indagroove said:
You are saying that your stock device rom is different than most. Other chefs have already described what to look for. You have been offered help to look through the rom and the dump, but you seem to be declining the offers, so never mind.
Click to expand...
Click to collapse
I have said that there are differences between devices. That would hardly be surprising. When someone says look for file "x" and it is not there, that would be a difference. It is then fair game to ask if whether it might be stored in one of the other partitions which has not been dumped.
If someone has said that they have checked from the root of the dump and double checked using a second tool, then that assertion is likely valid.
If you have no specific file or files to look for, then so be it.
Related
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
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 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?
Sorry for being dumb once again.
I know how to create an XML and convert reg files to PROVXML etc but :
I flashed my cooked rom and did snapshot with kheb made all my changes and got a difference .reg file.
I converted that to PROVXML cause i believe its the best way of doing it.
What I dont know is what to do with it and where to put it in order to flash it.
Ive put it under custom settings\files but iot needs to be named something specifically according to 0Kitchen . Also i have an xml file that has my exchange settings in that which i want to cook in as well but dont know how.
I do use XDA uc but id prefer to let it be done with runcc or something?
Please advise whats better and whats the difference between the differentx PROVXML file naming.
Thanx
I would preffer using reg instead Provxml because they take a lot of time for 1st boot....anyway you need to name them mxip_xxxx.provxml if im not wrong.
af974 said:
I would preffer using reg instead Provxml because they take a lot of time for 1st boot....anyway you need to name them mxip_xxxx.provxml if im not wrong.
Click to expand...
Click to collapse
Can i renam the exchange.xml to mxip_exchange.provxml as well. does a xml and provxml contain the same information/layout?
Uhmm...it seems that should work, give a look here http://ip208-100-42-21.static.xda-developers.com/showthread.php?p=6995989.
Grumps said:
Can i renam the exchange.xml to mxip_exchange.provxml as well. does a xml and provxml contain the same information/layout?
Click to expand...
Click to collapse
af974 said:
Uhmm...it seems that should work, give a look here http://ip208-100-42-21.static.xda-developers.com/showthread.php?p=6995989.
Click to expand...
Click to collapse
Leme just try quickly we do flash like 30 times a day in any case hey. Will revdert just now
Thanx for your help
There's various file names, mxip, mxipinit and mxipupdate. In my experience I've never needed to add anything to a .dsm file, as long as the extension is .provxml they execute ok.
What I do though, is put my post-boot provxml's into the very last folder that my kitchen picks up so it's named ZZZ_postboot_provxml or something similar and I also name the file to mxipupdate_zzzPostBoot.provxml but I'm not sure if this helps. I do this because:
If you use total commander and search for *.provxml files in your windows folder you might find that none of them have the original name you gave in your packages, but if you step through the files you find there, you can see the execution order.
Hope this helps a bit.
arealityfarbetween said:
There's various file names, mxip, mxipinit and mxipupdate. In my experience I've never needed to add anything to a .dsm file, as long as the extension is .provxml they execute ok.
What I do though, is put my post-boot provxml's into the very last folder that my kitchen picks up so it's named ZZZ_postboot_provxml or something similar and I also name the file to mxipupdate_zzzPostBoot.provxml but I'm not sure if this helps. I do this because:
If you use total commander and search for *.provxml files in your windows folder you might find that none of them have the original name you gave in your packages, but if you step through the files you find there, you can see the execution order.
Hope this helps a bit.
Click to expand...
Click to collapse
ok so postboot is also one of the names like mxipinit and mxipupdate. Why are there so many different ones and which ones are executed in what order?
Grumps said:
ok so postboot is also one of the names like mxipinit and mxipupdate. Why are there so many different ones and which ones are executed in what order?
Click to expand...
Click to collapse
I think the order is all to do with the way the kitchen picks them up. e.g. I use OSKitchen and it seems SYS, then OEM, then EXT packages are picked up, alphabetically-so my provxml's get the same order, which is why I put them in a package of their own with the ZZZ_postboot name. It just makes it the last one to be picked up of the EXT packages-ensuring everything is in place when the script runs
arealityfarbetween said:
I think the order is all to do with the way the kitchen picks them up. e.g. I use OSKitchen and it seems SYS, then OEM, then EXT packages are picked up, alphabetically-so my provxml's get the same order, which is why I put them in a package of their own with the ZZZ_postboot name. It just makes it the last one to be picked up of the EXT packages-ensuring everything is in place when the script runs
Click to expand...
Click to collapse
Ok lemme try
Im trying to change my timezone from dublin -8 to gmt +2. n start kheb take snapshot make the change get i difference .reg file. convert it to xml and the paste it in files folder of lastflash folder?? ill try and see what happens
Hi,
I'm using the latest osKitchen (v1.33.5) to build my own ROM for the HTC Kovsky (SE Xperia X1). Followed the tutorial, imported the latest official R3A WWE build, added a WM 21916 build and started cooking. But there's no first boot customization after a flash/hard reset. There are no errors, executing AutoRun.exe from the Windows folder doesn't seem to work either.
The config.txt (used by AutoRun and RunCC) files are left stock, but editing them doesn't make a difference. How can I fix this? If you need more information, just ask. I'll reply asap.
Have you added the runcc.lua file and redirected it to the right config.txt?
If so, flash the ROM and look whether those files are in \Windows\ (and just not executed) or not present.
Flashed the ROM: runcc.lua was already added and it redirects to the right config.txt. Paths are correct.
...
this happened to me not so long ago:
check that the autorun.exe and config**.txt files do not get overwrote during rom creation.
check that there are no duplicate files with those file names..
good luck!
Rn
I don't think those files are being overwritten during ROM creation. How can I check this? Can't find the Autorun.exe in the kitchen but after building and flashing it is visible in the Windows folder on the device. There are no duplicate files, triple checked that.
Tried building a new kitchen from scratch, an untouched build (only importing the stock ROM and the 21916 build) didn't have a first boot customization either.
I remember figuring this out on my X1 a year ago was a pain in the a*s. Can't recall where the problem was anyway. I could upload my OEM Packages for you if you'd like to? I'm using a older version of that kitchen anyway so this "could" lead to new problems...
That would be great! Please let me know what kitchen version you used, if there are any problems I can try to roll back to that one.
I PM'd you. Most persons would not know what to do with said files so it makes no sense posting them here I guess...
...
hey dude,
not sure what your problem is if all your config**.txt are there and there is no duplicate files, for me i had a mortscript called "autorun.exe" which obviously overwrote my original autorun.exe and caused my device to do no customisation.
erm, as for not finding your autorun.exe
lots of files in the kitchen are hidden and the windows hidden files toggle does not show all the hidden files for some reason :/
me personally i use ACDSee photo manager 9 to view the files in my kitchen, i then select all the files and untick the 'hidden' properties.
ALL the files you couldnt see in windows explorer are always visable using Acdsee, by unticking the properties with Acdsee, it now makes them visable in windows explorer.
hope you understand what i meen :s
btw, i only use acdsee9 to view my pictures and to change the properties of the files.
i edit all my images with photoshop and paint.
Rn
derliebewolf said:
Most persons would not know what to do with said files so it makes no sense posting them here I guess...
Click to expand...
Click to collapse
According to my searching results this issue seems to be very rare. Posting the download link here shouldn't harm others.
For osKitchen version number you mentioned in your PM, open the kitchen and use Help -> About. Don't know if this option was present in earlier builds, but at least in 1.33.5 it is.
raving_nanza said:
erm, as for not finding your autorun.exe
lots of files in the kitchen are hidden and the windows hidden files toggle does not show all the hidden files for some reason :/
Click to expand...
Click to collapse
I wasn't at the stage of using Mortscript in my ROMs yet. Untoggle hidden system files in Windows folder options did the trick, I found AutoRun.exe
Now I'm gonna sit and wait until the download is available...
DillonDarko said:
I wasn't at the stage of using Mortscript in my ROMs yet.
Click to expand...
Click to collapse
let me know when you are at that stage dude, ive got a small collection of usefull scripts that might prove themselves usefull.
DillonDarko said:
Untoggle hidden system files in Windows folder options did the trick, I found AutoRun.exe
Click to expand...
Click to collapse
cool man, but remember:
the windows hidden files toggle does not show all the hidden files.
Acdsee will show them all so none are hidden, trust me
Rn
NVM....thought of a some other problem...
raving_nanza said:
let me know when you are at that stage dude, ive got a small collection of usefull scripts that might prove themselves usefull.
Click to expand...
Click to collapse
Will do.
For the others that might experience this problem, the download link for EXT and OEM packages available here. These packages are untested, but I'm cooking them now. Thanks for the help. Scroll down for the fix.
So I think it's working now?
@All: please be aware, those packages are device-specific and for HTC Kovsky / SE Xperia X1!
Ok, tried replacing the existing packages with those from derliebewolf. Even when left untouched or using different (correct) commands there's still no customization. @derliebewolf, could you upload your "osKitchen.exe" and "Resources" directory for me? It's all I need, I can fill the kitchen from scratch there.
If this turns out to be a kitchen specific problem I won't hesitate posting it in the official osKitchen thread.
This is a pretty complicated problem to give advise.
Just a suggestion, didn't you modified/removed something from your initflashfiles.dat?
I mean the startup.
Compair it with a stock rom if you did and check if something is missing.
On my HD2:
Directory("\Windows\StartUp"):-File("ConfigureDevice.lnk","\Windows\ConfigureDevice.lnk")
Directory("\Windows\StartUp"):-File("bugtrap.lnk","\Windows\bugtrap.lnk")
Directory("\Windows\StartUp"):-File("HTCStartUp.lnk","\Windows\HTCStartUp.lnk")
Directory("\Windows\StartUp"):-File("PKG.lnk","\Windows\PKG.lnk")
Directory("\Windows\StartUp"):-File("SignatureReplace.lnk","\Windows\SignatureReplace.lnk")
Directory("\Windows\StartUp"):-File("Welcome.lnk","\Windows\welcome.lnk")
Click to expand...
Click to collapse
You tried everything possible so I taught maybe this could be possible.
On Xperia it's probably about the same.
DillonDarko said:
Ok, tried replacing the existing packages with those from derliebewolf. Even when left untouched or using different (correct) commands there's still no customization. @derliebewolf, could you upload your "osKitchen.exe" and "Resources" directory for me? It's all I need, I can fill the kitchen from scratch there.
If this turns out to be a kitchen specific problem I won't hesitate posting it in the official osKitchen thread.
Click to expand...
Click to collapse
You really need to leave the welcome.lnk line in there, or else you won't get the alignment screen and you can't boot the device up.
Found the issue: an incomplete initflashfiles.dat. By adding the lines below to a stock initflashfiles.dat the whole issue has been fixed.
Code:
Directory("\Windows\StartUp"):-File("CheckAutoRun.lnk","\Windows\CheckAutoRun.lnk")
Directory("\Windows\StartUp"):-File("AutoShortcut.lnk","\Windows\AutoShortcut.lnk")
Turned out a stock initflashfiles.dat file doesn't have those lines included by default. Thanks to all for the help, expect a new custom Xperia X1 ROM soon.
That's nice to hear, congrats.
Please at [SOLVED] to the topic title and I will link this thread to the solved cases sticky.
DillonDarko said:
Found the issue: an incomplete initflashfiles.dat. By adding the lines below to a stock initflashfiles.dat the whole issue has been fixed.
Code:
Directory("\Windows\StartUp"):-File("CheckAutoRun.lnk","\Windows\CheckAutoRun.lnk")
Directory("\Windows\StartUp"):-File("AutoShortcut.lnk","\Windows\AutoShortcut.lnk")
Turned out a stock initflashfiles.dat file doesn't have those lines included by default. Thanks to all for the help, expect a new custom Xperia X1 ROM soon.
Click to expand...
Click to collapse
DillonDarko said:
Found the issue: an incomplete initflashfiles.dat. By adding the lines below to a stock initflashfiles.dat the whole issue has been fixed.
Turned out a stock initflashfiles.dat file doesn't have those lines included by default. Thanks to all for the help, expect a new custom Xperia X1 ROM soon.
Click to expand...
Click to collapse
Which makes me woder whether those lines are missing in my initflashfiles.dat as well? RunCC is working perfectly anyway... Glad you solved it!