I did think of that but even if the source code is identical in every way except for the build number... it doesn't account for the differences in the end file. So, between 7600.16385 and 7601.17514, has Microsoft: - Updated the compiler - Changed the compiling options I think the first is more likely. When you think about it, changing the version descriptor, 7600.16385 to 7601.17514 should NOT change any part of the file except for those 9 characters. The files should NOT be any more or less offset, or any other compiled code changes apart from those 9 characters... or is it the case the file gets compiled different simply by changing a few text characters not relating to code, and not removing or adding any others characters...? The last sentence is meant to be more of a question than a statement, but to me it wouldn't make sense that the file should change too much in a comparison with such little changes relating to only the output text, that doesn't change anything except for a direct swap in numbers
I don't totally disagree with it either I was just thinking that since it appears there have been changes, might as well take advantage of it. I do think there's something more going on than just everything exactly the same in the compiling chain from the source code to the final file except for those nine text characters, but like I suggested earlier these changes probably relate to maybe an updated compiler... what changes that makes in reality is hard to say, the functionality, stability, or useability probably hasn't changed which only leaves performance. Maybe the recompiled versions are .1 percent faster or something
Do a fc /b and take a closer look at where the differences are: 1) There are the usual differences, e.g., the image timestamp, the image checksum, etc. 2) Information about the debug pdb file (stuff in the 0xC8nn range) that's generated and different on each compile. 3) There are the version changes. Also note that the string version, instead of "_rtm" is now "sp1_rtm". These extra characters produced a shift in the positions of everything following that change in the resources. Basically, all the changes found by running fc /b above 0x3B200 are the result of this. 4) So what's left? The two big chunks left to account for happen to coincide with the locations of the Import Address Table and the Relocation table. These are basically caches of the locations of functions in system DLLs. The new DISM was linked against a newer version of, say, kernel32.dll, and since the locations of the functions in kernel32.dll changed, the stuff in these tables will change, too. These are just caches; the IAT and Relocation tables are recalculated when DISM is run if it finds that the version of kernel32.dll that it loaded is not the version that it has these cached addresses for. Again, nothing that impacts the function of DISM. It does mean that a 7600 DISM running on machine with 7600.16385 system DLLs or a 7601 DISM running on a system with 7601.17514 system DLLs will start up sliiiiightly faster (probably just a few milliseconds, if even that) than a DISM on a system with different system DLL versions. Oh, the "Rich" pseudo-header contains, in part, a partial "signature" of the compiler, and it's identical in both. The important thing is that every single bit of executable code is 100% identical in every way, shape, and form. All of the differences are on the periphery and in parts of the PE file that do not affect the function of the code. Basically, the important parts--the code portion of .text, the merged rdata (minus the few bytes of unimportant info about the debugging pdb), and the .data sections--are bit-for-bit identical.
Ah ok! that makes sense then So the Import Address Table and Relocation tables of all the non 7601.17514 files are pretty much useless then? whats the point of them in the first place?!
This made a lot of sense back when NT was first developed: people were chugging along on 16MHz 386 machines, and every bit of efficiency helped. Also, you didn't have the kind of hotfixing back then that you have today, so you didn't have the situation where, after a few Patch Tuesdays (which obviously didn't exist back then), a bunch of your system DLLs are no longer their original versions.
thank you for the new release [edit] can you please add the quiet to the batch again? much nicer dont to get all the popups.
Are essential files like imagex.exe, dism.exe, wimgapi.dll, wimmount.sys, etc., etc., still the same as WAIK 1.0 and 2.0, or have some of these been changed in v3.0? Or does anyone know? Kind of don't want to download it (yet again) if it turns out to be the same core files again.
Can anybody help me get hold of these hotfixes for win7 x64 (KB2391591, KB2411000 v2, KB2495897, KB2461108 v2)? I can't download from Solor repository @geeksmack.net. My ISP is blocking it. Thanks
1.7G vs 1.5g new compared to old and it does not include the SP1 supplement, so, I think it includes more language files maybe. I do not have the old to compare anymore.
SoLoR Thanks for the repository. For the superseeded hotfixes as stated in "Removed" rows of your changelog, could you state this way? Removed: KBxxxxxxx (replaced by KBxxxxxxx) That way, I will be able to know which newer hotfixes superseed the older updates. It is just my suggestion, though. Putting that aside, I can still install Windows6.1-KB2264107-v2-x64.msu and Windows6.1-KB2305420-x64.msu to Windows 7 SP1. However, these 2 updates are not mentioned in the changelog. Why is it so?
Because they are techincaly not made for SP1 and if they are not speicificaly made for SP1 i personaly wont install them, simple as that. Like for example WAT, you can install it but its not made for SP1 and even more i think MS droped the idea of WAT because they remade whole that genuine page.