thank you, i appreciate the details. i will test this way and prove it to myself. i have thought that this was a lame excuse being used and would like to disprove that
since its relevant here now...(sorry to OP we are off topic)...i have changed to using the following in my batch. if a chefs concern is protecting his own additions, its not necessary to destroy the OS in the process.
Code:
attrib .\temp\dump\ffffffff-ffff-ffff-ffff-dcd*.* -s -r -h
del .\temp\dump\ffffffff-ffff-ffff-ffff-dcd*.*
attrib .\temp\dump\*.dsm +s +r +h
attrib .\temp\dump\*.rgu +s +r +h
attrib .\temp\dump\mxip*.* +s +r +h
obviously my packages follow a naming scheme and microsoft's do not use fffffff..
ok, but the behavior being discussed here...well if you cook your own rom, youre going to have a copy of every single file included anywhere in \windows. it sounds like what you want is a cab that installs elsewhere.
Going further OT, i would like to note that imgfs is linked list based, so the number of files in the linked list would affect traversal speed, especially in the case of an extremely large list. According to the Microsoft patent it seems like multiple linked lists are used:
http://www.freepatentsonline.com/EP1544732.html
But in practice, I think there usually is a single linked list. List traversal would then take O
time, as opposed to O(log n) time for some sort of binary tree. The storage region is FAT, and as usual is prone to the problems with the FAT filesystem. In particular:
"File entries within a given directory are not kept in any particular order. When a file is opened, the table for the directory is scanned, starting at the begining, to search for the file. When a new file is created, the entire table for that directory must be scanned to determine if the file already exists. When a file is deleted, the entry for that file is cleared, but the remainder of the table is not repacked to reclaim the entry (although the entry may be reused if a new file is created). What all this means is the amount of time to open or create a file in that directory will rise linearly with the number of files in that directory. A directory with a large number of files may impact performance." -http://blogs.msdn.com/medmedia/archive/2007/01/04/fat-filesystem-performance-issues.aspx
Which, although not particularly applicable to WM, does discuss how windows CE handles files in FAT land. I have made some attempts to port exFAT to WM, but uh, CE 6 is quite different from CE5.
Anywho, what this tells us is that a lower number of files is generally better for the performance of the IMGFS/FAT32 file system. The reason why you might not see a general increase in performance is that most day-to-day tasks on WM do not involve the creation or deletion of files in the \Windows directory, and I believe (don't quote me on this) that the MS app guidelines for the designed for wm logo discourage the creation of files in that directory, with the exception of DLLs upon install.
Finally, to get back on topic-
I try to always release a kitchen with a release so people can cook their own roms and possibly make improvements. For example, I'm not too big of a fan of those touchflo3d things, but some other people are, and maybe a cook can make a nice touchflo rom off of my base. Personally, I think that many (not all) cooks that protect/encrypt their files are worried because once the secret behind their ROMS success is revealed, it is easily reproduced. Others may do it because they don't want others to steal their secrets, etc. I've run into problems with certain people editing my work and claiming it as their own, so I guess I could understand where they come from. It is, ultimately their decision. However, I feel that those who are confident with that work, that it is different and good enough that when reproduced, people will still be able identify it, have nothing to worry about.
