Database Users

n00b question about adding my own programs

Okay I understand you have to use mkrom and Linux (or cygwin on Windows) to roll your own ROM my question is regarding how one could say remove one program from the SE ROM and include something else, for instance take off the byte counter and put another different counter on or such, would you just copy the necessary files (.exe and dll's) to the files1 or files2 folder and that's it ? What more is involved? Thanks in advance!

for simple programs, that is all there is to it.
some might need more research, as to which registry settings need to be tweaked to get te program to run from the windows directory. and what settings it needs to run at all.

You copy the files to either files1 or files2. Both sets of files end up in the \Windows subdir. So if you do not want to copy the files to RAM (see below), you should make sure the program is set to run from \Windows. Then you add any necessary registry keys to "default.reg", and any file-copy or directory creation commands to initobj.txt. Then run "mkrom <ROMfile>" and hey-presto.

Thanks so much for all your guys awesome work!!

entropy1980 said:
ok sounds good, what would one need to do to mod the registry for the programs (By that I mean prior to booting) I don't want to be mucking around with a reg editor after the device boots just to get the progs to work...
Click to expand...
Click to collapse
Not sure I understand the question. Default.reg just holds the entire registry as present after a cold restart. So if you put something in there, this will be in the registry when the device wakes up.

I think we wrote at the same time , so you answered my question before I posted it !!! What you said made complete sense! Thanks!

entropy1980 said:
[...]so you answered my question before I posted it !!! [...]
Click to expand...
Click to collapse
I installed the phpBB telepathy mod a couple of days ago, so I guess it's working.

Hey I knew you were going to say that.... :lol: :lol:

hi,
i want to add the skelmir java virtual machine (thats default installed in windows\ceej) and copy the swingall.jar in the windows\ceej map.
I have the cab file of the virtual machine but i can't find out which files are in it (when i open it with cabextract is shows .001 files and not the files that i find back in the device)
please help me

Using Special Edition ROM, Tthe CabInst tool will run CAB files on the device if you move it there manually and double-tap it. It allows to set a new directory to install in.
Also the System Snapshot tool will write a file in the root of the device which holds a list of the entire filesystem and registry contents, so you can compare and see what changed. UltraEdit for the desktop has a compare function.
Good luck...

hi,
i installed it to a seperate directory and zipped the files. i also took a snapshot when the xda was fresh and after install. i only can't find where the xda's gets is files from in:
43 <! [\Windows\AppMgr]
8544 <! 31/12/2002 12:31 1632 FC0E9EE1 Skelmir CEEJ Virtual Machine.DAT
8576 <! 16/02/2003 23:10 27 AEBB1DF3 CEEJ.lnk
8587 <! 16/02/2003 23:10 40 1EAF4EB3 CEEJ Examples.lnk
8588 <! 16/02/2003 23:10 27 AEBB1DF3 CEEJ.lnk
because these are not in the map where i extracted the cab file too. maybe you can take a look for me and tell me what i have to change in mkrom to have ceej by default installed
the extraced cab map:
http://www.devosjansen.nl/xda/java installed.rar
the snapfiles:
http://www.devosjansen.nl/xda/xda snapshots files.rar
thanks in advance

laurens0619 said:
hi,
i installed it to a seperate directory and zipped the files. i also took a snapshot when the xda was fresh and after install. i only can't find where the xda's gets is files from in:
43 <! [\Windows\AppMgr]
Click to expand...
Click to collapse
These files are generated during the install process, and contain uninstall information. You do not need to write them if you install in ROM, since you don't need/want your programs to show up the in the 'Add/Remove Programs' dialogue.

ah i understand,
so i just put the files in the files1 or files2 directory and add this reg files to the default.reg? i dony really understand the readme file

ah little kick,
isn't also good for the next SE rom? because you have finally a java virtual machine on the xda and the app is freeware (got it from www.skelmir.com)

laurens0619 said:
isn't also good for the next SE rom?
Click to expand...
Click to collapse
Noted...

nice but can you please help me out for the moment? i dont know which part i must add to the default.reg file

laurens0619 said:
I dont know which part i must add to the default.reg file
Click to expand...
Click to collapse
default.reg holds the registry that is present when the system wakes up from cold-boot. So any registry entries your installer (or first run of the app) has made that you would like to have present should go in there. Clear enough?

almost
so i just copy paste the **** at the end of the reg file? and the files in the files 2 map
but how will the rom know where to put the files??
sorry if i'm stupid but i don't want to f*ck my rom so i can use me xda's as a frisbee

Yes, the registry entries can be pasted at the end of default.reg. It doesn't matter if there's earlier entries with the same values, since the latter ones override.
All files in files1 and files2 will end up in \Windows, and if you want them somewhere else, (where they'll take up RAM), you must manually copy them (or pre-made links pointing to them) by issueing commands in initobj.txt.
Take a real close look at initobj.txt, and you'll get the picture.

Help for XIP building

Hi all,
I'm an owner of FSC T830 Loox...
With the great help of bepe and mamaich I'm trying to cook my own rom... (thx guys, really!)
At the moment replacing even one module makes the device not to boot.
The problem is now upgrading the rom from aku 2.x to 3.x
As mamaich says newer AKUs have added new functions to coredll, therefore I need to port the XIP section...
I need help on this case:
I succesfully dump the XIP of my ROM
dump -o 0x00250000 myrom.rom xip.bin
dumprom -5 xip.bin -d xip
The question is: how can I port the XIP section from a newer AKU?
Thanks for all your valuable helps!

hi turchino,
do you find a solution for flash a loox t to a newer os version?
bg joy

Hi!
I'm also trying to port the xip section from a newer AKU to the T830.
It seems that none of the current tools is working correctly with that rom. Rommaster isn't working at all. Dumpromx can extract files, but not replace any (e.g. replacing a bigger file with a smaller ->not enough space...)
I've tried to manually replace coredll.dll in the t830 xip section with the newer one but it didn't want to boot. The strange thing is that t830's coredll.dll is much bigger than one from AKU 3.5.2. Any ideas about that? (maybe compression?)
I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?
Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting.
Any ideas how to get that running?

hey. bepe's xipport is designed for dealing with WM5/WM6 xip's.
with dumpromx you would need to increase the image file size by adding 00 bytes at its end before attempting to add anything. be careful, if the xip section grows too large then it may not fit in the partition in your nand flash....
also i'm not sure if it supports wm5/wm6 xip editing or just ce 4.x/wm2003/ce3.
rommaster is too buggy dont even try that one i think...
manual replacing isn't too tricky if you know what you're doing.... you need to know about PE header stuff. how did you try to replace it?
also, the new coredll should have the same base address as the original one or one that isn't conflicting with anything else.
did you make sure about that?
did you also edit romheader properly - because if this new coredll was larger than the original one the image is larger for sure and romheader needs editing.
don't forget about compression issues either. maybe that's why the original one is much bigger. but i would need to see the coredll's in question
anyway it is possible to do a coredll replace manually (did that before), no worries. but bepe's tool might make it easier
you say: "I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?"
if psize is 0, then the .pdata section isn't really initialized data. it's a zero sized section and will only be existing when the loader loads the executable into ram.
but it sounds kind of strange to have a .pdata with 0 size, which file had this section?
edit: ok i see you meant nk.exe heheh. that's fine. it usually does have a zero sized section
you say: "Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting."
how did you do the relocating?

xipport was the exactly the tool I was looking for. After a few modifications "realloc P" of the unmodified xip gave me exactly the same map.txt as the original t830 xip map.txt. After exchanging all kernel files (except hd.dll and osaxst0.dll which were needed to keep another oem file in the same location as it was before), reallocing and changing the header address in nk.exe it still isn't booting (it runs nk.exe but gets stuck somewhere in there). Maybe you can have a look at the whole thing (download here, with modified xipport)
As for the coredll, it turned out that dumprom missed a section.
I did the relocation by writing a little app which runs through all pointers and changes them, but this is also possible by editing romheader.txt from xipport.

ok I've changed the other dlls too (had the same size), but it still wont boot. Is there a kernelflag which I can set to get debug messages on the screen? Or do you know if the nandflash driver trueffs.dll from AKU2 is compatible with AKU3?

hey. sorry for the delay.
did you solve the problem yet?
if not, i'm going to check it for you soon.
about coredll. OK but how do you mean dumprom missed a section? i've never heard that before about it.
relocation: yeah, romheader.txt is the trick there. but, must be a nice app. i'll check it out (i see it's in the zip)
edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot).
p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?

"edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot)."
The xip in "xipport" is the modified t830 xip that doesn't boot. (btw. xip.bin in that folder is the original t830 xip). And the xip in "xipport aku3.5.2" is the xip I want to port to the t830.
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
"p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?"
yep, the kernel always gives a me message when it has found the romheader and continues booting. Therefore I always know when I missed something

hey.
OK that sounds more clear now about which xip is which!
i'll look at it again soon.
until then: did you verify the copyentries are all OK? xipport sometimes has a silly bug regarding them.
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
also pay attention to map.txt see if the base addresses overlap or not (usually not but worth checking), also if .data base addresses (the 0x01Fxxxxx ones) have not been changed. they should not be changed. another xipport bug sometimes.
new--->
update: i looked at your xip now.. none of the above seem to apply. i'll leave that stuff there though.
last thing i can think of is try editing physlast in romheader to point to last actually used byte in xip.. that shouldn't matter but who knows
can you tell me how far does your system boot. maybe the xip is fine and your IMGFS part is wrong. check for module overlaps.
what is last message you get from your kernel?
and, to answer your question about kernel wanting to have files at specified addresses. well, the kernel regions have to stay at the original addresses in the xip, except for the region that is copied out and for the discardable last region (same for the debug crap dlls)

Core_Z said:
"
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
Click to expand...
Click to collapse
Hi Core_Z,
I'm trying to accomplish the same thing for our XDA Atom. I was wondering if you could describe how you achieve above. I, too, would like to replace the coredll.dll in our old AKU2.2 from the AKU3.X
These are the steps, I made using the modified XIPport (with realloc function):
1. coredll.dll comes from XIP of Atom Life which has same base address
2. replaced the modules and corresponding txt file into ATOM AKU2.2
3. new core is larger than the old one; so, I increase the ROMHDR.txt physlast to accommodate it.
4. realloc / write new maps.
5. move the rom header pointer in the nk.exe S000 module to the new one
6. built xip_out.bin
7. wrote the new bin to ROM image file
8. flash the device.
It won't boot. Did I miss anything?

cmonex said:
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
Click to expand...
Click to collapse
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs

I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.

check this out Jiggs,
http://www.pxdxa.com/read.php?tid=40125&fpage=1&toread=&page=1

jiggs said:
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
Click to expand...
Click to collapse
hey! i'm back if you still need help: you dont need these dlls, they just take up space. if you really want them then you can do one of two things:
1) use the original dlls from the device's original xip
OR
2) rebase them but this can be more difficult than with ordinary dlls.
(i did not try either, because those dlls are just for debugging anyway.)

jiggs said:
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
Click to expand...
Click to collapse
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.

cmonex said:
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
Click to expand...
Click to collapse
Thanks for the info! I'll look at this later.

Here goes nothing: I've been trying to understand the whole porting process but no one ever posts on my threads, so I figured I'd post on this one since it's about the same thing. I'm reading the thread and I'm following... most... ok, half of it. I thought the process of porting the XIP and the SYS was as simple as well... this. If someone wants to correct me, by all means, please do so.

Is there an autorun.exe that points to..

Howdy.
Does anyone know of an autorun.exe which is coded to look in "extendedROM"? (As opposed to "extended_ROM").
I'm aware of PocketPC Installer and that it probably can create a custom autoexec.exe for me, but I'm looking for a free solution if there's already one hacked up out there.
Thanks
--SUmmiter

I thought that it got that value from the registry:
[HKEY_LOCAL_MACHINE\Comm]
"AutoRun"="\\Extended_ROM\\AUTORUN.EXE"
"AutorunCFG"="\\Extended_ROM\\CONFIG.TXT"
"AutoRunType"=dword:0
"TurnRadioFlag"=dword:0

Yes but you have to add this into rom before building if you want it to look for autorun there after flashing

Right. My possibly incorrect assumption was that autorun.exe is hardcoded to look inside "Extended_Rom" for it's config, ignoring what is in the registry. I'll mod my OS rom and try changing AutorunCFG and see what happens.
joemanb said:
I thought that it got that value from the registry:
[HKEY_LOCAL_MACHINE\Comm]
"AutoRun"="\\Extended_ROM\\AUTORUN.EXE"
"AutorunCFG"="\\Extended_ROM\\CONFIG.TXT"
"AutoRunType"=dword:0
"TurnRadioFlag"=dword:0
Click to expand...
Click to collapse

Autorun.exe and config.txt can be anywhere as long as the registry points to them.
(if the registry points to Extended_Rom, then of course the files need to be included in the Extended_Rom.)
My autorun.exe is in windows, and config.txt is in the extended rom, but I've tried it other ways and it's worked.
alot of cooked roms use this feature to do a final modification like loading a theme from the windows directory.
BTW config.txt contains the paths to the files you wish to process, so it doesn't matter where autorun.exe, or config.txt are.
In other words, you could put autorun.exe, and config.txt in windows or anywhere else as long as the registry points to them, and it will process the files on the paths contained in config.txt

Little question, has autoexec any link in startup, or not?
(I make in intiflash registry entry es mentioned before, I have hope corect congig.txt but after HR ... nothing, co customization . Interesting is, that I can launch autoexec in ext rom manualy and it runs ok. I rebuld quite naked WM 6.1 rom)
Thx for help...

EasyPortOven V2.2 [Updated May 11 2008]

This is a release for my ROM porting kitchen. It ports both XIP's and SYS folders. It currently supports the following:
Herald
Wizard
Prophet
Kaiser
Elf/Elfin
Hermes
Zinc
Athena
http://www.darthnet40.com/xda/ivanmmj/Kitchens/
(You will need 7-Zip to open the file.)
This is compatible with Bepe's extended kitchen, but I don't believe he ever released one for every device out there. It requires a ROM folder with an extracted XIP folder within it. Just download the Herald's and you'll see what I mean. The ONLY tested section has been the Herald section as that's the only device that I have.
If your device is compatible with Bepe's kitchen or my kitchen, it will automatically launch the kitchen right after.
Instructions:
Delete your old SYS folder
Place the SYS file you wish to port into Working_Folder
Place your xip.bin that you wish to port into the Prepare folder
*Note: Close the XIPPort program after pressing "Make Packages." The script will take over after that.
You should not have a Working_Folder with an OEM, SYS and XIP folder (and a Tools folder if you have Bepe's kitchen, even more if you have my kitchen.)
Double click on the RunMe file and choose your device.
For those who have a kitchen:
Place bepe's kitchen in the Working_Folder (so that OEM/SYS/ROM and other folders are right within Working_Folder.) Alternatively, you can place also place all the files into EasyBakeOven's folder. Allow the Working_Folder to override EasyBakeOven's Working_Folder. You will not loose any data but will bypass a few "info" scripts. This will not cause any problems.
Obligatory Warning Label:
Use this at your own RISK. I cannot be held liable for any damage caused to your device by your own mistakes or by my mistakes in the instructions.
If you wish to know how to do this manually, head over to my HowTo thread.
Thank you's go to:
Bepe for his Extended kitchen and Herald/Atlas files
ababrekar for the elfin files
l3v5y and xvx45 for the Prophet files
character and ginminded for the Wizard files
Script for the Kaiser files
tjkhattak61 for the Atom Exec files
cruzzmz for the Zinc files
caxio for the Hermes files
irus for the Athena files
Changelog
V2.2
Added Athena Compatibility
V2.1
Added Prophet Compatibility
Added Elfin/Elf Compatibility
Added Hermes Compatibility
Added Kaiser Compatibility
Added Zinc Compatibility
Added Atom Compatibility
V2
Added Wizard Compatibility
Rewrote script to add expandability
V1.5
XIP porting complete
V1
SYS porting complete

Woo! I've failed to find a link for this up till now, but now I can cook some new ROMS!!
One thing, the read me doesn't include some of the more reason compatibility improvements...
Welcome to EasyBakeOven!
Devices supported:
Herald/Atlas
Wizard
Note: Make sure that the XIP in your recieving folder has been extracted already (You should have a ROM folder with a XIP folder inside it.) This is not an issue if you're using Bepe's Extended 6.1 kitchen or my own JustClean EasyBakeOven.
Thank you's go to:
Bepe for his Extended kitchen and Herald/Atlas files
ababrekar for the elfin files
l3v5y and xvx45 for the Prophet files
character and ginminded for the Wizard files
Script for the Kaiser files
tjkhattak61 for the Atom Exec files
cruzzmz for the Zinc files
caxio for the Hermes files
irus for the Athena files
Click to expand...
Click to collapse

l3v5y said:
Woo! I've failed to find a link for this up till now, but now I can cook some new ROMS!!
One thing, the read me doesn't include some of the more reason compatibility improvements...
Click to expand...
Click to collapse
Noted. Thank you!

Has anyone found this even remotely useful? If not, I will not pursue adding more devices.

Has anyone found this even remotely useful? If not, I will not pursue adding more devices.
Click to expand...
Click to collapse
I have! I've ported a Kaiser XIP and a Touch one to the Prophet! Problem is I couldn't find the latest builds so they where slightly out of date...

l3v5y said:
I have! I've ported a Kaiser XIP and a Touch one to the Prophet! Problem is I couldn't find the latest builds so they where slightly out of date...
Click to expand...
Click to collapse
Just for being nice to me, here you go!
That's the newest official build. Be careful of anything "newer," they're fakes.
It's the one labeled 19213.7z
You'll need 7Zip to open the file. In it as the xip.bin and the SYS folders.

Yay!!!
Porting time!

I have one feature request!
Would it be possible to build a feature in that cleans out the folders before porting?

I think I'll test later cause actually I'm in exam but I think it work, I'm on the same device as l3v5y so I'll make my test and maybe take to you Artemis files (my other phone)
Thank for your hard work

Great tool ivanmmj.... I have a few questions. I guess I don't fully understand the process.
I've been able to get the XIP folder, os.nb.payload and romhdr.bin files from a KAISER rom... plus I used the .VM and WinCENLS_WWE folders from a working HERMES rom, but I can't seem to get past the second boot screen. A question I had is... do we use the os.nb.payload and romhdr.bin we got from the KAISER? or do we use those from a working hermes rom? and the XIP directory, do we need to change anything in there? or is just extracting it out, enough to work?
Thanks in advance.

Awesome tool, looks like a dummy can me even port ROM's will try it out sometime. Thanks bunches!

l3v5y said:
I have one feature request!
Would it be possible to build a feature in that cleans out the folders before porting?
Click to expand...
Click to collapse
Already ahead of you. Today I noticed that I tend to leave a mess behind. lol I'll have it remove the files before replacing them, then I'll have it delete the extra files created during the process when it's done. (This part is already ready but I just haven't uploaded it. The removing the files before replacing them, I haven't done so, yet. Although this might not really be needed. Only the cleaning after part.)
...Maybe I don't know what you're talking about. lol
Explain it to me.

AssassinsLament said:
Great tool ivanmmj.... I have a few questions. I guess I don't fully understand the process.
I've been able to get the XIP folder, os.nb.payload and romhdr.bin files from a KAISER rom... plus I used the .VM and WinCENLS_WWE folders from a working HERMES rom, but I can't seem to get past the second boot screen. A question I had is... do we use the os.nb.payload and romhdr.bin we got from the KAISER? or do we use those from a working hermes rom? and the XIP directory, do we need to change anything in there? or is just extracting it out, enough to work?
Thanks in advance.
Click to expand...
Click to collapse
You need the XIP folder, os.nb.payload and romhdr.bin of YOUR device and the xip.bin and SYS folder of the rom you want to port INTO your device. Which device do you have? Tell me and I'll "draw" a map of what goes where.

xvx45 said:
I think I'll test later cause actually I'm in exam but I think it work, I'm on the same device as l3v5y so I'll make my test and maybe take to you Artemis files (my other phone)
Thank for your hard work
Click to expand...
Click to collapse
That would be more than welcomed especially since I'm gonna use my Herald cooking class and modify it to teach Artemis users, also.
ai6908 said:
Awesome tool, looks like a dummy can me even port ROM's will try it out sometime. Thanks bunches!
Click to expand...
Click to collapse
My hope is that it will allow just about anyone to port a ROM. ^_^

ivanmmj said:
You need the XIP folder, os.nb.payload and romhdr.bin of YOUR device and the xip.bin and SYS folder of the rom you want to port INTO your device. Which device do you have? Tell me and I'll "draw" a map of what goes where.
Click to expand...
Click to collapse
Thanks for replying ivanmmj... I have a hermes, and I've been doing exactly that... my problem is when I go to build it, I get "An unhandled win32 exception occurred in buildxip.exe [2276]"
If I put in my older XIP build, buildxip works fine... so I'm lost now. Oh, and I'm trying to port the 19213 official att kaiser rom XIP.

AssassinsLament said:
Thanks for replying ivanmmj... I have a hermes, and I've been doing exactly that... my problem is when I go to build it, I get "An unhandled win32 exception occurred in buildxip.exe [2276]"
If I put in my older XIP build, buildxip works fine... so I'm lost now. Oh, and I'm trying to port the 19213 official att kaiser rom XIP.
Click to expand...
Click to collapse
You'll need:
OEM: hermes
ROM folder: Hermes (uncluding the XIP folder and all the other files)
SYS folder from kaiser (look for and remove MSkernel from this folder... I'm not 100% on that folder yet and future versions may handle that folder automatically)
Place the xip.bin from the kaiser into the prepare folder.
Now run the RunMe

ivanmmj said:
You'll need:
OEM: hermes
ROM folder: Hermes (uncluding the XIP folder and all the other files)
SYS folder from kaiser (look for and remove MSkernel from this folder... I'm not 100% on that folder yet and future versions may handle that folder automatically)
Place the xip.bin from the kaiser into the prepare folder.
Now run the RunMe
Click to expand...
Click to collapse
I really appreciate your help ivanmmj, same thing again. It chokes up on BuildXIP.exe ...I have BuildXIP version 0.53 if that makes any difference. I tried with two XIP versions... 19209 and 19900. I'm about to give up.
Oh and I have Visual Studio 2008 installed, so I don't think it would be the runtimes... would it?

AssassinsLament said:
I really appreciate your help ivanmmj, same thing again. It chokes up on BuildXIP.exe ...I have BuildXIP version 0.53 if that makes any difference. I tried with two XIP versions... 19209 and 19900. I'm about to give up.
Oh and I have Visual Studio 2008 installed, so I don't think it would be the runtimes... would it?
Click to expand...
Click to collapse
It might be.... I'll have to do some research...

Ok, I even installed the vs2008 runtimes, same thing.. I found buildxip v.54, same thing... then i moved the whole ROM folder (new XIP) out and put in the old 19209 one and it ran... so maybe there's something wrong with 19213 with hermes? ok, I give up. Thanks for your help!!

19213 porting to elfin
i'm trying to port the 19213 to my elfin, and after porting when i use bepe's kitchen, it gets stuck at this screenshot. anybody help!!!

Gain more space in ROM.

Today I just tried this, I compressed my softwares which I have cooked in my ROM using UPX4PPC and cooked them in the ROM. As I have a small 32MB ROM (Himalaya), if this is possible to do with the default OS dll & exe files, it would be very useful. As I noticed, there is no big difference in the loading time of compressed files & the original. I searched the forum, but found nothing on compression of system OS files. Is there anyone who have done this before? Is this ok to do with .net CF dll & other large dll & exe files in ROM...?

shiranmotha said:
Today I just tried this, I compressed my softwares which I have cooked in my ROM using UPX4PPC and cooked them in the ROM. As I have a small 32MB ROM (Himalaya), if this is possible to do with the default OS dll & exe files, it would be very useful. As I noticed, there is no big difference in the loading time of compressed files & the original. I searched the forum, but found nothing on compression of system OS files. Is there anyone who have done this before? Is this ok to do with .net CF dll & other large dll & exe files in ROM...?
Click to expand...
Click to collapse
so you're compressing before cooking? interesting. all's working ok?

fredcatsmommy said:
so you're compressing before cooking? interesting. all's working ok?
Click to expand...
Click to collapse
EXE files can be compressed successfully. But when I compress all the dll files, ROM is not starting. Compression of some dll files works fine. So I wanna find which files can be compressed and which are not.

shiranmotha said:
EXE files can be compressed successfully. But when I compress all the dll files, ROM is not starting. Compression of some dll files works fine. So I wanna find which files can be compressed and which are not.
Click to expand...
Click to collapse
Does it go for SYS and OEM?
Interesting finding!!!
I'll be tunned
Regards,
Jaime.

Tapped "Save Changes" twice.

http://forum.xda-developers.com/showthread.php?t=397792
http://forum.xda-developers.com/showthread.php?t=265175
http://forum.xda-developers.com/showthread.php?t=335982
http://forum.xda-developers.com/archive/index.php/t-276884.html
..and so on..
maybe it's time to READ, not write?
few words about fighting for every goddamn kilobyte..
some exes or dlls cannot be upx-ed, NOTHING from rom/xip cannot be upx-ed,
do not try to upx .netcf soft, or its oempackage dlls, some dlls from mms oempack may lose its functions; isilo and some offROM soft will break, DO NOT upx today plugins(2 be sure), TCPMP plugins CAN be upxed, CPL-s usually CAN be upxed,
some upxed dlls may have ADVERSE effect on memory( i mean clean boot mem and so on), especially dll's that are launched after boot(..erm, resident, crucial ones).
whole art is to get thin line between making XIPmodules and upxed files....RAM-ROM loss, i mean.
and stability.
if you need more romspace, you will need do more, than simple upxpackclick, trust me...
look at size of tahoma and courier .ttf from DIFFERENT kitchens(old/new).
gain.
look at things that you will not use - cut it.
gain.
do not use stupid, trendy soft, until you MUST.
gain.
erase stupid html help files, not crucial temptates, etc
gain.
edit welcomehead.96.png(it may have 160 kb, or 2 kb...)
delete services and things that you do not need: i.e.sqm service(well..not delete = dummy), maybe wlive etc...delete mms oempack, if you do not need it - you CAN install it later..remove ppt.exe, its dlls and mui etc..
gain.
you need 2 mb skin instead of thinking/editing?
loss.
you want to have 1936237569423 home clones at once?
loss.
you do upx 23194673459826032194 - dlls exes AT once and flash...
loss(of time).
no hklm/init editing?
loss.
no reshacking(i.e. dialer skins, some keyboards, soft gfx etc)?
loss.
no unused dll's deleting?
loss.
you are not able to reedit soft gfx to optimize its size...
LOSS.
etc etc..
for going to extreme it is possible to cut XIP(but leaving crucial sys contents instead), but it is rather...risky.
i do not know more bout it..
i loaded >26-28 mb of useful soft/dlls/cpls/plugins/fonts into my rom, btw(wizard). 6.1.
84 apps, or so..
but ignore me...just short outburst..it is so hard to find something interesting there lately...
btw, usually it is safe to upx camera.exe.
worth it, imo.
safe files to be upxed, imo:
ppt.exe
word.exe
pxl.exe
and many more, of course.
there is no big difference in the loading time of compressed files & the original.
Click to expand...
Click to collapse
romfiles, maybe, but 9 mb file vs 2 mb file from sd card...you know..
OT:
btw, remember: RGU files MUST be saved as UNICODE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(that is very easy method to see first/second splash ONLY, nothin more..)
easy 2 forget.

well i use UPX for about 2 years in roms but I never sompress anything major in SYS folder except the Office pack, never upx .net (or it wil not work) some programs like solitaire and bubble breaker and calculator (spb one) can be compressed

2 years in roms but I never sompress anything major in SYS folder except the Office pack
Click to expand...
Click to collapse
well, you prolly did not need more space...for these 2 yrs.
EOT,sry.
good luck.

Bear in mind that rom's which have been upx'd take up MORE memory to run than non upx'd ones because some of the memory is not released. This has been hashed back and forth in detail in the previous threads but compressing everything in site is NOT the answer.

that rom's which have been upx'd take up MORE memory to run than non upx'd ones because some of the memory is not released.
Click to expand...
Click to collapse
agree...
idd, some - it may be not a problem, if it is not thing, that works ALL the time(crucial system dll, etc).
if it is..its useless to even try. loss may be quite..big, sometimes...