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.

 

 

  • (I posted this previously but it seems to have gone in to the bit bucket)

    A project I worked on (at MS but not in the OS group) used the term "Armor" to refer to the optimizations:on and assert/spew/etc:on case. I don't know the history behind this term though.

    Most devs used armor builds for day-to-day work and only dropped to debug builds when the optimizer was particularly unforgiving with respect to the debugger.
  • I understand. I just place sanity checks in their own category, I mean when you for example read in data and want to check IF(Number(Data)) that isn't a "sanity check", that is a validation check. A sanity check is when you have had the data within the program for a while and just add a random check to make sure whatever you're processing is what you think it is.. But something that you NEVER intend to trip off.
  • >> we settled on "Checked" for the "O:on, T:on, A:on, S:on"

    Is it still true today? Currently DDK setenv.bat file sets O:off for "Checked" build.

    :checked
    rem set up an NT checked build environment
    set MSC_OPTIMIZATION=/Od /Oi

    /Od - This option turns off all optimizations
  • Here's an sampling of various goofy bugs we've had to deal with in the CLR Debugging services over the...
  • > we settled on "Checked" for the "O:on, T:on, A:on, S:on"

    Is it still true today? the DDK build environment sets /Od for checked build and disables compiler optimization.

    set MSC_OPTIMIZATION=/Od /Oi
  • Wei, that's the DDK, not what's MS builds.

    The optimizations are turned off because optimizations will mess up debugging. We live with the inconvenience internally because it catches optimizer bugs, but that's a concious choice that we made internally.

  • Thursday, September 01, 2005 2:22 PM by Chris

    > The checked builds were sloooooow, like 20x
    > slower than the free builds!

    Yes, but they catch 20x as many bugs.

    Does someone really read reports sent by Windows Error Reporting? If so, ask them if it would have been 20x slower for developers and testers to dogfood Microsoft's own code on a checked build than it is for analysts to interpret the reports.
  • Wednesday, August 31, 2005 9:48 PM by Norman Diamond

    > Obviously the kernel itself does run under a
    > checked build

    Liar. Did you even think of trying Windows XP SP2 checked build in any environment other than guest machine under Virtual PC? Uhhh, OK sure you did, there's that 7 year old desktop machine on that desk next to you and it worked, but did you even think of trying a 5 year old machine with devices more powerful than the Virtual PC emulations? And how are you going to find if newer drivers even exist when Internet Explorer aborts every time you try to do a Windows Update?

    You should think about things like that before you post. "Obviously" indeed. You know how much you hate it when you find yourself lying.
  • That must have hurt...

  • PingBack from http://topalternativedating.info/story.php?id=14164

  • PingBack from http://thestoragebench.info/story.php?id=1510

Page 2 of 2 (26 items) 12