Related
Hi All
I hope someone can help with the following problem.
I had wanted to use Mkrom on 2003 roms but after encountering problems with rom addresses and on KP2L's advice I switched to the "Rom Kitchen" as the code has been updated to handle 2002 and 2003.
I did not want to run the whole thing as I don't know much about Web servers on Unix so I just downloaded the 2003 directory and added back the missing folders and tools. After converting the files I am able to run ./mkrom.sh and make a "raw" .nb1 image that loads O.K to my XDA
The problem starts when I try to add files.
Trying a simple example of just placing ssnap.exe in the files folder and not bothering with links/ subfolders etc ./mkrom seems to work in as much that it picks up the files>transfers them to files 1/ 2 adds the files from cfg and > to the XDA1/2 .bin together with xip and loads to the rom under XDA_Developers 1/2. When this Rom is installed the XDA freezes at the bootsplash screen (Not completely, if you press the volume button it comes up to the start screen but the screen is miles out of calibration and most of the menus are missing) To test this further I downloaded a rom from Jeffs kitchen and stripped the files for the cfg/files folder and re-ran ./mkrom.sh but I get the same problem .
I have run lots of UltraEdit "Compare" reports,of all of the cfg/dumprom output files, between mine and Jeffs, and apart from some addressing differences all the data is getting to the rom. (I can post the reports if anyone wants them)
I suspect, although I'm useualy wrong, it's data "type"/ conversion conflict and wonder if under a full Rom Kitchen the files are converted in some way before being placed in the files folder prior to ./mkrom processing ?
As a last resort, I guess, I will have to set up the Web server (I have got one just never used it) and do the whole thing but hope to avoid it with a bit of help.
PLEASE :?: :?: :?:
Thanks
Richard
O.K I guess the question was too long/boring lets try this:
Do the scripts in Rom Kitchen make any changes to the files to be added to rom prior to processing by ./mkrom.sh
Richard
Richjn said:
Do the scripts in Rom Kitchen make any changes to the files to be added to rom prior to processing by ./mkrom.sh
Click to expand...
Click to collapse
No: the script basically just sticks the files into /files and then runs mkrom.sh
Not sure why your scenario isn't working, it sounds like it should...
Hello,
I am trying to copy a file (from my smartphone to SD card), which have a 'ROM' attribute set and... it is impossible - acces denied is showed (even in Resco Explorer, Total Commander). I can't even change that attribute.
Please help me to find any solution
Best greetings,
RA
You should be able to extract files from the ROM file on your PC thanks to the tools provided in one of the sticky about ROMs modifications.
Unfortunatelly...
Cricri said:
You should be able to extract files from the ROM file on your PC thanks to the tools provided in one of the sticky about ROMs modifications.
Click to expand...
Click to collapse
I have extracted an 'nb' file from my ROM file, but WinImage can't open it ("not FAT16, FAT32 file"). It is WM6 image file, what tools to open this 'nb' file?
Best greetings,
RA
I, too, am trying to find a way to copy some ROM attributed files.
Ultimately, I am trying to move/copy some apps from one smartphone (WM5) to another (WM6). Is there a way to copy them to a zip file and move the files that way or maybe even using a backup copy (i.e. using Sprite Backup?) and restoring to a different phone?
Any help or direction would be appreciated. If there is another thread out there, please be sure to point me to it since searching brings up a lot of different threads.
u need to extract the rom.
Funny, but you make it sound so easy... ;-) I've been searching to figure out how to do that and found some instructions I'm hoping I can follow for the one phone, but not sure it it will apply to the old phone (WM5). If I do manage to dump the ROM, where does it go and does it extract the files in cab format for easy upload?
Update: I found a file extractor at http://pdaphonehome.com/forums/ppc-6700-xv6700/56057-6700-rom-dump.html which may have originally come from Buzz... (thanks Buzz!)? so now I have all the files and modules off the old phone, but am running into some issues installing. I can transfer the files indirectly, and can find the specific application file, but when trying to run the app, it tells me that it's still missing files to enable the program. Any ideas on how to determine which files they might be or how to install the files via Activesync?
Hi guys,
Recently i have noticed tha my t9 words are not working
I found this on xda
Directory("\Windows"):-Directory("ET9IMEDB")
Directory("\Windows\ET9IMEDB"):-File("eT9AsDb.Adb","\Windows\eT9AsDb.Adb")
Directory("\Windows\ET9IMEDB"):-File("eT9Rudb.Rdb","\Windows\eT9Rudb.Rdb")
but when i added it to initflashfiles.txt, all the files look like on the screenshoot
when i simply change a name of \Windows\ET9IMEDB to \Windows\ET9IMEDB_t, and change it back again to ET9IMEDB, files are normal, but after soft reset its the same story
so i did a mort script
Rename ("\Windows\ET9IMEDB\", "\Windows\ET9_temp\")
Rename ("\Windows\ET9_temp\", "\Windows\ET9IMEDB\")
and added it to StartUP folder, it works, but i want to know what is causing it
thanks for help in advance
Billy
ps. I am using leo3.02 IME packages on Topaz Rom
Wow, I'm glad I clicked this. I've run into the same crap many times. My temp fix is the same as yours. I don't use et9, but this has happened to me w/ several apps that I've relocated to windows, like ucweb. My only fix is to get corruptable files/folders oit of windows.
yeah, but you can't get this folder out of windows, cause it must be located there
Have you looked in the .reg file in the package? There may be a key in there that sets the path.
The files would get corrupted every time I would soft reset.
I'll add that for me, I've run into several apps that would give me corrupted files. Usually, it was apps that I'd relocated from \program files into \windows (to save storage space). For instance, Bing would do this to me. The rom files were fine, but the sub-folders would become corrupted after every soft reset if they were in the \windows folder. In particular, the XAML folder would go wonky. The fix was to rename it, then name it back. I'm sure you figured this out the same way I did: you couldn't delete the corrupted files/folders, or copy them, or anything, unless you first renamed them (lucky that worked). When I'd rename the folders, I'd notice that the files inside were no longer wonky. I made an EXT for FpseCE that was relocated to \windows, and all six sub-folders would become corrupted after a soft reset. It was a royal pain to rename them, so that was basically when I decided it wasn't worth the saved storage space to have the apps located in rom, so I moved FpseCE, Bing, and UCWEB (the CDDATA folder would go bad) to program files. The other app that would mess up on me was Weather2go (a today plugin). The Weather.dat file (located in \windows) would go bad for maybe the first 4 or 5 soft resets after a flash, but then it would mysteriously become stable. It was annoying as crap, because the plugin would go blank and not show the weather forecast after a reset. I don't know why, but now it works fine. Perhaps it's because I took the other 3 apps or so out of \windows. The really weird file that would screw up on me was an ID txt file for SK Today Commander. SK software puts an ID text file in windows for all it's paid-for apps. I have maybe 5 of their apps, and the files were fine for all of them except today commander. It would become corrupted at each reset. Now, it doesn't happen any more to me.
I wish I knew why it happens, but I don't. Now, if I'm making a package for a new app, I will test it before flashing, and do several soft resets to make sure that none of the files that might be created by the app are not corrupted after a soft reset. It's been a couple of months since I had the problem.
I looked at the xt9 package I have, and it looks like you can relocate the entire thing to another directory. It will be a pain in the butt, but if you really need it it might be worth a try. There's an installdir key that needs to be changed (from \windows), plus many keys for the path to all the dll's. I don't see a path for the databases, but they will probably move to the new location (assuming you change all the paths).
now i had finished all correctiong all errors for my rom (new packages from Oobe and Huashan) and new manila, i was using topaz ext before, but is it time to change it for a fresh apps
so i will have time to find solution for this, it may be to many files in rom, first i will try to remove some apps, my nhb file has 230mb, so it could cause problems in filesystem, we will see
I doubt it's that, but you never know. My rom is pretty light (only ~2500 files). I tried Task 29, and that didn't do jack squat. Moving things out of \windows was the only thing that worked. I guess maybe moving to osbuilder could help; maybe the module allocation in EVK is causing issues. I've never had S.O.D. before, but I have had this plenty. It's pretty clear that something hinky is going on during boot-up, though.
well i am using osKitchen v1.31beta10, so it's not EVK problem
OsKitchen and EVK are pretty much the same, though, aren't they? They both run platformrebuilder; I'm not sure if they handle modules the same way, but I suspect that they do. Osbuilder is supposed to do a better job of it, but the thought of converting all my packages over makes me want to hurl.
I figured out what is going on with this (sort of). I don't know why you get the corrupted files/directories in \windows, but I know how to avoid it. Files/folders become corrupted after a soft reset when their names are all capital letters. For instance, if I have a folder named \CDDATA in \Windows (or \XAML or \BIOS-those are from Bing or fpsece), then any file inside that folder will become corrupted after a soft reset (except for .lnk files, go figure). So, the key is to just rename the folder with lower case letters. In the case of UCWEB, which used the CDDATA folder, it works just as well with a folder named cddata, except that I can soft reset the device w/o issues. I'm assuming that Bing would work with an \xaml folder, and fpsece would work with all 6 of its sub-folders being named in lower case.
The same thing happens with files: if their name is all capital letters (inc. the extension), then they become corrupted after a soft reset. Renaming them fixes it (same with the folders). Anyway, this is why the OP's files go wonky in the \ET9IMEDB folder.
Like I said, I don't know why it happens. I get it with EVK roms and OSBuilder roms.
Farmer Ted good find, thanks
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.
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?