所有的事情都是有原因的，Win7版本 7600.16384和7600.16385也是有出處的。
首先7600這個build number是怎麼來的。
第一點自然是要被100整除， 這個是自從xp 2600開始的慣例。 關於這個慣例，還是有段故事的， 因為xp之前， build number都是1個1個加上去的， 從來沒有跳過，但是xp的時期從exchange來了個老大到Windows部門， 於是就把被100整除的這個慣例帶到windows了。 這一點沒有什麼技術原因，純粹為了好聽。
那麼為何不是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雖然是個好數字，但是並不符合條件。
再下一個符合條件的就是8000了，那麼為什麼不是8000呢? 這裡的原因是build number也是一種有限的資源， windows API GetVersion最大能支持的build number是16383，考慮到未來n年的需求，這裡不能隨意的亂跳build number，要不然再過幾個release， build number就用完了， 到時候就麻煩了。
最後說說minor build number， 也就是QFE version， 為什麼是16384。 這個主要也是QFE的需求， RTM的minor number的第14個bit必須為1，這個是hotfix用來判斷的一個依據， 這樣的話滿足條件的最小的minor number就是2^14=16384。 Vista rtm的第一個build也是16384，後來出了點問題才變成16386的。 這個和能不能被什麼整除倒是沒有關系。
順便提到一個問題， 就是n年後當Windows的build number到了10000之後， 很多軟件就會出問題， 類似y2k問題。
