Can you expand a bit on how the new patches folder works? Or point me at whatever docs I missed?

It's documented somewhere, but I forget where, so here's the gist of it:

First, if you don't have the patches folder already, you can add it to the 11/07_1 kitchen by createing a Patches folder and adding PatchDir=Patches to your selections.txt file. 11/07_1 distribution is the first ditribution with support for this feature.

It's really easy to use...put any files you want to overwrite core files in it.
BuildOS will copy those files to the ROM right after hive creation (which is why you can't use this method for rgu changes)
Any file that already exists in the ROM will be overwritten.

For RGU changes to core files, the best mechanism is the same as always...make an OEM with a uuid in the ffffff range.

That's all there is to it.

Thanks, seems simple enough.... so for example you could use that to do the PIE .dll patch in rom just by dropping in the .dll in the Patches folder?

simple, eh?

The down side of this approach, which will probably cause me to change a few things, is that you _always_ get the patch applied. This is fine for 90% of the core, but some things you can opt not to include...and the patch shouldn't be applied when you've opted out. I'll try to fix that behaviour for the next release.

Replacing modules is a bit trickier, as the patch must also be a module - you can't replace a module with a file.

Just to expand on the information given in this thread, when you have conflicting registry entries in the RGUs of your kitchen, the one parsed last is the one that will make it into the final rom. By using a UUID starting with f's in the first group of the UUID, your rgu in that package will be parsed towards the end, effectively replacing any conflicting registry entry you want to replace/update.

Another method of updating registry values is by using a minus sign after the opening bracket of the line, but this is not the preferred method in this application, as users may inadvertently remove an entire key when just trying to update one value. The f's naming convention is the way to go.

A UUID is usually assigned randomly or based on the time it was generated or both. In the current variant used, there are 5 versions used.

1. Time-based with unique or random host identifier
2. DCE Security version (with POSIX UIDs)
3. Name-based (MD5 hash)
4. Random
5. Name-based (SHA-1 hash)

You can find out which version is being used by looking at the first digit of the third group. For example, the tools some choose to use include the new oemizer and oem helper. Both tools use random generation, as demonstrated by a25ba3df-785a-4a9e-8dd4-b89d9f519e29. As you can see, the first digit of the third group is a 4, so it is random.

Anyway, this is probably way more than you ever wanted to know about UUIDs and how RGUs are processed and why, but figured I'd throw the information out there for those who care.

Can you elaborate...maybe an example or two? It sounds like your saying if I have
[asdf]
a=1
b=2

and I put this in my rgu:
[-asdf]
b=3
c=4

that I'll end up with
[asdf]
b=3
c=4

instead of
[asdf]
a=1
b=3
c=4

Is that correct?

BigJ - out of curiosity do you have an OEM for the WM6 threaded SMS? If you need the cab let me know.

Yes, and no. It applies to the whole key and isn't able to be used for specific values to the best of my knowledge.

example:

If your package has the following:

The usage is
which removes the whole Parms key and any values contained therein.

That's correct. The hyphen deletes a key--that's it.

I've been wondering how to do that for months! Thanks.

...now I need a CoolApp to try it on...