Is Windows 7 7600 the RTM version?

J

J32P

[H]ard|Gawd
Joined
Mar 5, 2005
Messages
1,881
Is Windows 7 7600 the RTM version? Sorry if this has been talked about, I did a quick check but didn't see anything. Just wondering if people know for sure or not if this is actually the RTM version for the product. It seems likely to me but you never know.




Thanks
 
7600 is an RTM candidate build, and all the builds from now on are RTM candidate builds. They will each be tested, then voted upon and whichever one wins will be the "final" RTM build that is the finished product we'll get on Oct 22nd.

7600.16384 was the first true RTM candidate build, but it had some issues and as such is "nuked" and no longer a candidate for release. Currently 7600.16385 is the "new" candidate, still in testing/voting, nothing officially announced as of yet. Chances are good at this point that it could become the actual final build as it's been close to 5 days now since it was built without anything negative being reported (and yes, I have friends at Redmond - I don't need Russian websites trying to tell me shit I get firsthand). :) If 7600.16385 fails or doesn't get the votes, we could be looking at upwards of a 1 week delay before another candidate build is created, so we'll see what happens.

All anyone can do is wait at this point, until a final build passes testing and the vote and is declared the RTM build, aka the "Ok, we're done, ship it" build.

They're not there yet, but soon...

Keep an eye on this blog:

http://windowsteamblog.com/

When it says they're done, it really will be done.
 
not that I care but wzor said 16385 has been singed off to RTM,


xlkpdw.jpg
 
Last edited:
Just want to say Thanks.

There's a bunch of smart people on this site. Love It...:D
 
From what I understand, 7600 is the final build (as in, compilation of the source code into machine code). What remains is how those binaries will be packaged. Version 16384 used the final binaries, but has some glitches. The new 16385 uses the same binaries in a different packaging, and could very well be the very, very final version.

For the record, the RTM copy of Vista was 7600.16386, so there is some unfounded speculation that there could be one more version in the pipeline.

And by the way, please don't fall for the fake 7700 "builds" going around. It takes days to compile something as big as the Window source code, and is totally unrealistic that 7700 followed a few hours after 7600.
 
InorganicMatter said:
From what I understand, 7600 is the final build (as in, compilation of the source code into machine code). What remains is how those binaries will be packaged. Version 16384 used the final binaries, but has some glitches. The new 16385 uses the same binaries in a different packaging, and could very well be the very, very final version.

For the record, the RTM copy of Vista was 7600.16386, so there is some unfounded speculation that there could be one more version in the pipeline.

And by the way, please don't fall for the fake 7700 "builds" going around. It takes days to compile something as big as the Window source code, and is totally unrealistic that 7700 followed a few hours after 7600.
Click to expand...

6000.16386
 
InorganicMatter said:
From what I understand, 7600 is the final build (as in, compilation of the source code into machine code). What remains is how those binaries will be packaged. Version 16384 used the final binaries, but has some glitches. The new 16385 uses the same binaries in a different packaging, and could very well be the very, very final version.

For the record, the RTM copy of Vista was 7600.16386, so there is some unfounded speculation that there could be one more version in the pipeline.

And by the way, please don't fall for the fake 7700 "builds" going around. It takes days to compile something as big as the Window source code, and is totally unrealistic that 7700 followed a few hours after 7600.
Click to expand...

i am sure MS has the power to compile builds pretty darn fast if they needed to.
 
InorganicMatter said:
Well yeah, but it still is a daunting task even on today's hardware. It took about 30 minutes to compile an Xen Linux kernel on a Q9400 at work.
Click to expand...

Wouldn't they have some uber super computers to do that sort of stuff? Tasks that would take years to do on a regular desktop (like computational fluid dynamics) can be done in a few hours using the supercomputers or clusters of lab computers at my University.
 
Tudz said:
Wouldn't they have some uber super computers to do that sort of stuff? Tasks that would take years to do on a regular desktop (like computational fluid dynamics) can be done in a few hours using the supercomputers or clusters of lab computers at my University.
Click to expand...
Maybe, but I doubt it. As far as I know, compiling is usually done under the instruction set the resultant binary is expected to run via, meaning you use an x86 processor to compile x86 code. But I could be wrong. Anyone else know for sure? :confused:

Anyway, I doubt it's that big a deal to compile the Windows kernel.
 
And still no official declaration from Microsoft at the Windows Team Blog, so... until that happens, I ain't believing it. WZOR seems to have good info more often than not but, in this situation, I'll continue to wait for that blog to announce it's done.

As for "compiling" Windows 7, when a bug is discovered it's a complicated process to determine how it affects everything as a whole, obviously. If it's classified as a true showstopper, that can force a total rebuild which does take a considerable amount of time. Think about it: Windows 7 probably has over 75 million lines of code, potentially more... that shit ain't gonna compile in a few hours on anything. ;)

Most likely, if this happens, they would create a new build to keep with historically past RTM builds, as in 6.1.7600.16386... we'll see what happens.
 
Joe Average said:
7600 is an RTM candidate build, and all the builds from now on are RTM candidate builds. They will each be tested, then voted upon and whichever one wins will be the "final" RTM build that is the finished product we'll get on Oct 22nd.

7600.16384 was the first true RTM candidate build, but it had some issues and as such is "nuked" and no longer a candidate for release. Currently 7600.16385 is the "new" candidate, still in testing/voting, nothing officially announced as of yet. Chances are good at this point that it could become the actual final build as it's been close to 5 days now since it was built without anything negative being reported (and yes, I have friends at Redmond - I don't need Russian websites trying to tell me shit I get firsthand). :) If 7600.16385 fails or doesn't get the votes, we could be looking at upwards of a 1 week delay before another candidate build is created, so we'll see what happens.

All anyone can do is wait at this point, until a final build passes testing and the vote and is declared the RTM build, aka the "Ok, we're done, ship it" build.

They're not there yet, but soon...

Keep an eye on this blog:

http://windowsteamblog.com/

When it says they're done, it really will be done.
Click to expand...

I'm not disputing your build numbers, but you don't seem to know what RTM means. The RC is the release candidate, meaning it's the final candidate for going gold. It basically means we are done UNLESS we find a last minute issue, so there can be multiple RC builds but usually not too many. The beta builds are when they are actively changing stuff. RTM means it's done, gone gold, and actually released to manufacturing hence the name. So if it's not done yet then there is no RTM release, only another RC build.
 
Pueblo: If you noticed, he never said it was an RTM build. He said it was an RTM candidate build - a build that could become RTM if it passes enough tests. There is a difference between an RC build and an RTM candidate build - a big one.
 
Arainach said:
Pueblo: If you noticed, he never said it was an RTM build. He said it was an RTM candidate build - a build that could become RTM if it passes enough tests. There is a difference between an RC build and an RTM candidate build - a big one.
Click to expand...

An RTM candidate build IS an RC build, hope that helps. :p The secret is in their names:

Release Candidate
Released to Manufacturing
 
OldPueblo said:
An RTM candidate build IS an RC build, hope that helps. :p The secret is in their names:

Release Candidate
Released to Manufacturing
Click to expand...


In the RC branch, they think they've got all the major bugs ironed out and are hunting for little nagging issues, finalizing the UI, and completing documentation. When they move to RTM phase, they've decided that the release candidate is good enough for deployment, and submit it to escrow. If developers or partners don't find anything wrong within X days, the sign off on it and it goes to manufacturing. If they do find something wrong, the pull the build from escrow, fix the problem, rebuild, and submit the new build for X days.
 
ryan_975 said:
In the RC branch, they think they've got all the major bugs ironed out and are hunting for little nagging issues, finalizing the UI, and completing documentation. When they move to RTM phase, they've decided that the release candidate is good enough for deployment, and submit it to escrow. If developers or partners don't find anything wrong within X days, the sign off on it and it goes to manufacturing. If they do find something wrong, the pull the build from escrow, fix the problem, rebuild, and submit the new build for X days.
Click to expand...

If you have a link proving this then I'll happily shutup, otherwise it makes no sense to bleed the RC phase into RTM since RTM means its done. Is there now then a new acronym for RTM like SMFD (super mega finally done)? All the stuff you reference is done technically in the RC phase. There may be a seperate branch heading towards RTM but it's not actually RTM and they can easily opt to make it RC2/3/4 for further testing.

EDIT: On second thought I guess I'm probably just being a douche bag, we're technically saying the same thing I'm just being a stickler for the names. Here's a handy reference link for everyone http://blogs.msdn.com/e7/archive/2009/05/11/OurNextEngineeringMilestone2.aspx
 
Last edited:
From your link:
The RTM milestone is not a date, but a process.
Click to expand...
Trust me, I've known people at MS in the past, and "RTM candidate" is a legitimate term for a build; whoever Joe's talking to, they at least use the proper vocab.
 
Arainach said:
From your link:Trust me, I've known people at MS in the past, and "RTM candidate" is a legitimate term for a build; whoever Joe's talking to, they at least use the proper vocab.
Click to expand...

Yeah my whole thing based around the fact that RTM actually means its locked and done, and sure they continue to work on it but via releasing fixes/service packs, not the same way they modify it pre-RTM by actually changing the code.

As that process concludes, we are done changing the code and are officially “servicing” Windows 7. That means any subsequent changes are delivered as fixes (KB articles) or banked for the first service pack.
Click to expand...
 
All of this is done in stages... alpha stages get to a point where "Ok, there's not much that can be done with this anymore, time to move on," and it then gets called beta. Beta is worked on over and over till it's solid enough to a candidate build that potentially is ready for a release.

Release candidates then get tweaked, debug code starts getting pulled from known solid chunks of it, performance improves overall, etc. A step at a time. When they get a release candidate that meets or exceeds their own internally set requirements, that's a candidate for release to manufacturing status. Then the testing starts all over again but on a higher level, with more stringent requirements.

Once they've moved on past RC builds to RTM builds, every single RTM candidate is a potentially "final" product. There's major and minor builds: 7600 is a major build; .16384 is the minor build. They don't rebuild the entire OS from scratch unless a MAJOR showstopper is found at that point; it's just a set of minor build updates, hence .16384 lasted about 1 day and they found something that nuked it, and .16385 took its place.

7600.16385 appears to be the one, so far. It's passed testing, and apparently it's even passed the vote (but I can't get anybody to verify that 100%, it's Saturday night and my own contacts are all out doing schtuffz - which could be a good sign if they're done, they're out partying now), but there still hasn't been an official declaration from Microsoft anywhere (still waiting on that blog to announce).

We'll know absolutely for sure in the next oh, 48 hours I'd say, by midnight Pacific time on Monday if 16385 is the real deal, or if they're intending to rebuild once more (a minor build) to get that historical 16386 number which follows 'em around, or potentially 7700.16386 just for shits and giggles.

It's not done yet, and anything is possible, that's the important thing to come to terms with at this point.

And keep an eye on that Windows Team blog too... ;)
 
I agree with you Joe, if anything official is going to be announced it'll happen tomorrow (monday).
 
It's official. That's not why I posted though.
Do you have to still have to defrag with Windows 7?

Just making sure. Don't beat me up.:confused::eek::(:D
 
The automagic background defragging in Windows 7 (and Vista, of course) negates the need for 3rd party software for that purpose. But if you absolutely must use such software, you can without issues. I recommend PerfectDisk above all others... but I haven't used it except for testing purposes because Windows 7 (and Vista) defrag themselves just fine.

Both are self-tuning OSes, effectively, and they do get a bit faster over time. Leave it alone is the proper attitude one should most likely stick with while letting the OS take care of itself.

Throw more software on it, things just get worse.
 
There was no need whatsoever to actively/independently perform a defrag in Vista. Windows 7 isn't a step backwards in that regard, so your answer is a firm "No".

These latter-day Windows versions come default configured to background defrag, and the job done if they're left that way is more than adequate. Over 3 years of continuous usage of Vista and now Windows 7, with regular periodical checks being performed using PerfectDisk, I've never seen any of my drives more than low single digit percentage fragmented. The default system tool, as configured by default during install, is all anybody actually needs.
 
uhhhh, you got me, XP Pro SP2 (64-bit) then, SORRY.

By the way, stop with the pwned comments. Move on
 
You must log in or register to reply here.
Back
Top