1st W7 RTM build 7600.16384: Did MS named it cause They like the nos?


Recommended Posts

Some time ago a friend had told me there was no build 7200 in the winmain branch, because the build no. 7200 was reserved for RTM, and win8(or whatever MS would name it later, so ATM we just have to call it win8) was started from build 7301, and will RTM at build 8000.

I had read something like it on WZOR for the build 7200 reservation, then later everybody was predicting RTM is 7300. It came as quite a surprise when RTM was actually 7600.

Recently I learned from another friend on the concept, it seems MS simply had no other better choice than to name the RTM as 7600. It all started with Vista, The Windows QFE Team(Quick Fix Engineering) had reserved the final 4 bits of the binary build string as indications of Service Packs, thus, SP0(i.e. the RTM itself) is [0000]. There are 16 combinations, so there can be 15 Service Packs(7601 thru7615) to fill the available slots, naturally nobody would dream of having so many Service Packs for a single OS.

Then, for a reason beyond my understanding(I am no developer, nor have any interest in it), this caused the necessity that the RTM number has to be a multiple of 16. Furthermore, MS has the tradition to round-up RTM numbers to 100's, so the first candidate for the win7RTM in the 7xxx region would be 7200. MS might have reserved this number for RTM, but had thought better of it, because it is awkward to have the RTM evolved from a earlier build bearing the numbers of 726x.

Now, 400 is the minimum 100-rounded 16-multiple, so after 7200, 7600 is the next candidate, and the next one is 8000. MS would hesitate to use 8000:

- They probably prefer to leave 8000 and 8xxx's for win8.

- Windows API GetVersion could only support the max. build number of 16383(1 number below 2^14), MS may want to leave more room for the later OS's.

- The current softwares can only support 4-digit build numbers, it's something like the 2K bug. If MS could push the requirement of 5-digit build numbers further back, let the software guys to develope 5-digit build number supporting softwares, then by the time a 5-digit build comes out, the "4-digit build only" softwares should all have become deep-buried fossils.

Therefore, MS probably had no choice, they just have to use 7600 as RTM, but compiling a 7600 could be voted down and they couldn't compile another 7600 as next candidate, that's what the "minor builds" come into play.

Now, the QFE sets another condition, in order for HotFix to validate, the first(minimum) minor build number must have the value of [1] for the 14th bit, i.e. the number has to be 2^14(2 to the power of 14) ,i.e. 16384. Therefore, for Vista, win7,win8...., until this system was changed, the minor build number just has to be 16384, and then the next minor build numbers has no further conditions, it could be any number larger than 16384.

So, the first RTM of win7 just has to be 7600.16384; and the next interesting question is: What about windows 8??

Some people had said that win8 couldn't have started when win7 was not RTM, then please note these facts:

- Vista was developed in 5 years, when XP RTM, Vista was almost beginning it's mid-phase of development.

- Win7's first known build was 6.1.5025.winmain.050111-2030; when Vista was RTM in Nov. 06, the nearest known builds(before and after) of win 7 were:6.1.5729.0.winmain.060914-1613 and 6.1.6415.0.debuggers(dbg).070404-1234.

If according to rumor, win8 was developing builds in the 73xx range, if MS wanted to have win8 RTM at 8000, they need to proceed within this range, there is no rule against it, but it would be very awkward to develop new build numbers smaller than 7600.

If they were to start the next win8 build with numbers beyond 7615; than it would be most unlikely that it could RTM at 8000, there is simply too little room to do that.

Personally I would speculate that, just as in the case of win7, win8 would Beta on 8000, the next RTM number candidate would be 8400; but I thought it would be the better choice of 8800.

Edited by FaiKee
Personally I would speculate that, just as in the case of win7, win8 would Beta on 8000, the next RTM number candidate would be 8400; but I thought it would be the better choice of 8800.

:)

nice, thank you for the write up. makes total sense if you are a nut head, ;). very nice.

On 2nd thought I edited the part about people doubting win8, just didn't want to start another fight. :rolleyes:

Absolutely. Mate, it's seriously time for you to have a break. You've been reporting every single thing thats happened with Win7 for months now, reckon it's time to look at other pursuits? ;)

Yeah, starting as of to-day(after this little discussion I mean) I am getting my life back LOL. :laugh:

As I said, I am stuck with 7100RC until the retail comes out, so I wouldn't care about wtf about RTM leaking.

FaiKee: 7600 could be a relative ratio : distance Earth to the Moon divided by 40 years calculated on the 20th July over the sum of the first 16 prime numbers...only through this tiny Window RTM will occur....

Eco must be ROTF on this one (Foucault's Pendulum)

Reserving the lower nybble for SP identification makes a lot of sense, actually, and sounds like something that MSFT would do. And it does explain their W7 version numbering. How they chose the subbuild number (start at 0x4000, or 16384, and just work up) was apparent back when Vista first came out.

Just one nit, though: the valid range for build numbers is 0-32767 (only the first bit of GetVersion()'s high-order word is reserved; not the first two bits).

Edited by code.kliu.org
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Does anyone here know if these updates are integrated into the UUP dump isos?
    • Motrix Next 3.9.4 by Razvan Serea Motrix Next is a modern, open-source cross-platform download manager built as the official next-generation successor to the original Motrix project. It has been completely rewritten using Tauri 2, Vue 3, TypeScript, and Rust, while still relying on the powerful Aria2 download engine for high-speed multi-protocol transfers. The app supports HTTP, HTTPS, FTP, BitTorrent, ED2K and magnet links, offering advanced features like multi-connection acceleration, task scheduling, bandwidth control, and batch download management. With a significantly reduced install size (around 20MB), it focuses on being lightweight, fast, and resource-efficient compared to traditional Electron-based download tools. Designed for Windows, macOS, and Linux, Motrix Next delivers a clean, modern UI inspired by Material Design 3 principles, with smooth animations and a minimal workflow. It improves usability through better download organization, system tray integration, and enhanced torrent handling including selective file downloads and tracker management. Motrix Next features: Multi-protocol downloads — HTTP, FTP, BitTorrent, Magnet, .torrent, ED2K, and Metalink tasks BitTorrent — Selective file download, DHT, peer exchange, encryption controls, metadata caching, GeoIP peer flags, and tracker probing Browser extension integration — Embedded Extension API with independent authentication, download confirmation, smart auto-submit, filename hints, referer/cookie forwarding, and real-time controls (Chrome Web Store · Edge Add-ons) Safe filename handling — Content-Disposition, RFC 2047, non-UTF-8, percent-encoded, and extensionless URL resolution with path traversal sanitization Download organization — Favorite and recent folders, optional file-type categorization, stale-record cleanup, and completed history backed by SQLite Concurrent downloads — Independent controls for active tasks, HTTP connections per server, segments per file, and BT peer limits Speed control — Global and per-task upload/download limits with day-of-week and time-of-day scheduling System integration — Tray operation, optional tray speed display, macOS Dock badge/progress, protocol handlers for magnet://, thunder://, and motrixnext:// Lightweight mode — Destroys the WebView on minimize-to-tray while Rust keeps the engine, task monitor, notifications, history, and extension routing alive Notifications and power options — Native task start/complete/failure notifications, keep-awake during downloads, and optional shutdown after completion Network controls — Scoped proxy support for downloads, app updates, and tracker updates, plus system proxy detection Auto-update channels — Stable, Beta, and Latest Across Channels policies with separate download and install phases Diagnostics — Structured logs, exportable diagnostic ZIPs, database integrity checks, automatic DB rebuild, and Linux GPU rendering fallback Personalization — Light/dark/system theme, 10 color schemes, 26 languages, and first-launch system language detection Motrix Next 3.9.4 changelog: Motrix Next 3.9.4 promotes the 3.9.4 beta cycle to stable. This release refreshes bundled engine binaries, improves task detail readability and copy actions, expands link handling for magnet and ED2K workflows, polishes responsive navigation and text wrapping, updates browser extension documentation, and refines network preference controls. New Features Task Detail copy actions — Added copyable values for task metadata and reusable render functions for long text fields. Magnet and ED2K lifecycle support — Added task lifecycle handling for magnet and ED2K links. History cleanup for deleted tasks — Deleted tasks can now remove matching history records. User-Agent management — Added user-agent management and improved related network preference controls. Browser extension documentation — Added the Firefox Add-ons link for the Motrix Next extension. Improvements Engine binaries — Updated bundled binaries for supported architectures. Task Detail readability — Long task names, URLs, tracker values, and copyable metadata now render more clearly. Deletion messaging — Refined localized task deletion text for clarity and consistency. Text wrapping — Improved URI input wrapping and task name multiline display. Navigation layout — Improved sub-navigation responsiveness. Disk allocation default — Changed the default file allocation method to trunc. Proxy controls — Improved proxy button styling in network preferences. Download: Motrix Next 64-bit | ARM64 | macOS ~20.0 MB (Open Source) Links: Website | macOS / Linux | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • NVIDIA officially supports Ubuntu, as linked above with the GeForce NOW Hands on I did in collaboration with Paul Hill.
    • TO be clear I am not running linux today, however I keep thinking about it. And I want to make sure there are minimal obstacles if I decide to make that switch in the coming months.
    • Yes, I actually glossed over the Linux part from the OP. You could always go for a 9070 XT and if you really want to play Ray Traced games in the future, GeForce Now is pretty damn good on Linux https://www.neowin.net/news/nvidias-native-geforce-now-app-for-linux-bridges-the-gaming-gap-hands-on/
  • Recent Achievements

    • Proficient
      Eric Biran went up a rank
      Proficient
    • Dedicated
      Conjor earned a badge
      Dedicated
    • Week One Done
      Windows Guy earned a badge
      Week One Done
    • Dedicated
      Mark Spruce earned a badge
      Dedicated
    • Collaborator
      conkir earned a badge
      Collaborator
  • Popular Contributors

    1. 1
      +primortal
      479
    2. 2
      PsYcHoKiLLa
      252
    3. 3
      Steven P.
      72
    4. 4
      +Edouard
      69
    5. 5
      Skyfrog
      67
  • Tell a friend

    Love Neowin? Tell a friend!