BUT binaries like cmd.exe are old even compared to newest Insider versions (MS obviously has newer ones internally). Broken frankenbuild. TBH I thought Insiders were getting RTM - to test it so MS can do day 1 patches and touch up for Final on the 29th. MS can disable KMS/OEM activation and timebomb it, like all the other Insider builds..
TBH I thought Insiders were getting RTM - to test it so MS can do day 1 patches and touch up for Final on the 29th. The Final is not released until about 2 months after Jul 29 RTM
Dude, look at the compile date, the files in 10176 are NEWER, just labeled as 10011 due to a binary versioning issue when the build was compiled. Whoever set the build to compile didn't configure the flags correctly, that's all there is to it. If this was really 10011 binaries, this build would look like 10011.
No, because only some binaries are 10011, whereas others are 10176, and still others are 9600, etc. It's a frankenbuild, either because it was compiled incorrectly, or the leak came without the binaries included and were inserted post-leak. Also the "compile date" just refers to the date it was compiled. It has nothing to do with the VERSION of the file compiled. Obviously it was compiled recently, either by MS before it got leaked, or after it got leaked.
There were also two versions of 176 cut..almost 12 hours apart. Maybe this was the first and the second was to fix all the screwed up modules that still said 10011
Were they both leaked? Weird. Also I'm fairly convinced that those ARE 10011 modules, not incorrectly labeled binaries. If incorrectly-labeled modules were the only problem, then MS would've RTMed this week.
I don't know which were leaked but these were the two that were made and still reside in the RTM branch 10.0.10176.16384 (th1.150705-0552) 10.0.10176.16384 (th1.150705-1526)
I'm sorry but no, you have a complete lack of understanding of how the build process works internally at Microsoft. When a build is kicked off for compile there are flags that are specified to assign file version numbers as well as overall build number etc... This build was compiled as 10176.16384 but due to the binary version flag being set incorrectly, most files are stamped 10011.0. Windows is compiled every day as an entire entity and files are never re-used from a previous build for a mix and match build. You can call this whatever you please but it is not a frankenbuild, all of the digital signatures are valid and all have the same date, that is not achievable by anyone other than Microsoft themselves. Flat out 10011.0 is an error for obvious reasons and will be fixed in a future build, it's probably the whole reason 10176 was rejected so quickly in the first place.
Windows has a lot of hidden packages. If they were compiled with a 10011 instead of 10176, it would absolutely come out this way. It doesn't mean that the files were swapped or anything. The OS most likely wouldn't even run if the files were really old versions. I wouldn't get too hung up on the 10011 thing. I'm pretty sure it's just an error on the compile like Chris said.