yashsingh1/xdaforums huggingface dataset:
[Windows Mobile] AndrewSh:
The full version provides additional features of the kitchen. But not the lifetime personal support and private correspondence.

The OEMDrivers relocation does not differ from other modules relocation.

Did you try to copy the name of the module and paste it into the menu box? Try it...

After doing that - try to save your custom config to "make this persistent". But later if you wanna get these settings - load proper config.

The rest of your post - sorry - I can not understand fully... Maybe your needs and requirements are too sophisticated for me (too much beer and English is not my native) maybe something else.

I will anyway pass the info about this post to Barin and hopefully he will reply.

P.S. Unattended exceptions - happen only because of user's mistakes. This situation was several times explained in the correspondent topic at mobileunderground - try to read there.
[Windows Mobile] tobbbie:
I had PM-ed all this 3 weeks back - no reply at all.

The relocation is different for OEMDrivers as explained in my post. They are NOT listed in the relocation information (like all other modules). I don't want to argue about all this in public, however - sadly I could not get direct contact for cleaning this up.

Also about getting the exception list sticky - it simply does not work (despite save and all that). Have you tried yourself?

And finally about the unhandled exceptions: It is easy to not capture the reason when something goes wrong (if a user mistake or not) and omit explaining what was expected. Then however I expect to see at least a debugging option that tells where that happened so it can further be debugged. As it is you are basically blind and need to guess around.
[Windows Mobile] tobbbie:
Well - as an easy start I just dumped a working (and previously fresh built) ROM. So all RGU are working correctly. Then a subsequent build fails as indicated without any hint :-(
[Windows Mobile] Farmer Ted:
The '!!!!!' that you see in the dumpmap indicates that you have overlapping module allocation. This is not good. Are you trying to re-cook a custom rom? You'll get this problem if the modules are missing the .reloc section. Maybe you've got a bad set of oem drivers, that are missing the reloc sections.

Do you have a native kernel, or are you using a 6.1 kernel? Why do you want to recmod any of the oem drivers? It doesn't make much sense to do that.

Under the xip settings, I have the 'squeeze nk sections' and the 'remove dll gap in slot 0' boxes checked. In the build/dump rom settings, I have the 'remove dll gap', 'use built-in engine to rebase', 'autodetect kernel type', 'split L modules', and allocate according to packages.cif selected (among other things). I don't use the minimal slots bound or slot 0 modules list.

You might use the 'do not rebase list' if you had one stinking module that had to be loaded Low, but otherwise, you wanted all the rest of the L modules split. Then you could stick it in slot 0, where it would work properly. I've actually been thinking of doing it with rsaEnh.dll, which normally is cooked in as a file (and must be added Low, otherwise the rom won't boot), but I figured maybe I could get it to work as a module if I set it in slot 0 low manually and then put in on the do not rebase list. Probably not worth the effort, though, lol.

The object list error makes me think you're missing something. It may have nothing to do with rgu's. If you look in the temp folder, there's a new (and awesome) feature where only modules and dsm's are copied into the dump folder, if they need to be corrected. All other files (or objects) that don't need to be copied stay in there packages. It speeds up the build. My guess is that the kitchen is looking for an object on the object list, and it's not finding it. It's also possible that you have a corrupted file in the kitchen, and the build is crashing because the file can't be used. Try scanning your drive for errors.
[Windows Mobile] tobbbie:
I am not familiar with the details of relocation. It plain works (somehow) with my old kitchen and the wmreloc.exe relocates all 250 modules resulting in a bootable ROM. It has a side-effect though as the display driver puts some garbage in the empty parts off the scrollbars.

It must be noted that the components I build on are very old cooked ROMs themselves (Hurricane WM2k3 device and related cooked WM6 ROMs). So the ddi.dll is from another device but it works in the cooked ROMs.

When I dump that (old kitchen) rebuilt ROM with OSBuilder and try to rebuild it there, then not all 250 modules are relocated but only ~215. No clue about the rest (hence my speculation).

I have no other components for the OEMDrivers than those from the old cooked ROMs and need to build the rest around it.

The build problem always occurs immediately when it says compiling registry, but no clue (also with system trace tools) which file it tries to access that does not work.

I currently juggle with all types of kitchen/relocators to which will fit finally.
[Windows Mobile] Farmer Ted:
Ok, well it sounds like your modules aren't going to work, at least not the way you're doing things. Why are you dumping the old rom with OS Builder? If it's a custom rom, you're bound to run into issues. Can't you just convert all the packages over to the necessary format, and work from there? If you have the source modules (pre-cooked), then you could just copy them into your OEM driver package. To check if the modules are intact, just open the package dsm with osbuilder, and then right click on a module in the modules and files tab and select module info. Then open up the info sheet for the last module. It should be a .reloc section, and the top-left corner of the popup will say something like S004 (.Reloc).
[Windows Mobile] tobbbie:
The ROM is from 2007, a time when Frankenstein ROMs were created by wildly replacing parts of packages. The DSM were not reconstructed properly and the ported ddi.dll has no relocation section (despite S000 - S0004 are there, none is of .reloc type).

The later wmreloc.exe seems not to care about that and relocates everything.

Possibly OSBuilder is correctly taking care about all info that should be there (DSM, .reloc etc?) and acts accordingly - which could explain that only 233 (I checked it now) of 250 modules are treated in the relocation part. I then need to take care that I get all the non relocateable modules in OEMDrivers from the original dump and see if OSBuilder can create a booting ROM from there.
[Windows Mobile] Farmer Ted:
Your best bet is going to be to find an original shipped rom and dump the OEM Drivers from it. If that doesn't work, you can always try to manually relocate the 17 modules. It'll be a fun exercise in hex arithmatic, lol. But it should be do-able, I think.

Edit: you could also just take the modules from the dump folder of your other kitchen and use them in this one; just make sure the kitchen doesn't reloc the modules during cooking, and you should be good to go.
[Windows Mobile] tobbbie:
I went step-by-step anyway. The original ROM is WM2k3, so it seems that there is nothing like slot0 and slot1 - all items are files after the dump. I tried using those originally for the OEMDrivers, but without any success.

So I went to base the rest of efforts on working cooked ROMs for WM6. They DO work, but the OEMDrivers parts has some non-Hurricane parts, e.g. the ddi.dll, which comes from the ELF (an OMAP 850 device). Also there replacing it with a Tornado ddi.dll (also OMAP 850) did not work. So instead of guessing around too much I stay with the various cooked ROMs OEMDrivers part, which seems to be identical anyway.

Merging such a cooked ROM OEMDrivers with the other cooked Tornado ROM is almost done and after I ported the XIP as well (both on WM6) I finally succeeded that also the .provxml were executed at last. The latter was a major headache but now almost everything is as expected - almost!

Relocating the modules with greloc did not produce booting ROMs and only after I came accross WMRELOC everything worked as expected, with the glitch of the scrollbars filled with garbage - sigh...

So my try with OSBuilder and the option to "not relocate" some modules. I had to register to get that option (not a big thing anyway - so no complaints there), finding finally that ddi.dll would not be relocated in my case and that the "not relocate list" seems not sticky as well - phew :-(

Guesswork starts again...

So will try with dumped OEMDrivers unchanged from the working cooked ROM and combine it with the rest of the Tornado ROM which I intended to port to Hurricane - let OSBuilder do all the relocation.

To be continued....
[Windows Mobile] AndrewSh:
tobbbie

Farmer Ted is totally right.

Remember - you CAN NOT use custom rom as an OEM or other source of modules. Only the official roms containing ALL dsm files and reloc sections in modules are applicable as a sources.

Anyway - as I promised - Barin just read your message :)
[Windows Mobile] tobbbie:
I know about all the potential problems attached to cooked ROMs. But as I want to cook for such an ancient device and I have to base my efforts on that of others in the past - my only choice is to understand the methods that are applied by OSBuilder.

At least nobody has put intentional efforts in camouflaging the packages that time (e.g. by "merge to one") - so I do have hope to get it running some time as it should be...
[Windows Mobile] tobbbie:
I just don't understand the relocation function for OSBuilder.

I expect the relocate to sort out all the memory locations for the present modules in such a way that no overlaps are present after relocation. However when I look in the dump-map.txt after the relocation has been done, a lot of !!!! lines stay there. What can I do in the process to make them vanish?! Is that not the purpose of relocation as such? Or is the file telling the status BEFORE the relocation and the window-content the status AFTER?

I see the module ddi.dll in the dump-map.txt, but it is not present in the relocation window - WHY?!
[Windows Mobile] AndrewSh:
The method of OsBuilder is to dump a source rom, analyze DSM files (they should contain the information about the Package - list of files, their size, attributes, flags and so no, registry and other information) and according to this information - group the files and modules to OEM SYS and XIP packages. According!!!

If the DSM file is missed or corrupted or equal to zero - OsBuilder can not identify the list of modules and files dedicated to the package.

Reloc - if the module miss the reloc section - how can it be relocated properly?

Ancient your source or not - does not matter - it should be original shipped or created as original - with normal correct dsms and untouched modules. If you want to create the kitchen for ancient device - you should anyway use latest stock rom as an OEM and XIP source.

P.S. The "Do not rebase modules (list)" feature (normally - not used by anybody except you :) ) is fixed by Barin right now - wait for the updated version of Builder - you will get what you want.
[Windows Mobile] tobbbie:
Well, the DSM and package can be reconstructed (did that) and if the module has no reloc section - then it SHOULD NOT be relocated - yet the rest of modules should.

Edit:

I hope there is an easier way to find out if a .reloc section is there or not other than the prodedure Farmer Ted has described. Will be tedious to step through all packages, DSMs, Modules, inspect the components and seek for non present .relocs - sigh...

Consequently the art of relocation is to handle the non-relocatable modules together with those that can be relocated and construct optimally filled slots. It seems however that this is not easily possible (never was).

I have no clue about the logic of WMRELOC, but this was the only relocator that produces a booting ROM right away - always. It also relocates ddi.dll, at least in such way that things work straight, except the quirk with the scrollbars. No idea what else may be hidden though...

I was after the "non relocatable" stuff just because I saw that in the OSBuilder - expecting it to work as well. If it needs fixing, well then it will finally work as "advertised". I know that I do something out of mainstream and I also know that my sources are non optimal - but hey I do it for me to learn only anyway :-) Once the ROM works, I will share it (if anyone cares, maybe even the kitchen + sources) - but not before that.

Would not mind discussing with Barin directly though, but he seems a shy (or busy) guy :-)
[Windows Mobile] AndrewSh:
You better discuss it with the guy who introduced you to have a full ver... I will make it clear within today for sure.....
[Windows Mobile] tobbbie:
To report the results of my discussions at asusmobile.ru:

Barin is very helpful as long as we discuss about the OSBuilder. When it comes to the basics of Windows Mobile (relocation) however, the thread there is (as expected) not the right one to discuss.

There is also no help expected when it comes to porting old OS (WM2k3) to newer devices as the support of OSBuilder starts with WinCE 5.2 (i.e. WM6 onwards). It seems that only new stuff is good stuff in some heads :-). Seeming to forget that Windows Mobile is a dead end with WM6.5 anyway and if you want to "progress" you have to go back in time... For Cooking WM6+ however the tool works great, so porting old kitchen content is quite easy as the old ("legacy") option.xml are respected. So if you want to try it out:

Dump a ready made ROM (the OS.NB) with OSBuilder. This will create the needed structure (especially on the ROM/XIP parts).

Copy over all your OEM and SYS folder content to the new place, replacing the dumped content.

Run a test-build

Watch the Dump-Map after the relocation - do not expect that OSBuilder will create overlap free slots from the start!

Cleanup the DSM and other stuff that OSBuilder can do.

Don't expect that your settings are permanent over dumps (directories). If you have invested in setting your options once, you need to copy the relevant OSBuilder.osb settings file to your next location manually. Barin claims this is for safety reasons to avoid wrong settings for a new dump - so try with the default settings first and then start to "play".

Regarding relocation OSBuilder does a great job, however it relies on all information to be present that are needed to do this, i.e. per module the .reloc section. Sadly is does not report the details of the relocation job completely - it only reports those modules where actually a relocation was done and is silent about the rest - leaving you in darkness why the hell that relocation went wrong. Just to be clear: other relocators are not doing a better job when it comes to transparency, so it is just no exception (yet I hope).

IF you want "brute force" relocation on your old stuff (even with missing .reloc in your modules), then you must deal with WMRELOC.EXE. This produces overlap free builds in any case (at least all my cases).

The quest to port the old WM2k3 modules continues, I hope to find some helpful brains that are not limited in their views to the dead wall of WM6.5 before them.
[Windows Mobile] -=Barin=-:
tobbbie

Well as i told You at asusmobile thread you try to use custom ROM as a source - but it's not a good practice, because some info can be missed in those ROMs. I cannot satisfy all the requests and expectations.

1. If You use a module without .reloc section, it cannot be remapped, because all fixups are missed. Built-in Reloc engine in full version can cover this situation but only if your module does not break memory model rules.

2. If you use custom ROM another info can be missed - partitions, signatures, etc

3. When i start to write OSBuilder the main target were WM6/6.1/6.5 devices (i've got ASUS P750, HTC Blackstone and HTC Leo, and it works fine with them).

And about "brains that are not limited in their views" - it's better to say limited in time. Sorry, but i'm not interested in ancient devices and i cannot cover all the WinMo versions since WinMo appeared.

And once again - do not use custom roms as sources :)
[Windows Mobile] tobbbie:
Hi Barin, thanks for your continued support. I can well understand all your arguments and I am happy with what you offer. I gave you all my hints on improving the OSBuilder regarding visibility of actions (relocation obviously...) or menus - it is all up to you to care about that or not. I don't want to put too much focus on what OSBuilder cannot do - it works perfectly for my Tornado ROM. I have to investigate further if stepping up to WM6.5 is viable for that device (XIP porting, nk.exe support of WM 6.5 slots - but not as part of this thread either).

I know it is completely up to me to get the problems with old and partial data solved - I know that and I hope to find some people that can help me with that or supply hints and tools for that quest. I definitely want to base my Hurricane ROM on the true original module data form WM2k3 and not on old cooked ROMs - will come back to you once that is done, promised :-)

I just feel that there may not be any more challenges for you after WM 6.5 is the final stage of the story. So if at any time you feel bored - why not look back :-)
[Windows Mobile] AndrewSh:
Do not waste your time... It's definitely not viable.... I hate to remind that but your device has 64 MB SDRAM, 64 MB Flash ROM and OMAP 850, 200 MHz.... besides - 4 memory slots support is not a matter of kinda "patching" or "modifying" original nk.exe....

Anyway -good luck!
[Windows Mobile] tobbbie:
Why should it not be viable? The VOX has the same memory and CPU and there are 2-3 WM6.5 builds available for them - including Multi Language by frauhottelman. Will have to ask there what he did on that part :-)
[Windows Mobile] AndrewSh:
tobbbie, if you occasionally pay attention on my signature - you will see that I developed and released a hell of 6.5 roms for P525 so I really know what I'm talking about

:)
[Windows Mobile] tobbbie:
You can do as much (or little) on the Tornado as is possible for the VOX.

If the memory slot use for WM6.5 native kernels is not transferable (as part of the monolithic nk.exe and not of the linked modules in the XIP) - then WM6.5 would be just a nice optical gimmick for those who like it. I don't care for that - and as Da'G valuable contributions here at XDA outline - the slots belong there.

Does your last remark on your P525 ROMs you made indicate the same? Have there not been any other nk.exe around for the same processor you could build on? This is for sure not the case for OMAP850 - so I have no hope here for me anyway.

We are Off-topic here and should stop that. If you are willing to share your experiences on the P525 work, PM me for that.
[Windows Mobile] HD2Owner:
maybe it's time to let this ancient device "rest in peace". let it go..... ;)

even if it's just a rhodium/topaz/kovsky you will at least get native 6.5 nk.exe... :eek:

even the kovsky lost my interest (since i have a hd2) because it's too slow to handle sense 2.5 for example even if i have a 6.5 nk.exe.
[Windows Mobile] tobbbie:
I know that I am a hopeless case - still stuck with a plain smartphone. I just don't need the fancy GUI and touch stuff - most jobs can be done without and I don't have a brick in my pocket. For those where I need touch I have an Asus P565, but nothing to brag about with that one.

Once touch devices get smaller and lighter (still with good resolution) I may change. Some tempting ones are coming up lately (Moto DEFY or smaller SE or HTC) but none got me hooked yet... And all of them are Android so would mean changing the train.

Hurricane seems really a dead end on all paths I tried - not much to improve there, sadly. Tornado is already exploited almost to the maximum (for my needs), maybe I still squeeze little there with OSBuilder (to keep in the thread) :-)
[Windows Mobile] Nixeus:
Hello my friends,

I'm triyng to use this fabulous kitchen instead of osKitchenZero.

When i dump my stock rom, is there a way to write the number version of each OEM packages ?

It's very hard without this number of version.

For exemple, with the Ext package we have :

Adobe PDF v2.5.1.0.404840.06

So with this folders name it's easy to know which rom have latest OEM in order to create a rom with all the latest oem.

Thanks a lot :)

regards,

Nixeus
[Windows Mobile] kristofpetho:
You can not do that. You either habe to rummage through the rgu of each package, or in OSBuilder you can see the package number in the lower left hand corner.
[Windows Mobile] Nixeus:
:\ aaa :(

Sooo bad :(

Edit: Do you know if it will be available in the next version?

Thanks a lot
[Windows Mobile] kristofpetho:
I think only Barin can answer that... :)
[Windows Mobile] Skrobel:
Hello Nixeus and Kristof,

There is a way to obtain a list of all the packages with their HTC version descriptions. You need to go to the Additional Tools menu (the gear icon on the button bar) and click Packages Versions (HTC).

Then you will see a kind of a report made in rightmost window with a list of all the packages for which the program could retrieve the HTC package version. I guess it's easier than clicking every single package to check it's version in the bottom left corner.

Best Regards

Skrobel
[Windows Mobile] mwalt2:
You can use the EXT's dumped with osKitchen in OSBuilder. airextreme's kitchen leaves the .dsm there and you can use that to rename app.reg to the corresponding .rgu. Change app.dat to initflashfiles.txt, put everything in one directory, and you'll have an OEM that will work with OSBuilder (you need to make sure all files are unicode). I've attached a tool that will do it for you, but it renames dsm/rgu's and the dsm's need to be fixed in OSBuilder before they can be used. I used to do everything this way because it was the easiest path to migrate my kitchen to OSBuilder.
[Windows Mobile] Nixeus:
:) :) :)

Thanks a lot :)

I will try !!
[Windows Mobile] Nixeus:
Hello,

Yes i know this tips but there is no way to "write" the HTC version on the folder name of each oem :\

It's sad, in addition it will be very simple for Barin to add this options.
[Windows Mobile] ultrashot:
I'll post auto oemrenamer as soon as i get to pc...

Here it is. Place oemrenamer.exe to Dump\OEM\ folder and run... Backup your dump first if there is anything to backup.
[Windows Mobile] Nixeus:
Why is the goal of oemrenamer please ?
[Windows Mobile] AndrewSh:
ultrashot, не, ну блин, это пипец! :)

"The goal" of oemrenamer is to RENAME OEM! Rename to your so wanted osKitchen style.
[Windows Mobile] Nixeus:
It's note my so wanted oskitchen style, it's just that it's more easy to having the HTC version number in the folder name.

In addition, i don't knwo how using oemrenamer in order to rename my folder automatically with the htc version number :\
[Windows Mobile] ultrashot:
video guide

i don't think it is hard to understand even without guide.
[Windows Mobile] Nixeus:
Thanks a lot, i will see them :)

Do you know where OsBuilder get the htc version of the OEM ?

It's written on the rgu, but is this version infos on the dsm ?

I will create a program on c# in order to rename the oem with the version number if i found where get this htc version number.

Thanks for your help,

regards,

Nixeus
[Windows Mobile] ultrashot:
Do you really like reinventing the wheel? What you posted is an exact purpose of oemrenamer.

dsm doesn't contain htc version, look at rgu.
[Windows Mobile] Nixeus:
Sorry for my mistake !

OemRenamer is perfect !

I can try this kitchen now :)

Thanks !!! :)
[Windows Mobile] pupakota:
..maybe it is stupid question, but, why every option that I need(urgently) gives me "not available in public version" message, lol...

Is this normal?

Sorry for asking, but i just wanted to migrate(to consider its value, that i cannot verify seeing "public version" msg at certain functions) from old tools that had no problems, or '"public" versions, you know.

Fabulous kitchen, btw. lzx packing is INCREDIBLE quick here, wow.

upd: ...can someone explain method for reusing .tpl i have(asus)? Do i need to recreate tpl each time i want to make rom correction?? How to set kitchen to use one i have already...?