[小常识]Win7版本7600.16385的由来 为何不是7777 [复制链接]

所有的事情都是有原因的，Win7版本 7600.16384和7600.16385也是有出处的。 =-_B:d;  
首先7600这个build number是怎么来的。 =-_B:d;  
第一点自然是要被100整除， 这个是自从xp 2600开始的惯例。 关于这个惯例，还是有段故事的， 因为xp之前， build number都是1个1个加上去的， 从来没有跳过，但是xp的时期从exchange来了个老大到Windows部门， 于是就把被100整除的这个惯例带到windows了。 这一点没有什么技术原因，纯粹为了好听。 =-_B:d;  
那么为何不是7300呢? 这里有个技术原因。 最后的build number必须要能被16整除。这个是为了做service pack用的， QFE team预留了build number的最后4个bit用来作为service pack的number (当然这个是Vista开始才出来的要求了)。 比如Vista的6000， sp1就是6001， sp2就是6002，最多能做16个sp。 因此win7的初始rtm build号也必须被16整除。 那么因为之前最后一个build已经是7271了，最近的一个即能被100整除，又能被16整除的数字就是7600了， sp1就是7601。 7777虽然是个好数字，但是并不符合条件。 =-_B:d;  
=-_B:d;  
再下一个符合条件的就是8000了，那么为什么不是8000呢? 这里的原因是build number也是一种有限的资源， windows API GetVersion最大能支持的build number是16383，考虑到未来n年的需求，这里不能随意的乱跳build number，要不然再过几个release， build number就用完了， 到时候就麻烦了。 =-_B:d;  
最后说说minor build number， 也就是QFE version， 为什么是16384。 这个主要也是QFE的需求， RTM的minor number的第14个bit必须为1，这个是hotfix用来判断的一个依据， 这样的话满足条件的最小的minor number就是2^14=16384。 Vista rtm的第一个build也是16384，后来出了点问题才变成16386的。 这个和能不能被什么整除倒是没有关系。 =-_B:d;  
顺便提到一个问题， 就是n年后当Windows的build number到了10000之后， 很多软件就会出问题， 类似y2k问题。 =-_B:d;