yashsingh1/xdaforums huggingface dataset:
[Windows Mobile] CRACING:
Yeah had this issue too when I first shifted to OSB. Well, its not the actually an issue. :p

OK spent many hours and finally resolved. Its with attributes of those html files.

Quick note:

In OSK, it writes attributes to files while building ROM from its own attributes list command line.

In OSB, it writes attributes to files while building ROM from DSM attributes settings (In the package).

So all you have to do is, set +s flag in the DSM present in messaging enhancement package.

But I guessed why shouldn't there be other issues with attributes on different format files.

So what I have done is. A bat command which resets all the files attributes and then in OSB app, DSM autocorrection (All DSM files -> In EXT only -> Set H & S flags in DSM records according to modules & files in package folder). This is what I do every time when I build a ROM. :)

BTW; Like AndrewSh and tobbbie, build order (packages cif and sof) is an advanced option and should never forgot to check before building a ROM.

But atleast the issue you have isn't related to this. :)

Thanks...

Best Regards
[Windows Mobile] -=Barin=-:
OSBuilder V1.2.157 with advanced compression options for XIP objects is ready
[Windows Mobile] AndrewSh:
OS Builder V1.2.157 FULL (20.09.2011) Changelog

1. Added possibility to convert files to modules for WP7 files

2. To FileInfo menu - added possibility to convert file to module at a place (replacing file by the module or saving module to any folder/disk and leaving the file untouched).

3. Added possibility to select separate packages in XIP (drag and drop into the tree to select the package). This feature is recommended in case if XIP is assembled from packages in your ROM folder, or the packages from ROM folder are used as your OEM XIP

4. Added possibility to compress separate XIP objects. That feature reduces the amount of Physical Space and thus it can free-up some RAM. To specify that you want to compress an object, you must set up Flag C (full file or module compression) or Flag R (compression of all sections of module except those containing code) in DSM Rebuilder/Files and Modules tab.

Setting the Flag C for the filesys.exe module – works without any problems

Setting up C flag to the other modules can cause un-bootable ROM.

Example for LEO (tested on several devices):

Do not even touch dlls marked with Flag K

----------MSXIPKernel----------
For all files - Flag С
Modules:
coredll,dll - Flag R
device.exe - don’t touch
filesys.exe - Flag C
imgfs.dll - don’t touch
initvmmap.exe - don’t touch
regenum.dll - don’t touch
the rest of dll - Flag R

----------OEMXIPKernel----------
For all files - Flag С
Modules:
nk.exe - don’t you even think about touching it!!!!!!!!!!
cecompr.dll - don’t touch
QCBPM.dll - don’t touch
rpc_pmem_client.dll - don’t touch
wce_pmem.dll - don’t touch
the rest of dll - Flag R

----------WinCENLS_WWE----------
wince.nls - Flag С

With that above mentioned settings and squeezing nk RW sections in RAM – about 0,5 Mb of Program Memory (RAM) was added.
[Windows Mobile] tobbbie:
Great - one more thing clears up for a half-noob that I am :-)

These flags in the DSM steer the individual files/modules compression - no matter if they are located in XIP or IMGFS. Of course the build process must honor these settings.

Later when booting up the OS must have the cecompr.dll ready and operable when accessing these files/modules first time - so no wonder that nk.exe is no candidate for any compression.

So far I thought simply that all XIP is uncompressed and all IMGFS is compressed. Need to walk through my IMGFS DSMs to see if there are any uncompressed left!

Edit: I did look at the \SYS\OS\ .dsm and none of the files has any R or C flag set - so I think that there is a hierarchical way to steer filesystem compression.
[Windows Mobile] Nixeus:
Thanks a lot for this release.

I don't understand what are the advantage to set Flag C in XIP.

The files will be compressed, but they will be decompressed in ram no ?

So, where is the gain ?

Thanks a lot :)
[Windows Mobile] tobbbie:
Don't see that either at first glance - obvious gain is that your XIP partition will get smaller - a value by itself anyway :-)

From the Release Notes is reads:

Probably this is the potential gain here? This is deep under the hood of the machine here - no clue what is going.
[Windows Mobile] ai6908:
I thought it should be the attributes and I was going to play with it to see if it fixes it. Thanks for the tips cracing...:D
[Windows Mobile] CRACING:
It is, no doubt. ;)

Just set +s flag in message enh DSM for those html files and it should work.

You're welcome...

Best Regards
[Windows Mobile] Nixeus:
Thanks a lot, i will play with it :)

Have you any new plans about new feature of the kitchen :D ?

best regards,

Nixeus
[Windows Mobile] -=Barin=-:
OSBuilder V1.3.163 is ready
[Windows Mobile] AndrewSh:
Changelog for OS Builder V1.3.163 FULL (29.09.2011) - supports WP7 ROM dumping

1.	The first step to full WP7 rom assembling support - Added ability to dump HTC WP7 ROM (either with the FLPART structure, or with _wmstore structure - like Eternity or Omega roms).

Advanced Dump Tool also supports extracting sections, packages, modules and files from WP7 (HTC) ROM file.

WARNING! DO NOT ATTEMPT TO ASSEMBLE WP7 ROM WITH OSBuilder OR TO USE TPL Builder TO CREATE A WP7 TEMPLATE!!!

Special thanks to: AnDim, AndrewSh, Ultrashot, xb0xmod (xda)

P.S. (Just to clarify) - special thanx to AndrewSh does not mean that I thank myself. It's just the translation of original changelog from Barin :)
[Windows Mobile] HD2Owner:
thanks a lot for working on wp7 support barin. highly appreciated.
[Windows Mobile] itje:
Looks like a great tool, and its great to see the development on wp7 is speeding up.

But would be cool to have some basic setup tricks with wp7 for us "os.builder noobs" :-)
[Windows Mobile] caliban2:
well, guess you're one step too far ahead. :)

since all you can do is dump wp7-roms for now, there's no big setup. run osbuilder, switch to "mode: dump-tool" at upper right and the rest is self-explanatory.

if you still have your hd2 and want to do some apprentice pieces with osbuilder (always assuming the basics will stay the same with wp7), get the kitchen of hd2owner at post1 OR get ultrashot's kitchen here.

that should clear most things up for you already, nothing better than a full kitchen as a start. (who am i telling this anyway?! ^^)

take a look at how to set build-order via packages.sof/.cif, no more sorting via filename. and dsm's have actually a meaning now. changelogs at post 4 are very informative and at least show you what to look at and search for.
[Windows Mobile] Nixeus:
Thanks a lot for this release,

Is there any news for WM6.X ?

Thanks :)
[Windows Mobile] -=Barin=-:
Do you see them in changelog? :p
[Windows Mobile] ct_moi:
Hi,

Thanks for the new version, playing everyday day to find the good way.

How can I do to have the exe files working when I'm with KernelFlag=1 and pp=0 ?

Thanks -
[Windows Mobile] CRACING:
If anybody saw my post replied to a previous version of osBuilder. I was smelling the taste of WP7 being cooked on osBuilder. Now its become for really on every releases from Barin.

Awesome dude, keep it up!!! :D

Thanks...

Best Regards
[Windows Mobile] ultrashot:
They are working indeed. With KF=0 everything should totally correct. With KF=1 some dlls might stop loading, so "emulated" mode is the only solution: add "*" line to demand paging list.
[Windows Mobile] ct_moi:
I'll do that as I can't find a solution, get some exe not working like leocpuspeed, NuePerformance, MyStopWatch,

volume also is the old wm and on music tab I've an error: "audioManager_eng is not a valid ppc application".

With KF=0 all is ok, so will look what to add at the paging list.

Thanks -
[Windows Mobile] Nixeus:
Nooooooooooo ! :D
[Windows Mobile] WojtasXda:
hi!

I wanted to do DUMP wp7 ROM and at IMGFS receives a message:

Reading IMGFS:

Arithmetic operation resulted in an overflow.

What is wrong?

part4.bin swapped for part4.nb

---------------------------------------------------------------

Another problem :<

just installed the new version and I have problems: <

XIP rebuilder shows error "Object reference not set to an instance of an object."

I had earlier version OSBuilder1.2.107-LE and there was this problem

Please help ...
[Windows Mobile] AndrewSh:
What kind of rom? Stock one or someone's custom? Define exact name.

Would be also nice to know - what phone model are you trying to cook for. And what was taken as a source XIP? We have also one complain (the same) from a user at Russian OsBuilder thread (this user is cooking for TouchHD) but Barin was not able to simulate this issue to debug it.

To all (for the future)

If you have some issues with OsBuilder and expect kinda help here:

1. Make sure that most recent .Net Framework 4 is installed on your PC. Try to avoid long and strange path to the OsBuilder install folder and kitchen folder

2. Define the exact Error Message, returned by the program

3. Define the phone model

4. Define the source SYS, XIP and OEM exact names (what build # was used for SYS-XIP and what stock rom was used for OEM-EXT)

5. Attach you build logs (for both XIP and rom)

P.S. To wojtas_p5n - We figured out the issue at Russian forum: the guy managed to set OsBuilder to delete the following

Deleting package LangDB Ok
Deleting package MSXIPKernel Ok
Deleting package MSXIPKernelLTK Ok
Deleting package OEMXIPKernel Ok

After that smart operation XIP rebuilder just goes crazy :)

So - to help you - we need your XIP Build log attached here. Maybe we also will find something funny inside it...
[Windows Mobile] itje:
always a step ahead :-p

Nah I was just thinking of the dumping procedure...as I got a unknown format error when dumping os.nb.

I was dumping Omega_HTC_Europe_1.08.401.03, and it was fine dumping nbh.

ROM file is signed
DEVICE: PD2910000
CID:
Version: 4.05.401.02
Lang: WWE

Data chunk: 0x10000

[Sections]
0x0300 offset=0x00002200 length=0x01860000 - Radio
0x0200 offset=0x01862200 length=0x00100000 - SPL
0x0400 offset=0x01962200 length=0x132B53D7 - OS
0x0380 offset=0x14C175D7 length=0x0000004C - Radiocust
0x0830 offset=0x14C17623 length=0x00011CE0 - Unknown
0x0831 offset=0x14C29303 length=0x00011A38 - Unknown
0x0832 offset=0x14C3AD3B length=0x00011A50 - Unknown
0x0833 offset=0x14C4C78B length=0x00007100 - Unknown
0x0834 offset=0x14C5388B length=0x00007100 - Unknown

Extracting OS...Ok

Converting NB to PAYLOAD - Unknown file format

Im sure its pretty easy to figure it out, but I got to much on my schedule to do the research this month, so I was hoping for a shortcut :eek: :o

But I do my cooking and all with use of bat files for now, so it's no big deal :p
[Windows Mobile] -=Barin=-:
Did you use THE LAST version of OSBuilder?

Omega's dump log is attached...
[Windows Mobile] WojtasXda:
Hi !

Thanks for reply :)

I sent My Kitchen to the server. Personally you can diagnose what is happening.

when it comes to WP7

I tried to open this ROM

ps. Now I know why I could not open this ROM, do not read that at the present moment there is support for all wp7 devices
[Windows Mobile] AndrewSh:
WP7 support has nothing common with the reason why you could not deal with the rom you mentioned! OsBuilder's features for 6.5 are not replaced by features for WP7 - new features just ADDED.

The reason is that you CAN NOT use someone's custom rom as an OEM and EXT source. You should use ONLY stock rom for your device to make OEM, ROM and EXT folders.
[Windows Mobile] WojtasXda:
WP7 and 6.5 are two separate problems ...

WP7 by the way I wanted to open

My main problem is that I can not build a ROM

Building the ROM on the OSB 1.2.107-LE goes quickly and efficiently, and here I do not know why I have problems: <
[Windows Mobile] -=Barin=-:
The part of changelog:

Added ability to dump

HTC WP7 ROM

nobody wants to read...
[Windows Mobile] MS Master:
Hi HD2O,

will there be an update of this kitchen in future with "XPH wp7 mango compression method" support?
[Windows Mobile] AndrewSh:
It's kinda joke?

Three last public releases of OsBuilder ARE with XPH support! Since September 15 release.

And devices supported are defined in changelog. Only the devices with CPU able to deal with ARM v7 instructions.

No-one is going to dismiss that support.
[Windows Mobile] HD2Owner:
patch 1.16 with xph integration added to hd2 template kitchen.
[Windows Mobile] HD2Owner:
Some findings and resulting basic answer regarding your device..
[Windows Mobile] AndrewSh:
HD2Owner +100000000000000000000000000000000000000000000000000000000
[Windows Mobile] tobbbie:
So the reply depends on the value and age of the device? Settings and their meaning also depends on that? Only HD2 owners (bg) are worth receiving replies here?

Oh well, you are really disappointing me here - both of you. Making fun is ok as long as you are supplying some value along with it - which you do not. Not the style I am used to at xda-developers so far.

Anyone out there that can reply to the questions?
[Windows Mobile] WojtasXda:
finally someone help me?

Someone solved the problem with the My 6.5 ROM?

I would like to work on the latest version :((((
[Windows Mobile] tobbbie:
Did you ever succeed to rebuild the XIP with any version of OS Builder? You can as well use the XIP unchanged - so you may get further in the build process this way. Set the "While assembling use XIP" in the "Build Dump and ROM" settings to "File XIP.BIN in ROM folder" - this will use the XIP unchanged.

OS Builder had some exceptions not handled in the past as well, so for some basic things it just silently closed. The risk of this to happen increases when you are using an already cooked ROM as a base. There are many options to sabotage a cooked ROM from easy reuse - sadly, so this is why the usual recommendation is to use only stock ROMs as a base.

Check if the boot.rgu is not empty and if the last line in the file is an empty line. In the meantime this should have been caught by OSB however as there is an option in the Build Tab to "check RGU Syntax automatically".

If you really want to rebuild the XIP, then play around with the settings in the XIP tab and list the .\temp\xiplog.txt how far it could get. You can start the XIP part of the build process easily by using "Additional Tools -> port XIP". To start with that select in the XIP settings "Rebuild" and then "packages in ROM\XIP folder" then un-set all options except the "Do not move RAM start..."

Good luck...
[Windows Mobile] Farmer Ted:
The rgu's and dsm's are included in rom so that you can dump the rom and reconstruct all the packages. The rgu's can be helpful if you jack up your registry, and need to find the original settings in a pinch. I personally like cooking unprotected roms-it protects your kitchen. If you have the .nbh stored safely, but something happens to you kitchen, you can easily reconstruct it. The downside is a few hundred extra rom files and maybe 3-4 MB of rom memory consumed.

DSM's list all the files in each package, and they have flags and certificates as well.
[Windows Mobile] -=Barin=-:
The full answer will take a few pages:)

i'll try to answer about compressed objects in XIP.

You know, that address space has few areas. All XIP objects allocate physical space at first (physFirst-physLat), then kernel RAM space follows (RAMStart-RAMFree) and then system RAM space (RAMFree-RAMEnd).

When some objects are compressed, the physical space upper bound can be decreased (physLast). And then we can decrease RAMStart value and mowe RW sections of Kernel modules upper also. But there is one ****ty point - address of uninitialized data sections in Kernel RAM space MUST be aligned to 64k.

Anyway if RAMStart delta is more than 64К we can move uninitialized data sections.

And then we can also decrease RAMFree bound and gain more system memory as a result (RAMEnd stays unchanged)

You can check all these values in XIP map
[Windows Mobile] CRACING:
Hello,

I will try to help you as best I can. If I'm wrong in some cases, please do correct. :)

You may already know this, rgu/reg contains registry entries and the same data is written to two files known as default.hv and user.hv while building.

When done, these rgu are no longer kept in ROM or not placed. Exactly same as DSMs. Especially those ROM cooked in 3rd partly kitchens.

No idea where you saw rgu/reg files present in custom ROMs. I never saw except stock/official ROMs.

The purpose of keeping DSMs and RGU is necessary for image update system also. Check this out in case you haven't already.

If you lookout deeply in DSM files, you will know what really it contains. Like I said above, its very necessary for image update system also.

Don't get me wrong but there are many things to include in osbuilder but if they do, what is left for us to do? ;)

This kitchen is advanced kitchen so most of things have to be done manually.

I have made a bat file which removes necessary files from the SYS and an another bat to fix attributes (later in OSB, I will fix attributes flags in DSMs).

Ignore them. They are just kidding. I appreciate you being still cooking on such a old device but getting a new one would be better. Not for us but for you itself. :)

Those kilobyes difference you are finding are just in old devices. I too came across old devices and was also cared but now on newer devices, we don't.

Most of ppl here use newer device and when they see such queries, they just ignore or be kidding. :)

Thanks...

Best Regards
[Windows Mobile] tobbbie:
I remember that thread by Da_G but finally it is just an option - never used so far, or? So my proposal to have the fw update packages to be removed as well would go inline with that potential saving case.

The cooked ROMs I dealt with (you know this old stuff...) did not have the chefs need to brag about how good they are and sabotage others from what they believe is only their own merit.

There are no protected Tornado ROMs and the older (Hurricane and Typhoon) were not even cooked with normal batch kitchen but seem to have patched the original builds. I have setup simple batch kitchen with WM6 (Hurricane) and WM65 (Typhoon - based on Aleuts ROM) for everyone to cook further.

Could I get the DSM and RGU removed during the build process - so after all the registry build stuff is done but before imgfs is created? It seems that the .\temp directory does not contain all files but only some. Even after unchecking the "delete temp in background" not the whole content is part of the \temp folder

I do ignore them for such comments - it is just disappointing to get only such feedback from them while I know that they could also contribute something useful with their background. At least barin has shed some light on the XIP compression gaining RAM :-)!

The little gain to get is not negligible for these old devices - especially my all time favorite the Tornado. There has not come any later device that suits all I need for a day-to-day use:

~100g weight

sturdy and sized to carry in the back pocket of your jeans (including sitting in a car with that setup)

WLAN

Audio quality that is acceptable in frequency range and noise level. I had so much bull**** devices tested that I decided to give up on any other than HTC or where I know from GMSArena that data are ok.

Micro SD capable

The first 2 items rule out all touchscreen flat bricks - and for item 4 I had tested and discarded: BenQ E72 (noise), LG KS20, Asus P565 and HP Ipaq Voice messenger (frequency response).

SE Ray comes close currently - but Android - so well, still stuck :-)

---------- Post added at 04:50 PM ---------- Previous post was at 04:45 PM ----------

Thanks Barin - I checked the xip map for the comparison and have seen the effects of the various settings this way before reporting. Great to have such a sophisticated tool to tweak the bits off the XIP and elsewhere.

Are there other reasons to keep FW-Update, RGU and DSM on the device except the obvious reason to prevent too much protection and allow (in theory) later package replacement?
[Windows Mobile] -=Barin=-:
You need to keep just one module in FWUPDATE - packageinfoapi.dll - it's used by other packages.

RGUs are useless if you do not plan to use ImageUpdate.

If you want to exclude dsm and rgu automatically and save the order of provxml execution just select "Merge packages" option in toolbar.
[Windows Mobile] CRACING:
I miss that development as well as Da_g. It was a great thing.

Like Barin said, you can remove fwupdate package(s) but just keep that single dll. It is needed or else you will have troubles.

Yes earlier, kitchens weren't removing DSMs and RGUs so the ROM would be extractable. After bepe released platform rebuilder, it used to exclude the DSMs and RGUs. The same tool was used on different kitchens including oskitchen.

But on osBuilder you can select whether DSMs and RGUs should be include or excluded.

Yes its possible, just tick Merge packages option in osbuilder settings. :)

As of temp dir, I have noticed not all files are moved to temp but I think it takes from the original source itself (ext, oem, sys) to save building time and/or space. Especially files; Modules are being moved. May be for relocation.

Thanks...

Best Regards
[Windows Mobile] ultrashot:
Exactly. Also all files from r/w sharing, demand paging, reversmod, recmod lists are being copied there.
[Windows Mobile] tobbbie:
Oops - I compared the gwes.exe at the original place and in temp and did not notice a difference (binary compare all files). What is the trick with excluding gwes from demand paging?! Is that not part of section flags in the imageinfo.bin files?

---------- Post added at 09:18 PM ---------- Previous post was at 09:13 PM ----------

Oh well - bepes platform rebuilder never worked for smartphones - so I missed that episode in ROM cooking and smartphone ROMs are usually not protected.

As mentioned in my initial post, the merge packages will save a lot of space by summing up all single DSM and RGU into just one - so saving the many individual signatures in each single DSM - but still the one merged DSM is there as well as the one merged RGU. THAT could as well be saved and there is no option to do so in OSB.

---------- Post added at 09:23 PM ---------- Previous post was at 09:18 PM ----------

Is there any option or method to actually USE that design of fwupdate? I have never seen any indication that this was ever used anywhere - so why keep it? I have cut out the ULDR already from the ROM, so reading through Da_G's post the fwupdate would not be able to work anyway. Getting rid of the fwupdate packages (except that one dll mentioned) is the logical consequence then - obviously! One more reason possibly to get a tweak checkbox in OSB, posssibly linked to the ULDR activities.

I checked the backward dependencies on the FWUpdate package and it lists outside the FWUdate package: SYS\OS\dw.exe and SYS\SHELL\ coldinit.exe and syncmgr.dll. Great to have this backward dependency check in OSB - another field to safeguard package removal :-)

I know about the merge option - but this is not removing the merged DSM and the merged RGU. But wait:

Are you telling that the DSM is defining the sequence of provxml execution? If so then THIS is the missing info for me that justifies their presence on the device!

Edit: Just re-read Da_G's thread and I noticed that the shadow order is handling RGU sequence treatment while assembling the registry hives but also defines the sequence of the provxml treatment on the device later. A good reasons to keep the DSM (at least the merged one).