Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Where do "checked" and "free" come from?

Where do "checked" and "free" come from?

  • Comments 26

People who have MSDN or the DDK know that Windows is typically built in two different flavors, "Checked" and "Free".  The primary difference between the two is that the "checked" build has traces and asserts, but the free build doesn't.

Where did those names "checked" and "free" come from?  It's certainly not traditional, the traditional words are "Debug" and "Retail" (or "Release").

When we were doing the initial development of Windows NT, we started by using the same "Debug" and "Retail" names that most people use.

The thing is, it turns out that there are actually four different sets of options that make up the "Debug" and "Retail" split.

You have:

  1. Compiler Optimization: On/Off
  2. Debug Traces: On/Off
  3. Assertions: Enabled/Disabled
  4. Sanity checks: Enabled/Disabled

Traditionally, "Debug" is "Optimization:off, Traces:on, Assertions: on" and "Retail" is "Optimization:on, Traces:off, Assertions: off".  Sanity checks was something the NT team added.  The idea was that there would be additional sanity checks built in for our internal development that would be removed before we shipped.

So the NT build team wanted to build "Optimization:on, Traces:on, Assertions: on, sanity checks:on" and "Optimizations:on, traces:off, assertions: off, sanity checks: on" and "optimizations:on, traces:off, assertions:off, sanity checks: off".

The last was what was traditionally called "Retail" - no debugging whatsoever.  However, the question still remained - what to call the "O:on, T:on, A:on, S:on" and "O:on, T:off, A:off, S:on" build - the first wasn't "Debug" because the optimizer was enabled, the latter wasn't "Retail", since the sanity checks were enabled.

So clearly there needed to be some other name to differentiate these cases.  After some internal debate, we settled on "Checked" for the "O:on, T:on, A:on, S:on" and "Free" for the "O:on, T:off, A:off, S:on" build.  Checked because it had all the checks enabled, and free because it was "check free".

And as the NT 3.1 project progressed, the team eventually realized that (a) since they'd never actually tested the "retail" build, they had no idea what might break when they started making builds, and (b) since they had perf tested the free build and it met the perf criteria, the team eventually decided to ship the free build as the final version.

 

 

  • So, are there still sanity checks in the Free build?
  • "After some internal debate, we settled on "Checked" for the "O:on, T:on, A:on, S:on" and "Free" for the "O:on, T:off, A:off, S:on" build. Checked because it had all the checks enabled, and free because it was "check free"."

    Wait a sec... but they both have "S:on" (sanity checks on)... shouldn't they both be checked, and the differentiation be on the assertions?
  • No, the point is that the sanity checks are always on, the original intent was that they'd be removed for retail, but that never happened.

    The checked/free differentiation is about traces and asserts.
  • David, yes, the sanity checks are still there. The concept of a "retail" build in it s original form no longer exists.
  • Out of abject curiosity, is this only true in NT and derivatives, or does this include programs like office, exchange, etc as well? I know anything built in .Net would have various sanity checks as well.
  • Can we get an example of a sanity check you're likely to find within Windows?
  • > And as the NT 3.1 project progressed, the
    > team eventually realized that (a) since
    > they'd never actually tested the "retail"
    > build,

    With more modern versions the opposite seems to be the case. For example maybe I'm the only person who tried to install Visual Studio 2005 July CTP onto a checked build (couldn't do it) or the earlier beta 2 (got most of it done). And maybe I'm the only person who noticed some of the messages displayed in WindBag by mmc.exe and some other stuff under a checked build. Obviously the kernel itself does run under a checked build so some teams are still dogfooding a checked build, and some driver writers mention how much they depend on checked builds. Can you persuade some of the other teams how valuable it would be to do the same?
  • I think this is the first post from you about internal stuff that I had absolutely no clue about. I had no idea whatsoever. And I'd never thought to ask anyone.

    Thanks for the info.

    I wonder why there is no "Windows Lore" wiki somewhere. I haven't even seen anything like that internally. Without one, what will the rest of us do when the mothership comes to take you and Raymond away?
  • How does one decide what becomes an assertion and what becomes a sanity check? Aren’t both assumptions that will cause undefined behavior if violated?
  • Just curious.....

    Most test teams inside Microsoft use the fre builds (x86fre, ia64fre etc) for feature verification / BVTs / Sanity Passes.

    Which brings me to these ..........

    1- How often does your test team use a chk build for automated testing? Not as often as you possibly think...

    2- I don't think the chk build is ever used for selfhosting or deployment purposes.

    3- Most teams use test hooks (e.g. registry keys) to turn on debug messages / traces / spews on fre builds. Plus you always have private symbols available for debugging. So what real advantage does a chk build have over a fre build?

    4- Then why do the build labs go through such pains to generate the checked builds for each feature branch (vbl_???_???). And that too on a daily basis. It clearly doesn't find much usage.....


  • Manip, I can't come up with any examples, mostly because after 15 years any examples are long gone - the conditionals that made the "extra checks" are long gone so the concept is meaningless at this point.

    AC: We don't use checked builds that often, but we run all our stuff checked - for some components that are relatively self contained (like the audio subsystem), it's totally possible to drop a checked set of binaries onto a retail system. The checked build was always intended for testing purposes, not deployment/selfhost test (although I know some people who selfhost on checked builds (brave souls them)).

    And the reason that checked builds are built and tested is that the checked builds catch problems daily.
  • Oh sorry, I misunderstood. I thought Windows had generic sanity checking in it today...

    Although it kind of does if you compile using Visual Studio 2005 but not things that the programmer has to worry about.
  • Manip, there are all KINDS of sanity checks in the OS. But they're all just part of the normal OS, they're not specifically called out.

    At one time there were #if !RTL conditional compilation macros around the "sanity checks", the #if checks have been removed because we're never going to turn the RTL flag on.

  • One project I worked on (within MS but not the OS group) called the variation of optimizations:on and assert/spew/etc:on "Armor". I have no idea where that term came from though. Armor builds tended to be the ones that most people used on a day-to-day basis and they only dropped to Debug builds when the optimizer just got to funky with the code to figure it out without a lot of pain.
  • I worked on Microsoft's Windows 2000 QA team back in the mid 1990s. We rarely tested the checked builds, but I would occasionally. The checked builds were sloooooow, like 20x slower than the free builds!
Page 1 of 2 (26 items) 12