[Windows Mobile] Da_G:
Seems to me that there may be a little bit of language barrier here due to everyone communicating in english while that not being the primary language :) So maybe I can lend some of my understanding to help out here:

.SOF : Shadow Order File

.CIF : Compression Info File

Purpose?

.sof tells the system the "shadow order" in which to compile the registry.

.cif tells defines filesystem compression on a per-package basis.

Content?

.sof is a simple construct. {GUID} {GUID} {GUID} ... {GUID}

.cif is also a simple construct. {GUID} {dwCompressionFlag} {GUID} dwCompressionFlag} ... {GUID} {dwCompressionFlag}

possible values for dwCompressionFlag:
0x0 : No Compression on this package (all files/modules belonging to that package {listed in the .dsm belonging to that GUID})
0x1: Compress files only (do not compress modules)
0x2: Compress modules only (do not compress files)
0x3: Combines 0x1 and 0x2, compresses everything

Why might you want to compress files and not modules? One example - you have a device with NOR Flash rather than NAND. NOR supports true XIP (code can be executed directly from flash chip without prior copying to RAM, thus speeding execution) - however NOR flash cannot XIP if modules are compressed (must be decompressed to RAM prior to execution)

NOTE I have not examined the source code for EVERY tool out there but I am fairly certain .cif file is not honored by imgfsfromdump or xipport, etc. So really setting these values should have no effect.

Now for .sof: why do you want to make a shadow order for registry files?

Shadow Order concept exists for this reason:

Assume 2 .rgu files: 1.rgu and 2.rgu. To make reading simple assume 1 is a proper GUID and 2 is a proper GUID. But alphabetically sorted, 1 comes before 2. In case you have a problem imagining that, say 1.rgu is: 00000000-0000-0000-0000-000000000000.rgu and 2.rgu is 11111111-1111-1111-1111-111111111111.rgu.

Now, if we assume there are no relevent entries in .sof file for RGUComp to use during registry building process. RGUComp will add .rgu files according to GUID alphabetical order. So first we get:

1.rgu: tasty = 1

2.rgu: tasty = 0 (THIS OVERRIDES PREVIOUS tasty = 1 inside registry hive)

We all know cold beer is tasty (again it's just an example! :))

So really, tasty should be = 1. The function of .SOF is to enable us to ensure that 2.rgu overrides other registry .rgu so that tasty always = 1.

Now, for a more concrete example:

1.rgu contains some registry entries for 3rd party SMS/MMS provider.

2.rgu contains some registry entries for WM default SMS/MMS provider.

1.rgu is processed by RGUComp: 3rd party SMS/MMS is active in registry.

2.rgu is processed by RGUComp: 3rd party SMS/MMS is OVERRIDDEN by WM default provider, and now 3rd party SMS/MMS integration WILL NOT FUNCTION.

In this case, .rgu are being added alphabetically, and only way to "fix" is to change GUID of package 1 so that GUID of package 2 comes first. (rename 1.rgu/.dsm to 3.rgu/.dsm)

HOWEVER, this is exactly what .sof is designed for.

Now we put in .sof:

{GUID2} {GUID1} ... {GUIDx}

Now, when registry is built, RGUComp reads packages.sof, and sees that GUID1 SHADOWS GUID2 (because it comes AFTER in the processing order)

So, now during registry compilation we dont follow alphabetical order for these packages, we follow .SOF order:

2.rgu : WM Default SMS/MMS provider is active.

1.rgu: WM Default SMS/MMS provider is OVERRIDDEN by 3rd party SMS/MMS provider resulting in desired functionality when adding package to ROM.

So, I think that should make it clear why packages.sof is important. However not 100% required as there is a small case where a problem occurs: 2 packages contain same registry entries with different values, and are added to registry hive in wrong order.

Incidental to this discussion but related: .DSM contains associations/dependencies that also form a shadow order. This shadow order is more complex as it is treated more like a tree than a linear order. Technically these should also be followed to ensure that files/modules are overridden in the same manner that registry entries are. However, the same note as before applies. I don't think any current tool follows the .DSM shadow order properly except some private tools. Example: PRB file/module precedence is handled alphabetically in Windows Vista/7 (by date modified in XP if i recall correctly)

(btw, it's 04:30 here, if i made some mistake, please correct me and I will edit post. Sleep now :))