yashsingh1/xdaforums huggingface dataset:
[Windows Mobile] mac_es:
Thanks for the info...

The HD's wm6.5 nk.exe works but if the rom has many modules it doesn't work well. I try to keep modules in the SYS, manila, dshow, and little more

I also cook for myself. As I said before I'm migrating the kitchen and I want to check that everything goes smoothly. So what I'm doing is:

generate a rom whith evk and dump it

generate a rom whith osbuilder and dump it

use BeyondCompare to check for orphan files, and the reloc file parts were popping up continuosly

Yeah, 23 kb (If I remember correctly). Why HTC is leaving such gap? :confused:

OSKitchen. I tried it, but i got problems whith build order, files not being copying correctly... and looking around I come to OsBuilder. :D
[Windows Mobile] _Madmatt:
Extendir?

Someone who knows how I can cook Extendir in my ROM using OSBuilder? In the Extendir thread they say I should add it in my XIP and so on. So, I added the folder of Extendir to my XIP packages folder and it builds. I believe it is really in my XIP as it is displayed in the XipMap.txt file. But in the Extendir thread they also say that I should edit boot.hv to let the device use the patch in boot time. Does OSBuilder do this autmatically or should I do it on my own? And how should I do it?

Thanks for helping!

MadMatt
[Windows Mobile] Farmer Ted:
If it's in the xipmap, then it's in xip. You can edit the boot.rgu with the boot.rgu editor or by going into the oemxipkernel folder. Back it up before you screw with it, though. As a tip, practically all the important settings are set in the boot.rgu, including all file system settings/caches (datacache; replstorcachesize; dirstoexclude...). If you're setting your file system caches with a regular .rgu, you're wasting your time; it doesn't work.
[Windows Mobile] _Madmatt:
Okay, my boot.rgu is OK. But maybe it's because I use v1.05 instead of 1.08? The problem with 1.08 is that it is not in S000, S001, ... and Imageinfo.bin and .txt format. That's why I use 1.05. Do you maybe know how I can convert the 1.08 DLL and try with that newer version? Or is it really because of boot.hv (as described in the thread of Extendir)?
[Windows Mobile] Farmer Ted:
Converting files to modules is easy; just get reversemod.exe, and drag the file onto it. Or, use the kitchen to automatically do it for you. There's a list of files to convert to modules in the kitchen (I have around a hundred set for conversion). I suppose it will work for a xip file to module conversion.
[Windows Mobile] _Madmatt:
Thanks, the conversion already succeeded. Now building the NBH for flasing :D

EDIT: Now I get this while building XIP

Allocating physical space...

Not enough physical space for boot.hv
[Windows Mobile] Farmer Ted:
I had that as well; I think there's a box in xip settings you need to click, but can't remember it off the top of my head.
[Windows Mobile] _Madmatt:
This are my current XIP options ;)

See image ;)
[Windows Mobile] mwalt2:
Check the 'stripe reloc sections' box. That free's up slot0 I think (maybe is supposed to be 'strip').
[Windows Mobile] alexander555:
Change package file target directories?

Hi, can i change the target directories for packages. I've seen there are a lot of files in the main /windows directory like images, manila files and leo.db...

I thinks it wolud be better If these files are not all in the main directory because this need a lot time for access this huge directory structure.
[Windows Mobile] WallyGator:
Maybe You should check Extendir?
[Windows Mobile] Farmer Ted:
The windows directory is the rom; every single file cooked into the rom appears in \windows. The trade-off for using extendir is a loss of storage space. Personally, I didn't find it to be worth it, but then again, I have a pretty light rom, and only have a little over 2000 rom files.
[Windows Mobile] Farmer Ted:
Uncheck the 'do not remove ramstart...' box. That's why the xip isn't resizing for the added file.
[Windows Mobile] alexander555:
I think the count of files can be reduced if you kick out unneccessary files (b.t.w. I'm not be able to be a Chef.. I need more time to understand how work the build process an how can I change the .reg and package files)

What i meant was if you get acces to an directory with a lot of files this need more time. So I think its better if you cluster your files in directories (not all in the main directory)
[Windows Mobile] Skrobel:
Moving files to different folders than \Windows\ will not reduce the number of files. Please note that every file that is moved using "initflashfiles.dat" leaves a copy in \Windows\ folder as well.

Jackos, one of the chefs around xda, told me once that this is not actually a

copy

of the file. But I don't clearly understand thich mechanism. The only thing I know is that after clean flash all the files that should be placed in \Program Files\ or Start Menu are visible also in \Windows\ folder. And moving more files to different subdirectories will not improve the time necessary to show the contents of \Windows\.
[Windows Mobile] _Madmatt:
That's why I want Extendir (but it doesn't work...). I've now cooked the Extendir.dll in my XIP and the reg tweaks are done, but Manila doesn't start (and the files are in \Extendir\WinDir\Manila)... :(

Using HTC Photon (HD mini) and Extendir 1.08
[Windows Mobile] Farmer Ted:
Did you set the right order for extendir in the boot.rgu, and change the order of the other file system filters? Extendir can be a bit buggy, and it kills file system replication.
[Windows Mobile] _Madmatt:
I have set the registry values that are indicated in the thread ;) But somehow it doesn't work...:(
[Windows Mobile] Farmer Ted:
Are you using extendir as a file or module? I think you may need to leave it as a file.

They're actual copies of the files, and not virtual copies, or anything like that. It's real easy to prove if you don't believe it. Check the system memory of you device, delete a large file that was copied by initflashfiles.dat, then check the memory again. It goes up by the amount of memory cleared when you delete the file.

Initflashfiles (or provxml's) is not the way to go to move files around. First, I think you're better off leaving as many files in rom as possible. It's usually pretty easy to move a program from program files to windows. You save memory, and you can also get the added benefit of converting files to modules if you have a 6.5 kernel. Most applications work fine in \windows, although registry keys may need to be changed to reflect the new location, as well as shortcut paths. Settings files can be tricky, as they generally should not be read-only, so you need to figure out a way (normally quite easy) to get them into window w/o being read-only (I usually stick files like that in a zip file, then unzip it to windows, or I use a backup/restore mortscript to move them to my sd card and back to windows after a flash). So, for me the first goal was to get as few files as possible outside of rom. The only apps I have in program files are resco keyboard and resco radio. The keyboard has to be in program files (I guess some file locations are hard coded, it doesn't work otherwise), and I have a few other resco apps, and there are conflicts with the skin files if i have the radio in windows. Other than that, I have dozens of programs located in rom, and most of them have all files converted to modules, which makes them load faster. Saving memory, having a faster first boot time, and getting faster load times is a win-win-win situation for me.

To move files, I use mortscripts to unzip folders to various locations. For instance, I move the office templates to my documents that way. The compressed files save space and in rom (as well as file count), and the unzip is fast. I also create all my shortcuts with a mortscript (using CreateShortCut and WriteFile commands). It's fast, and I only have a half dozen or so shortcuts in rom, instead of maybe 150, which I would have if I used initflashfiles.dat to create my start menu. I only use initflashfiles.dat to create directories and to move a single shortcut to the startup folder to run my customization queue. Using it for more than that is a waste, imo.
[Windows Mobile] Jackos:
Och, you misunderstood me somehow :)

It's exactly like Farmer Ted wrote.
[Windows Mobile] Skrobel:
Hmmm... If you say so... Either way I believe in what I see, so from this point of view Farmer Ted is right! :)

But I wonder if there is really so big difference in performance/memory management after spending so many hours on optimizing every single program package to prevent loading to Program Files.

On the other hand there's always a question of files vs. modules. The more modules you have the more slot 60 and possibly 0 you occupy. I don't fully understand the ways of Virtual Memory but as stated by Da_G in here:

http://xdaforums.com/showpost.php?p=4268137&postcount=2

we should avoid overshooting the ROM with too many modules (even though programs may load faster this way).

Could you guys put some light also here?
[Windows Mobile] Jackos:
It's a question of good balance. A good ROM means a balanced ROM.

Just try to keep those both slots free and you will be just fine. Nothing tricky there.

About deleting those copied files: I recommend that every custom created package does not use initflashfiles.dat. I use this file only to create shortcuts. As Farmer Ted mentioned: It's a waste.

IMHO using Mortscript to copy unzipped files is not worth the effort. Unless you're really copying something big or an extreme amount of files. Just the ConnectionSetupDB contains over 900 files, so whatever. This makes the file system slow, och yeah it does... For uckin` sake it does. Not to mention Sense... Another 2K files. Pff -.-

PS I'm totally exhausted right now, hopefully I didn;t write something stupid :) Good night! :(
[Windows Mobile] Farmer Ted:
It's next to impossible to overload slots 60 and 61 with modules (I've tried, lol). Just check the build map, and make sure there are no Low slot 0 modules, and also look to see how much space is occupied by the High slot 0 modules. I usually have ~6 MB in the high slot 0 modules, which has been fine for me. In a few cases, I had 8 MB, and that was a little too much. There were a couple of dll's that had too much read-write code, so I left them as files.

Here's the main thing: if the dll is loaded all the time (like an oem driver), then you really, really want to leave it as a module (or convert it from file to module). The code is going to be loaded into slot 0 high no matter what, but when it's cooked in as a module the borders as 4 kb per dll, whereas they are 64 kb per file. So, if you have 30 oem drivers that are files, and each has a 4 kb read-write section, when they load they take up 30*64 Kb of virtual memory in each slot (not so good), whereas they would only take up 30*4 kb of virtual memory as modules. I know that may not make much sense, but just look at the buildmap, and you'll see that each dll is loaded one right on top of the other, with no gaps or wasted VM. But I'm pretty darn sure that you get gaps when files are loaded; you can see this using devhealth.exe, and dumping your ram profile with it.

If you're talking about a dll that's only used by an app you use once in a while, then you may not want it converted to a module, so VM isn't being used all the time. But if it only uses 4 or 8 kb of VM, then I'd personally rather have it as a module, so the app will load faster. If it's 512 kb, or something like that, I'd leave it as a file. If you look at the module info in a package (open the dsm, then right click on the module and select module info), you can guesstimate the read-write size; it's usually S002 (I think, not really sure why, though). It's tagged as read_write, or something like that.

This kitchen is really awesome because of the control it gives you over modules, and because it gives the build map. It's really easy to know if something is going to cause problems, if you know what to look for in the map. I do (sort of), mostly by trial and error (lots of the latter, lol).
[Windows Mobile] illi:
Hi Farmer Ted

Being a nooby cook, I would appreciate it very, very much if you can have a look at my DumpMap.txt. Of course, if you have the time:D Please see if I have optimized my cooking and any good advise you can share.

Thank you very much.
[Windows Mobile] Skrobel:
Thanks Ted, you sure put more and more light to my stupid brain ;)

But you are not completely right about overloading slots 60 and 61. I believe this has much to do with the device and ROM version. When I dumped a Rhodium stock ROM, the number of modules was over 630 (or even more). And reported free memory in slot 0 (it's really an awesome kitchen that it even calculates and shows that) was like 17 MB. I managed to make it about 25 MB by getting rid of some of the bigger modules but for instance Jackos wrote in his thread once that he uses only slot 1 and 61, for my understanding the slot 0 and 60 are totally free.

Additionally there are over 30 modules marked L in the slot0 map. Didn't touch them yet, but if you say there shouldn't be so many of them, perhaps I should take a closer look on this. The memory usage and - so called - memory leak in Rhodium Manila ROMs are right now my main concern if about cooking. Buuut there are so many questions and so little answers from experienced chefs that I use any opportunity to spill out my doubts... ;)
[Windows Mobile] Farmer Ted:
If you split the L modules, it frees up all the space you need in slot 0. L modules load all of their code in slot 0 unless you split them. When you split them, the read-only code goes into 1, 61, or 60, which is where you want it.
[Windows Mobile] Skrobel:
Is it enough to check a "Split L modules" checkbox or I have to change the individual L flag into Advanced Options -> Find all modules with L flag (I don't remember correct naming).
[Windows Mobile] Farmer Ted:
I think you're ok just checking the box to split the modules. I usually run the dsm auto-corrector before a build (if I've edited rgu's, or something like that); I'm not sure which of the boxes to check for the L flag options (I think I usually check both, which may be kind of stupid).

What I wonder is if PRB has issues with the netconfig.dll (I think that's what it's called) module because it needs to be loaded Low. In know that there are a few HTC modules that need to be recmod'd if you use PRB, or else the rom won't boot. My guess is that PRB basically splits all L modules, because it ignores dsm files during module allocation, and so you run into trouble if there are one or two modules that have to go Low. So, you might run into issues if you have some of the newer HTC packages.
[Windows Mobile] Farmer Ted:
It looks fine to me; you've got a couple modules loaded low (OemExtDll.dll and asyncmac.dll), but you have ~26 MB free in slot 0, which is fine imo. I think you could probably remove the L flag from asyncmac (or do the L split option), but I don't know about the other module. It probably won't matter much either way. You have barely anything in slot 60, though (maybe 2 MB), so you can always load plenty of modules there.
[Windows Mobile] Skrobel:
Ok, I'm home right now so I could check which option I had in mind.

When I'm in my ROMs folder there the "Additional Tools" (the Settings icon on the toolbar) and there you can find a menu:

"Find modules with Vbase in slot0 or with L flag in dsm"

And there appears a whole list of modules with their paths and Vbase address. For each of them I can use a context menu and there is a "module info" item, where all the advanced memory-wise information are shown (I wish I'd understand any of it), or "Clear flag L". Perhaps instead of splitting so many modules into parts, it's better to clear the L flag for modules which definitely don't have to land in slot 0 (I guess most of them)...
[Windows Mobile] Farmer Ted:
I think you can probably do that; if there are a few modules that need the L flag, then you can leave them. There's also an option in settings for putting modules on a Slot 0 list, which does the same thing (I suppose).
[Windows Mobile] illi:
I'll work out your suggestions and see how it goes. Thank you very much for your inputs.;)

EDIT: So, should Slot 0 have more memory or less?
[Windows Mobile] Skrobel:
As for my understanding we should keep Slot0 as free as possible because all the processes launched during normal work of the system are attempted to load into Slot0 in the first place.

And it's said that when the slot0 is filled up with unnecessary data, it will give the user "Out of memory" errors even though there is still much of free physical memory left.

That's what I concluded from Da_G's tutorial and from what Jackos told and wrote me.
[Windows Mobile] AndrewSh:
You can see the list of modules with flag L via OsBuilder settings. These modules SHOULD be in slot0. The trick to empty Slot0 is only splitting L modules, not kinda recmodding etc....

About free space - for Leo - about 26 Mb free in Slot0 is quite OK.

Here is what MSDN says 'bout flags in general and L in particular
[Windows Mobile] AndrewSh:
OS Builder V1.2.99 LE (19.02.2011)

A lot of changes including Personal data generator... Sorry guys - the full changelog will be ready tomorrow
[Windows Mobile] HD2Owner:
first post updated.

thanks alot @ barin / andrewsh
[Windows Mobile] AndrewSh:
OS Builder V1.2.99 (19.02.2011)

1. Fixed package description window size (5 lines, 120 pxl)

2. Built-in HTC Splash Tool added - you can create Primary и Secondary boot Splash WVGA (480x800) in NB or NBH format. You can also extract image from NB splash. See Menu Tools -> Built-In.

3. Built-in HTC NBH Builder Tool added

– allows to create NBH file from NB files. You can import NBH header parameters from settings, registry or NBH file. Files and code sections are added and deleted using the context menu.

Sections, which should be included to NBH must be toggled in checkboxes. You also can save your settings in a separate file. See the menu Tools -> Built-In.

4. For HTC-LEO - in case when the date and time sync failed on first start - date and time of the ROM creation will be added.

5. Several improvements in assembly and merge dsm algorithm

6. Fixed a problem with new versions of Yandex-maps

7.The option RomConfirmOverwrite has been added to the section [OSBuilder] of configuration file. If the parameter = False, then the assembly of the ROM process does not display “Over-write?” dialogue (the file is automatically overwritten). By default, this option is True

8. Built-In Personal data generator tool is added

– see Additional Tools - Personalize. You can pre-enter owner name, Wi-Fi settings, mailboxes, VPN connections and favorites.

You can add, delete and change personal data by using the context menu.

Favorite links found in OEM provxml files are added automatically to the top list. Toggle correspondent checkbox if you want them to be added to Favorites. You can add your custom Favorites in the bottom list via context menu.

Personal data is stores in the root of OEM folder in the file Personal.dat. You can save it in menu File->Save to OEM.

To integrate your personal data to your custom rom you should go to Configuration Menu->Advanced Settings->Write Personal Data (toggle checkbox)

Full version:

9. Added the possibility to save personal data (paragraph 8) in a readable xml (provxml) file.

Keep in mind that not all data can be imported during provxml runtime.

P.S. Sorry for Russian screenshots :)
[Windows Mobile] momo2004:
need projects for htc mega

thank
[Windows Mobile] brainmaster:
There is a bug in the latest OSBuilder - the "Add WiFi Network" Dialog is in Russian language.
[Windows Mobile] -=Barin=-:
I'll correct it ASAP
[Windows Mobile] AndrewSh:
OS Builder V1.2.101 LE (21.02.2011)

Changelog:

1. Fixed minor issues if OsBuilder is used in multilingual mode (several configurations for several rom languages)

2. Added the possibility to run SINGLE exe file with arguments while device first boot. Exe file will be executed after importing other Personal settings. The execution order corresponds to the order in the list.

3. Fixed English interface issues in Personal Data Generator
[Windows Mobile] HD2Owner:
thread updated
[Windows Mobile] HD2Owner:
please post feedback for the latest version here.

ideas for improvements are also appreciated.
[Windows Mobile] tobbbie:
I am a quite disappointed with the support on the full version. I had taken the chance to support the author and hoped to get some answers to my queries. However nothing happened (after 3 weeks waiting for a PM reply) - sadly.

...restarted my initial tests on the WM6 build but the one I use will not re-build. At the 4.th step for compiling registry OSB will crash with an unhandled exception "Object reference not set to an instance of an object". No further indication about where it failed and which RGU did not work ok.

Are there an better debug options in OSB? I would like to see many more details of the steps ongoing. Can logfiles be enabled for the various steps (including registry compile)?

...the relocation of the OEMDrivers is hard to understand compared to the other module's relocation. What I have observed is the following:

All modules seem to be relocated (they appear in the list of items during relocation) - except the OEMDrivers where special rules seem to apply:

The modules that can not be recmoded are not listed in any treatment of relocation. One of these modules is the ddi.dll, but there are many others as well. I have no visibility what happens to them during relocation.

For those that CAN be recmoded: If they stay as modules, then they are equally not visibly treated, unless they are manually added to the slot0 (add from OEMDrivers) for loading "LOW". They are treated then accordingly.

Looking at the DumpMap.txt I see several lines listed like "01E28000-01E45000 L0001D000 !!!!!". They confuse me as I think that the "!!!!!" indicates something to care about, but I don't know what?!

The purpose of the settings "Do not rebase modules (list)" is still unclear to me.

How do I add a module here?

How can I make this persistent? After leaving the settings and re-entering this item, the data are gone.

Are some modules (e.g. those in OEMDrivers) not relocated by default anyway?

How do I know which are these?

If above is true, how can I ever relocate the OEMDrivers modules?

As of now I feel completely lost what the relocation is concerned. The handling is very in-transparent - and relocation was the initial reason to go for OSBuilder :-(
[Windows Mobile] mwalt2:
Have you tried any other means to contact Barin? I'm not sure how much he checks forums. It's possible he may have missed it. You can try emailing the gmail address that you received OSBuilder FULL from. I know Barin is on there from time to time. You could also probably PM AndrewSh here at XDA, as he knows Barin well. All of the asusmobile.ru people I've interacted with have been extremely helpful.
[Windows Mobile] Skrobel:
I can only answer point one.

If there is any problem with registry files you can track it down easily by running Registry Preview from Additional Tools. It will show you which reg/rgu is causing problems.

However your error seems more serious than invalid registry file. When I messed up one of my rgu files, the OSB just wrote "cannot compile registry file" or something like that. But no "unhandled exceptions" so far.