The Old New Thing

I don't know.  It's kind of hard to mess up:

DWORD dwSeconds = (dwDosDateTime & 0x1F) * 2;

My guess: they tried to do a bitwise OR but accidentally did a logical OR, thus casting the seconds from an integer to a boolean and therefore causing it to always be either 1 or 0.

Doh.  I was going in the opposite direction.

The seconds field contains the number of two-seconf increments:

dosdatetime.seconds = seconds / 2;

Now type "%" instead of "/".

Pity about the daylight saving ending. I enjoyed having new entries show up at 15:00 instead of 16:00 for the past week.

I think MrZebra is on the right track - just replace OR with AND.

(seconds && 0x1F) will be 1 for every value of seconds except 0.

dwSeconds = wDosTime & MASK_SECONDS; //no?

dwSeconds = (BOOL) wDosSeconds ?

dosdatetime =   ...

            | (hours        &  0x1f) << 11  

            | (minutes      &  0x3f) << 5

            | (seconds / 2) && 0x1F;

Ok, let's start with correct code to compute the DOS date/time value:

dwDosTime = ((dwYear & 0x7F) << 25) | ((dwMonth & 0x0F) << 21) | ((dwDay & 0x1F) << 16) | ((dwHours & 0x1F) << 11) | ((dwMinutes & 0x3F) << 5) | ((dwSeconds >> 1) & 0x1F);

dwSeconds is right-shifted by one bit to divide it by two. If you mess up by typing ">" instead of ">>", you'll be testing whether dwSeconds is greater than 1 instead, which will be true (evaluate to 1) for most values of dwSeconds.

Another possible error is the one I mentioned earlier: typing "&&" instead of "&". However, this seems less likely, assuming the programmer knows what they're doing (which they do if they got the rest of the expression right) - it's an excessive keystroke, as opposed to a missed one.

Nice to know I got it! I have to give credit to MrZebra for inspiration.

Good point about not needing to use AND; I was just being cautious.

> the month is always at most 12

unless it isn't. I would be quite cautious in what is bit-masked to the timestamp. If something goes wrong and you receive a garbage instead of minutes, it messes up the whole value.

On the other hand - there is much more oportunities to make a mistake when playing with masking :-)

I haven't installed Windows in a while but I seem to recall at least some OS installers asking what time it is.  If that is the case, then it's likely that the time input doesn't have a seconds spot - I don't know anyone who cares down to the second when setting the time.

But that's not a programming error, really, is it.

...with 0 or 1, uh, heck.  Well if you've got your timestamps going with, say, milliseconds since epoch or something (fp unix or win32 time), I'd say they did round(time % 60, 1) / 60 or something silly like that.  For high second counts it'll give you 1.

The true Error is the managment with allow this kind of bugs slip away for ages.

@640k: Why, when reading a description of a bug last manifested in software released almost ten years ago, that was so inconsequential that none of the millions of Windows users ever noticed it OR were affected by it in any way, do you immediately jump to conclusion that it's a Microsoft management conspiracy?

Is that *really* the most likely explanation for the bug Raymond described, given that Raymond (a Microsoft developer) is the one describing this bug to you in the first place?

The real error is using a language with absurd C syntax. (Would anyone do this with Delphi/Pascal and '>'/'shr' operators?)

Is the bug fixed in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate yet?

"The real error is using a language with absurd C syntax"

That is why Real Men program in C.

@Lawrence, a smart developer would ask whether the bug is in a shared function (I guess Raymond would have said so if that were the case), and whether the buggy source code has been cut-n-pasted elsewhere (which I don't expect Raymond to know.)

So, yes, a 10-year old bugs do matter, even though I agree in this case the consequences seem minor.

@Burak: To answer your question: No, Pascal will prevent entire classes of 'typo' bugs like this, which is a good thing.

But to counter your bogus assertion: I don't believe Delphi was an option when developing the Win95 installer. Remember the title of this blog.