Related
Announcing: ROMkitchen
Special Edition ROMs are soooo yesterday.... We're proud to unveil our largest project yet: ROMkitchen. Now you too can modify your ROM to contain precisely what you need. Create your personal ROM, based on the ROM you like.
Wanna see: Have a look at our showroom kitchen to see what we mean. As you can see the showroom kitchen shows the PPC2002 based 3.17.03 ROM released by O2, as well as the 4.00.05 Microsoft WM2003 test ROM. Neither of these ROMs is really present though: you need to download the scripts, include your own ROM images, and run the scripts on your own unix machine. But once you do, you and your friends can create ROMs to your heart's content.
Why didn't we just include these files and make it all work? Because we're not licensed to distribute these ROMs, that's why.
So now what?
Play around to see if you like it.
download all the files visible when logging in using FTP to xda-developers.com username 'kitchen', password 'kitchen'.
Put them on your own unix machine, which should be capable of executing php scripts, and which should have a 'little' memory, disk and processing power left over. (We're afraid ROMkitchen wasn't built with resource-efficiency in mind.)
Add your own ROM files, see the readme files in the "data/00[...]/_/cfg" directories for details.
Notes:
If you set up your ROMkitchen, make sure you only use it for yourself, and with ROMs you legally own. We're not responsible for abuses.
If you use an ftp-client which can ignore files which are newer on your side, you can regularly check for updates and always have the newest kitchen.
ROMkitchen does not yet support outputting self-extracting binaries a-la Jeff's exe. We're working on that.
ROMkitchen currently supports English language ROMs only. We're working on this too.
The welcome exe is back in ROMs made with it: a little too much hassle to make our own. So you'll have to go through the silly tutorial every cold-boot.
XDAunlock is missing still. (It will be incorporated, but most people will be making 4.00.05 ROMs, and it doesn't work on that anyway...)
How does it work?
The ROMkitchen consists of a number of php scripts that present the form with all the options to choose from, and which copy files ready for our 'mkrom' utility to process. If you take a look you can see the raw structure of the data that is presented and inserted into the ROM. We'll find some time soon to explain, but you can already learn quite a bit if you look at the files and directories carefully.
xda-developers u are AWESOME
I'm going to try it as soon as i get home tonight. So all that is needed at first is a 2003 or 2002 image file?
thanks
alex
This looks awesome
Is it possible to run this program on Cygwin ? I have configuered the Cygwin download to include Bash and Perl but can't find a reference to dd. I confess that although I have a reasonable amount of programming experience I have never used Unix before so don't even know how to invoke the scripts so any help would be much appreciated.
Richard
just uploaded everything to my unix box and tried to run setup.sh from 4.00.05 directory. i also uploaded bootloader.nb0 and rom.nb1 files to the cfg directory. when i run ./setup.sh this is what i get:
[[email protected] _]# ./setup.sh
Usage: splitrom <romimage(s)> [options]
-wx xipchain where to write xipchain
-wo osrom where to write output image
-wb bitmap where to write bitmap
-wl bootloader where to write bootloader
-rl bootloader which bootloader to use for NBF
-n nbfinfotext what NBF header to use [ex: PW10A1-ENG-3.16-007]
-ri nbfinfofile or where to read NBF header info from
-wi nbfinfofile where to save NBF header info
-rx xipchain where to get xipchain from
-rb bitmap where to get bitmap from
-rm [email protected] insert new romsection.
-ob offset where to find the bootup image
-oe offset the end of the desired os image ( default: 0x81f00000 )
-t NBF | B000FF | NB? | IMG type of result image (default is NB1)
also when i tried to convert the default.fdf file to default.reg i get error saying "unknown fdf file signature" and it creates a 0 byte default.reg file.
any help is appreciated. i know i'm asking too many questions, but same happened with ur mkrom tools and once i got answers from u i was able to build roms without any problems.
thanks
alex
Hold on a tick, if you guys added one more feature it would go nova, however. Some features I would like to see is the ability to mix drinks, roll joints, cook dinner, and cure premature baldness/cancer.
It would also be nice if you could arrange for the program to be delivered to my house by the drunken, naked Chinese twins, Fok u and Fok me.
You guys are the bomb. Keep up the great work!
-
# Put them on your own unix machine, which should be capable of executing php scripts, ...
Click to expand...
Click to collapse
this implies that you should also have setup a webserver, for running the php scripts.
you will have to change the 'splitrom' commandline in setup.sh depending on what source file you have.
it is not a configure all automatically script, just a guide, to what sort of is supposed to happen for setup.
Holy Cow, you guys are amazing....
This is just a short message to say I'm fighting with it as we speak. My friend's box does have PHP, this is good. I've already found that it needs two subdirs under its root ('download' and 'workspace') to be world-writeable. Took me a while to figure that one out. Haven't got it running yet though, this ROM setup.sh thing is far less than intuitive. But I have the two ROMs which have all the other mumbo-jumbo done: 3.17.03 and 4.00.05, and I will get this to run, if it's the last thing I do.
Jeff (Just back from the U.S., up since 4 am, severe jetlag)
Jeff Summers said:
I've already found that it needs two subdirs under its root ('download' and 'workspace') to be world-writeable.
Click to expand...
Click to collapse
Whoops... I guess you're right, that should have been documented. The things you take for granted sometimes...
Thanks, and good luck...
Thanks
hey, you are doing a great job guys, keep it up.
welcome back Jeff Summers.
Othman
OK, here's the status:
I'm close, really close. It wouldn't detect my OS, the bash on the system I'm on is in /usr/local/bin instead of /bin and now it's complaining about a missing perl file. I'm working on it though...
probably you are missing http://search.cpan.org/author/GBARR/Scalar-List-Utils-1.11/
which is included with perl 5.8, but not with perl 5.6.*
if you don't have root access to you box, you can also install ( see the README for build instructions ) list-utils in your home directory, by editing the generated Makefile, and changing 'PREFIX=$(HOME)', and then adding
Code:
export PERL5LIB=$HOME/lib/perl5/site_perl/5.6.*
to your environment. ( with '*' your perl version )
It's working
It's working!!!
With a little help, I got it to work !!!
Have a look at http://cuba.calyx.nl/~jsummers/ROMkitchen
I just created my first ROM!
Hi, I tried create 4.00 based Rom on Jeff web and it works... thanks.
I discovered only small problem, that there are not installed links in Programs to extra included programs. But I can do it manually for now.
I tried to start my version of romkitchen on my notebook but I was stopped on integration PHP to IIS. I tried some last installer php-4.3.2-installer.exe for Windows but I got CGI error when I tried to access index.php. I'll work on it.
I hope that it will run too, like mkrom on Cygwin.
aleho said:
Hi, I tried create 4.00 based Rom on Jeff web and I works... thanks.
I discovered only small problem, that there are not installed links in Programs to extra included programs. But I can do it manually for now.
Click to expand...
Click to collapse
Ah, you haven't noticed that we put these in subfolders maybe. Go to Programs, and you should see subfolders. If you unchecked the option to put in these subfolders, then you have also unchecked everything 'below' that, meaning you haven't installed these programs.
I tried to start my version of romkitchen on my notebook but I was stopped on integration PHP to IIS. I tried some last installer php-4.3.2-installer.exe for Windows but I got CGI error when I tried to access index.php. I'll work on it.
I hope that I will run too, like mkrom on Cygwin.
Click to expand...
Click to collapse
Go for it...
Ah, you haven't noticed that we put these in subfolders maybe. Go to Programs, and you should see subfolders. If you unchecked the option to put in these subfolders, then you have also unchecked everything 'below' that, meaning you haven't installed these programs.
Click to expand...
Click to collapse
I had unchecked only few of programs to fit in ROM 4.00 free memory.
But folders in Programs like Phone, System tools,... were not in this case created, but they were checked.
jeff: great work...
one bug i found: when i disable the modify rom and add programs i get an error: Warning: Invalid argument supplied for foreach() in /home/jsummers/public_html/ROMkitchen/processor.php on line 480
i wanted to get the orig 4.00.05 rom without modifications
Jabba
REQUEST: zipped Kitchen
Hi !
Thanks all developers! Great work
One request though: please put a zipped version of your ROMKitchen at your ftp -> downloading hundreds of files is a mess *g*
Thanks... Jabba
This is so frustrating: I had it working perfectly, and now all of a sudden it stopped working. I'm working on it...
It's working now. Not really sure what was up, but it seems to have fixed itself.
Nice!!! These new ROMs are sooo cool. All the programs are stored in neat subfolders with icons....
I did find that D9 and PocketCHAT (The EVB apps) do not yet work on WM2003. It complains some EVB shared files are still missing.
Hi Jeff, just to say I've successfully used your ROM builder principally it has to be said to get hold of 4.00.05 so I only choose the Hot Fix item.
Checked in startup (which I've not looked in before) to see the hotfix and its there, there is also aFlashman, cFlashman Handsfree poutlook, SMSReciever, stk & Ussd. Are these part of the normal ROM? Just want to check that the thing is running as lean and clean as it can.
Many Thanks
Spent a lot of time on it, trying to figure out what went wrong with mkrom when cooking 4.00.xx roms. finally figured it, well, almostly. here is a short step by step tutorial for people who do not want to set up the complicated kitchen but wish to use mkrom as in the good old 3.17 time.
I assume you already know the rom flush process already, if given a NBF file. also you need a linux box with perl.
I know quite a few people struggled and have not had a clue. and I believe there is some bugs in the mkrom package that gives the trouble.
1. download the newest mkrom from http://xda-developers.com/~itsme/download/mkrom_136.zip. this is the only piece of software you would need.
2. unpack it to, say mkrom, directory. then make directories cfg
3. get hold of a copy of rom file and its corresponding paramter files. the parameter files can be obtained from the demo kitch download ftp://kitchen:[email protected]/data look inside the "00_base ROM" and the parameter files should be under cfg directory of each rom directory. bascially the parameter files tells mkrom, where to start to put added files and how large space there is. there are two blocks of space that can be used. so the file has format
wincever=4
start1=81740000
size1=00040000
start2=81b00000
size2=003c0000
startbmp=81ec0000
startop=81b00000
the first three lines are same for all 4.00.xx roms, start2 varies for different roms, startbmp is also the same for all roms. startop should be the same as start2. size2 will be startbmp-start2, remember they are all in hex. you can calculate how large space there is once you get hold of the start2 parameter.
anyway, put the parameter files under the mkrom/cfg directory, with name "params"
4. copy a rom file (.nbf), say rom.nbf, into mkrom directory and run "./setup rom.nbf". this will creates several files under cfg.
5. mkdir a directory mkrom/romfile, enter it and make another directory file , then type "../dumprom ../cfg/rom.nb1 -4 -d file"
here comes the first bug. the setup.sh tells you that dumprom can only be used in windows box. but in fact, there is a compiled dumprom for linux in the directory (you might need to set it to be executable though). however, this linux version does not put extracted files into the "file" directory as it is supposed to, instead it just write file as "file\xxx" where xxx is the actual file name extracted from rom. it is a bug but as long as we know it, not a big deal. the is someone posted a correct version of dumprom in this forum though.
6. you should be able to find three files (or with the "file\" prefix added) with name default.fdf initobj.dat initdb.ini. these are the three files that needs to be process as indicated by setup.sh. follow the instruction to create the default.reg initobj.txt initdb.ini and copy them to cfg directory.
7. make a directory mkdir/files. you are ready to create a clean rom now by running "./mkrom output.nbf", the created output.nbf should be fine.
So far so good, followed the instruction of mkrom. next would need to add our files. then comes the problem. if you add files into the mkrom/files directory, and run "./mkrom output.nbf" again, it is almost definitely that the created rom is bad. I am not 100% sure why, but here is what I believe:
the mkrom script scan files in the "files" directory and put files in there into the "files1", "files2" directory, each of them is supposed to fill the two space in rom starting from "start1" and "start2" in parameter file. the size of files under "file1" should be less than "size1", similar "files2" and 'size2". when mkrom does this, it is highly possible that the three critial files "default.fdf, initobj.dat, initdb.ini" are placed into "files2" directory instead of "files1" directory and renders the rom bad.
here is what I did
edit the mkrom.sh, delete the line that splits files in "files" into "files1, files2" directory. change the three lines that convert the three critial files so that these three files are created in "files1" directory instead of "files" directory. then put your files into "files1" and "files2". just be careful, keep the size less than specified by "size1" and "size2".
then you can run "./mkrom.sh output.nbf" as before, and the resulted rom will be good.
hope this helps. however still a couple of problems
1. the fdf2reg.pl won't recoganize the default.fdf extracted from 4.00.21 rom or 4.01.00 rom
2. if i change the content of initobj.txt, the created rom won't boot. I might have done something wrong in initobj.txt though. but I used to be able to do this for 3.17 rom
3. I did not try to modify registry, as my only purpose is to put my files into ROM to save space. all registry can be done later by installing the software and choose not to overwrite existing files in ROM. must simpler.
the unix version of dumprom does not decompress files, that is why your default.fdf etc seem corrupted.
this is because I only have the decompression code in the form of a binary library, which I have not figured out how to link to under linux.
the only use of dumprom under unix is to find the offsets in rom where filepointers to default.fdf etc should be patched.
I should maybe disable the '-f' option in dumprom for the unix version, to make things less confusing.
but it looks to me that the dumprom under linux worked for pre- 4.00.16 rom. only not for after 4.00.21 roms. so are they different?
maybe the default.fdf was not compressed in the 3.x roms?
I am quite sure it does not work for compressed files under linux - I just did not implement the compression routines.
dumprom worked with 4.00.05 4.00.11 4.00.16 roms. I cooked 4.00.11 and 4.00.16 roms, and the rom was fine. I never used windows box during the process. only when i tried 4.00.21 and 4.01.00, there was error. anyway, i don't care, since I need as much rom as possible and 4.00.11 seems to be the best choice for me.
thanks for writting mkrom, a terrific tool. I don't like the way xda-developers.com promoting kitchen but not mkrom. mkrom is much simpler to setup and run, as long as you know about linux. the kitchen is much more complicated to get it to work and most people don't actually need such flexibility I believe.
ok i installed cygiwin and was with u till step 5, then i am lost.. when i run step 6 dumprom (in DOS) gives me an ewrror here atr the first few lines from dumprom( wiht latest ATT official release)
img 00000000 : hdr=8c0a1000 base=8c078000 commandlineoffset=8c077fe0
img 00040000 : hdr=800cdde0 base=80000000 commandlineoffset=7fffffe0
img 00180000 : hdr=8024db88 base=80000000 commandlineoffset=7fffffe0
img 00380000 : hdr=8039b334 base=80000000 commandlineoffset=7fffffe0
img 00670000 : hdr=80be2c40 base=80000000 commandlineoffset=7fffffe0
img 00c00000 : hdr=80e99400 base=80000000 commandlineoffset=7fffffe0
img 01050000 : hdr=813efc74 base=80000000 commandlineoffset=7fffffe0
img 01400000 : hdr=815d2ba4 base=80000000 commandlineoffset=7fffffe0
img 015f0000 : hdr=815f0650 base=80000000 commandlineoffset=7fffffe0
img 017c0000 : hdr=81bba0a4 base=80000000 commandlineoffset=7fffffe0
ERROR: could not find pointer for ofs 8c0a1000
invalid romhdr ofs 8c0a1000
ERROR: could not find pointer for ofs 00000000
7fffffe0 - 80000000 L00000020 unknown 30315750 452d3142 412d474e 2d30332e 2d353030 62373239 2d2d2d2d 2d2d2d2d
80000000 - 80000004 L00000004 romsection id=ea0003fe
80000004 - 80000040 L0000003c NUL
80000040 - 80000048 L00000008 'ECEC' -> 8c0a1000
errorsgalore...
so help me here how do i make sure the files extracted are all good also the size (as per ) windows explorer is 33+ not sure how all has been installed in the 32mb rom
did you get default.fdf initobj.dat initdb.ini out of dumprom. dumprom also reported tons of errors but as long as you get the three files out, it is ok.
Dumprom tries to figure out for each byte in the rom what it does. If it doesn't know it says 'unknown' this is not an error, just that dumprom could not determine the use of this byte. The 'could not find 00000000' message means that it encountered a NULL pointer somewhere in rom where it did not expect it, the other one is a pointer to RAM, which dumprom does not know exists. You can safely ignore these errors.
Dumprom was initially written to assist in figuring out what I did not know about the rom, so it tries to figure out stuff that is unknown. Later I added the code to extract files to it. Maybe I should split dumprom in one research tool, to do a detail examination of the rom, and one tool to only extract files.
Most files in rom are compressed, that is why they are more than 33M when uncompressed.
ok i understande the messages...
now here is what i did
ran ssnap and got a picture of the OS and did a compare and have a list of entries i want to add to registru and a folder with bunch of subfolders that need to be added on install
not sure how step 6 goes.. to convert the files to .reg and .txt and how/where do i add my files and registry entries....
any tips...
update...
i did fdf2reg and made a .reg file added my entries in there and then ran reg2fdf to recreatre the fdf...
i hope this is right now i need to fig out how to specify where the files i want added are to be copied i mean some go into windows some in new filders that need to be created...
plz tell me how to go forward.
you don't need to re-create the fdf file again, mkrom does it for you, you only need to take care of the default.reg file under cfg
I am not sure whether you can put files under directories other than \windows only. I did not try that. I suppose all files under /files1 and /files2 go to \windows directory just they happen to locate in different memory location in ROM
Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance
XIP files would report incorrect size. Because they are XIP
If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!
I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem
Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel
IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem
If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).
The WM5.0 emulator is working on my PC.
Japanese Emu, S-Chinese emu, and T-CHinese, emulator. also english.
i want dll, mui, exe files from them, to make Japenese or chinese WM5.0
on my Himalaya with english WM5.
Hope someone can help to dump it or make dump tool.
i have a dump tool my friend made for WM2003 emulator, so not worked for WM5.0.
if need emulator image from WM5.0 SDK, i will upload i them.
Please help!
ms would be pretty stupid if they made it possible for one to unload a real rom image from an enulator
as far as i know then all roms have to be 100% made / "compiled" for each pda to work
so unless that emulator was using an 100% image of the rom for the device you want to upload it to later
i doubt it would work
Rudegar said:
ms would be pretty stupid if they made it possible for one to unload a real rom image from an enulator
as far as i know then all roms have to be 100% made / "compiled" for each pda to work
so unless that emulator was using an 100% image of the rom for the device you want to upload it to later
i doubt it would work
Click to expand...
Click to collapse
thanks for your comment,
but plese dont worry i want just take the resourcese from dll or exe, to make mui files to pretend interface of OS.
i used this way to make japanese OS on my Blue Angel with PPC2003se.
Mr, Mamaichi teached this way to me in the past.
for your refference
http://asukal.seesaa.net/article/6114096.html
http://asukal.seesaa.net/article/5052836.html
Japanese site, but you can see the JPGs
ooh got a bit confused then i guess
Asukal
You can dump the ROM image from WM5 emulator with a normal dumprom tool, but first you need to convert image from B000F to the NB format with the command:
perl splitrom.pl PPC_USA_GSM_VR.BIN -wo ROM.BIN -oe 0x82000000
and then dump it as a normal rom:
dumprom.exe ROM.BIN -5 -d C:\ROM_DUMP
I've tested that on english version of emulator.
you'll need splitrom.pl script and a new build of dumprom tool from itsme.
Mamaichi>>>
thanks for your information!
i will try it!!
Thanks Mamaich!
after i got your private message and done it!
i got dumped roms files form mnu!
@Japanese OS image
@Simple chinese OS image
@Smart phone (WM5) japanese image
after succesfull them, the splitrom have error on following emu image.
@English OS image
@Traditional OS image.
i dont know why???
may try to restart windows system and try again
any way, i got it!
thanks!
hi Asukal,
can you please give me the links to your emu images?
i'm too lazy to search.. ;o)))
thanx
buzz
Yes, why not!
Here it it!
http://www.asukal.jp/ROMs/PPC_USA_GSM_VR.rar
20MB <not dumped yet>
i could dumed english image also.
here it it!
http://www.asukal.jp/ROMs/SDK_ENG.rar (17.32MB) dumped files
i dont know why i couldnt up load this as attachment???? :shock:
so i must use my own server :?
Asukal said:
after succesfull them, the splitrom have error on following emu image.
@English OS image
@Traditional OS image.
Click to expand...
Click to collapse
what is the error text? I've dumped english ROM without errors
to mr,mamaich
i got successfult to dump english SDK emu rom after that.
But i took Bin from SDK in another computer.
I guess Bin file which i tryied dump at beggining was broken or have some problem??
or i have already opened and drove this emu image on the Emulator many times so it was not default already.
i have never tried again about T-CHinese Bin.
i think it can be possible if i took out another T-Chinese bin from another SDK.
the error text was...... cant remember exactry because i left that computer coz i am trip in europe now.
maybe.....
This image files has incorrect(or invalid) boot image.....or some like that.
sorry my late rplay.
I am in Germany now and have to visit Milan and paris after here.
thanks
MUI's in wm2005
Hi, everybody!
I followed this thread and successfully created some MUI's for 2005 (I think) but I can't get the device to load them. I tried changing the registry settings (worked for 2003se) but it didn't help.
No changes I made are visible and the files can be deleted, so I guess they are just ignored for some reason.
Can anyone help please :?:
Thank a lot!
that is true, also cant do that.
keep on studying now.
Something different from WM2003!
MUI security signature?
Hallow again!
I think the problem might be with the digital signature Microsoft now requires. :idea:
Also I made the following experiment:
I put the resources in 2003SE MUI officeres and btres and it did load, but when I tried it with shellres or coresres it didn't work.
I think it won't load unsigned system files…
Any ideas?
Any leads will be greatly appreciated!
:lol:
Re: MUI's in wm2005
levenum said:
Hi, everybody!
I followed this thread and successfully created some MUI's for 2005 (I think) but I can't get the device to load them. I tried changing the registry settings (worked for 2003se) but it didn't help.
No changes I made are visible and the files can be deleted, so I guess they are just ignored for some reason.
Can anyone help please :?:
Thank a lot!
Click to expand...
Click to collapse
because on 2003, files are copied to RAM. on 2005 are used directly from ROM.
buzz
Re: MUI's in wm2005
buzz_lightyear. 2005 can also load dlls to RAM, for example when they are started from storage card or built-in storage.
There maybe one more reason. The DLL may be not loaded if your resource DLL does not have some resources that the original DLL has. Or if your DLL is somehow incorrect. You should make a program that calls LoadLibrary() for your MUI DLL and check the error code if it does not load.
For MS Smartphones there was a registry key that allowed to run unsigned applications. Maybe the similar method exists for WM5.
Asukal. I've attached the program that would try to dump shellres.dll of your device to \storage card\shellres.dll. I've tested the program only under emulator, on the real device it may crash.
If it would not crash - you should look into the produced DLL to examine its resources. This dumper would produce DLLs that are unable to load (they have no relocations information), and their size is larger than it should be, but resources should be extracted correctly.
PM me if the program crashes. And it probably would crash. I'll try to do something.
Mr,Buzz and Mr,Mamaichi!
thanks your comments, and i have just back from Paris and too tired to try mamaichi`s testwm5.exe
aftre sleep while, i will try it! (i dont afraid crash! glad to be sarifice!
I'd recommend you to try this tool - http://forum.xda-developers.com/viewtopic.php?t=23520&start=25#152044
To mr,mamaich
The first attached testWM5.exe dumped only dump.dll(?)
the second TESTWM5.exe of the link can extraxt installed files also, and RAM files can be dumped.too.
but not crashed.
i will remake MUI file and test it!
Thanks!
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.