The Old New Thing

Presumably the maximum is actually 11059200 (exactly 128 days).  If so, why would you measure (and limit) boot menu timeout in terms of days, and why would you choose 128 as the cut-off?  Documentation for boot.ini indicates that a value of -1 = no timeout, so if it is possible to not have a timeout why would you limit the maximum timeout?  What if I want a timeout of 129 days?

"...so if it is possible to not have a timeout why would you limit the maximum timeout?"

Presumably because deep in the bowels of Windows there is a variable that stores that timeout value and that variable has to have a data type i.e. it has to be bounded.

Rather than 129 days you might as well ask about 2^1024 days. It's equally as silly and unlikely.

Haha its funny when he makes jokes w/ such things...

John: OK, but the boot menu timeout is not measured in terms of days, it's measured in seconds.  That question doesn't make any sense -- you're converting it so it's measured in terms of days and then asking why...

There has to be some maximum, right? For this application, 11 million seconds is well beyond what one would need for this purpose and is a suitable maximum.

If you need a timeout longer than 11 million seconds, then you probably should look at finding another way to do whatever it is you want to do.  Perhaps some kind of mechanical timer connected to the on/off switch?

@John Topley:

"Presumably because deep in the bowels of Windows there is a variable that stores that timeout value and that variable has to have a data type i.e. it has to be bounded."

Um, there are these things called bignums.  Or 256-bit numbers.  Really, it was a design decision.

"Rather than 129 days you might as well ask about 2^1024 days. It's equally as silly and unlikely."

Well, 2^1024 days would be after the heat death of the universe.  But, let's say you want to use Windows in some sort of probe and want it to delay bootup by 1 million years?  Yeah, that's silly.  Who'd trust Windows (or any other generic OS) to work reliably in a space probe?  Still, 129 days isn't asking a lot.  But I can understand why during the design it was just not considered reasonable.

Writing your own GINA huh, that brought back some memories ;-)

I've not come across anyone post about GINA stuff for months... years even.

Sometimes it seems like having a limit inspires people to ask why it is there.

Is there really some scenario where you want a computer to be on, but refuse to boot for more than 129 days?

I thought the boot menu timeout was only for the screen where an OS can be selected from multiple values? Also, in response to John, I've read that -1 requires the user to make a selection.

@Sitten Spynne

"Is there really some scenario where you want a computer to be on, but refuse to boot for more than 129 days?"

Now now, it's not saying it /can't/ boot, just that it waits that long before making the default choice. You know, if the user has to do some research to determine what option is the best.

Some people argue just for the sake of arguing.  I hate these kinds of people.

Them: "But what if I really want to delay it for 128 days!?!"

Me: "What if I really want to punch you in the face?"

"But, let's say you want to use Windows in some sort of probe and want it to delay bootup by 1 million years"

You're kidding right? Have you any idea how many Windows updates it will have to download and install when it finally does start up after all that time?!

@SM: The timeout itself is measured in seconds (obviously), but the limit is set at 128 days (or 11059200 seconds).  The value 11059200 requires 24 bits to store.  Since you're already using 24-bits, why not accept the highest 24-bit number of 0xfffffe (or 16777214 seconds = 194+ days)?  At least that way it would actually be a storage limitation instead of an arbitrary cut-off.

My question would be, why is a cached logon not working? XP supports it. You have to go into group policy to turn it off, in fact.

To further clarify my original question, if there is only 1 OS installed, does the boot timeout have any impact?  I just tried setting mine to 300 from 3 and noticed no difference in boot time.  I'm just not sure how this solves the original issue.  

Mike, they may have some custom scripts that run at startup, assuming that domain logon has already happened.

Also, doesn't cached logons put up a modal dialog on the screen that has to be manually cleared?

@John:

>> Since you're already using 24-bits, why not accept the highest 24-bit number of 0xfffffe (or 16777214 seconds = 194+ days)?  At least that way it would actually be a storage limitation instead of an arbitrary cut-off.

<<

Umm, really, does anyone beside you care about this?  Have I just been trolled?

These are some of the most (unintentionally) hilarious comments that I've read in a long while.

Why do some people insist on arguing design decisions based on what some martian might want to do with a space probe in the year 2,000,000 AD?

Sigh.

Dave:

Cached logons used to put up a modal dialog, but I don't believe they do anymore.  (I'm pretty sure they don't on XP, and I don't believe they do on 2000 either.  I am fairly sure NT4 had them though.  No idea about the 9x family.)

"Um, there are these things called bignums.  Or 256-bit numbers.  Really, it was a design decision."

You have to be kidding.  First of all, you'd have to be insane to use either of those for this particular purpose.  (Maybe if your OS is written in Python...)  Secondly, 11 million fits in 24 bits, so you wouldn't even need 64-bit integers.

"There has to be some maximum, right? For this application, 11 million seconds is well beyond what one would need for this purpose and is a suitable maximum."

But it's an interesting maximum because it's not the limit of any natural data type.  32 thousand or 2 billion would be more what one would expect.  Most likely the time is internally counted as days/hours/minutes/seconds with 1 signed byte for each.  It's probably code from when DOS was important that it just hasn't been worth changing.

I'm surprised it's so high...  I can only guess that someone must have needed a way to delay Windows' boot up exactly like this.

John, your post reminds me of Slippery Slope Guy from the Adam Carolla radio morning show.

"Sure, let's set the limit to 128 days. But it's a slippery slope! Next thing you know we're clutching the outside of a space probe, two thousand years in the future, unable to get the airlock door open again because the damned Windows computer isn't booted up yet! We could all die!!"

For the timer to work in the boot.ini you do have to have more than one entry listed under [operating systems]. You can easily put the same entry in there twice so you can get the delay or prompt.

The question may seem somewhat stupid, but actually it would be interesting to know "Why 11059200 seconds/184320 minutes/3072 hours/128 days?".

Not because someone wants to set their timeout to 129 Days, but simply because it's a nice bit of Trivia. 11059200d is A8C000h or 101010001100000000000000b.

Is that any magic number?

Are the Bits used for something else?

Or did someone just pick the number "128 Days" by Random?

Again, nothing important, but those nice Bits of Trivia are always nice to read.

My guess would be it's using some old BIOS call or basic low-level hardware interrupt to increase a counter. But I couldn't find anything that quite added up.

As long as we're digressing...

Them: "But what if I really want to delay it for 128 days!?!"

Brian: "What if I really want to punch you in the face?"

Me:  "Your right to swing your fist ends just before my nose...  What if I really want to visit you when you're in jail?"

Dang, now you've got ME doing it.

Set the timeout to -1 and use a soft-event -- the evolution of the next species who can hit "Enter".  

Why not 130 days?  Sheesh.

josh's and Michael's comments better state what I was trying to get at.

@James: Slippery Slope Guy is my idol.

PingBack from http://www.universityupdate.com/Technology/Windows-Vista/5249041.aspx

Maybe whoever designed this little piece of Windows deliberately chose an arbitrary cutoff just so people would argue about why they chose that number.

If so, they'd probably get quite a good laugh out of these comments :-)

@josh:

'"Um, there are these things called bignums.  Or 256-bit numbers.  Really, it was a design decision."

You have to be kidding.  First of all, you'd have to be insane to use either of those for this particular purpose.  (Maybe if your OS is written in Python...)  Secondly, 11 million fits in 24 bits, so you wouldn't even need 64-bit integers.'

I was kidding, to an extent.  But the idea that "you'd have to be insane" to not have such limitations *is* a design decision.  Perhaps in this case, it truly is insane.  But developers (or their managers) often don't really think out real-world considerations.  The results can be all sorts of backwards compatibility nightmares; look no further than the discussion that the issue at hand might be a DOS/BIOS compatibility issue.  Or a lack of consideration can lead to bizarre failures--any "power user" using Linux long enough has probably stumbled across argument list limits, something which has been worked on recently.  Meanwhile, other software is designed and developed which does just fine with such "insane" considerations.

So, it's just a little funny every time I hear about another seemingly arbitrary limit of NT or Linux or any other similar modern system.  Perhaps the next time you hear about a limit, be it 32K, 2GB, or 18.45 billion billion and you find you *do* have a reason to surpass it, you'll have a little chuckle too.

So here's my guess on the reason why the limit is roughly 11 million seconds. The max value of a signed 32-bit integer is 2147483647. Divide this by 182 and you get 11799360.7. Why 182? The boot timer uses the system counter (INT 01Ah) which increments 18.2 times per second (but the math is done with 182, since it needs to work with integers, and the 0.2 would become significant for longer timeout values). I suspect if you try it with 12 million it will timeout very quickly.

I think it's pretty obvious that the limit was put in to stifle competition (somehow).

"Maybe whoever designed this little piece of Windows deliberately chose an arbitrary cutoff just so people would argue about why they chose that number."

I always find that sort of thing tempting when I code. Using things that seem just different enough to the norm to look significant. Maybe a cutoff that is just before a datatype limit, or 100/5 instead of 20 just so they try to figure out what the 100 means (because obviously performing the division was a note about a meaning that would be lost with a straight number). I usually resist because I know that it'll be me that comes back to the code and spends a day trying to figure it out in case I break something.

Some of you readers have so missed the point of this article that I just have to congratulate you.

The point of the article is that the low-tech solution is better than the high-tech solution (and for more than one reason).  Raymond first describes a low-tech software solution against a high-tech software solution.  However, commentor SM shows that we can extend Raymond's principle even further.  SM suggests using a mechanical timer to decide when to turn on the computer.

But then you cry:

"Waahh!  What if I want to use a delay of 129 days?  Waahh!  What if I want to use a large delay to the year 1,000,000 AD?"

For once let's make Raymond proud and show that we are reading his blog entries.  I will now invoke Raymond's blog entry that inspires us to "imagine if this was true."

OK, let's imagine if this were true.  Let's imagine that the boot process can wait 100 years before starting the operating system.  What do we have?  We have a computer doing absolutely nothing, except sucking up valuable resources like electricity.  Does this seem to make sense?  Is this efficient on our part?

Let's go further.  What if this were true.  What would happen if something caused the power to go out?  When the power comes back and the computer turns on it will start counting to 100 years starting from 0.  That means we will miss our mark of 100 years from the original point in time when the computer was first turned on.  What can we do about that?  Can we use a battery to remember the elapsed time?  Can we then program the boot process to fetch the last recorded elapsed time and make a determination?  Sure, but at the price of complicating the code, and Microsoft's QA dept. already has enough on their plate.  Clearly this is not path we should be pursuing.

So what do we do?  Go low-tech.  Throw a mechanical timer into the mix.  It will turn on the computer when the time is right.  It will consume far less energy than a computer.  It can also programmed to turn on the computer on a specific calendar date (and the important point here is that small code inside the timer is FAR less complicated than Windows and thus should be practical ensure it is bug free).  Maybe it has a battery to remember its settings for when power goes out.  Maybe the battery recharges when power is on.  The point is that you are better off making the low-tech solution robust rather than adding more features to the high-tech solution.

The fact that boot.ini allows for 11 million seconds is awfully generous.  If you are seriously going to argue that it should be no big deal to make it longer then you are not thinking with "one foot out of the box" and you are not considering the "low-tech" route.  In effect, you are arguing to make Windows even more complex than it already is.

"128 days is enough for everyone"

Alright, you sucked me in.

My guess is that it uses to BIOS timer tick, which by default is set to occur at ~18.2 times second (~54.9ms).

3600 seconds per hour x 18.2 = 65520 (0xFFF0)

Move along, nothing to se here...  :)

@Nicholas

The only problem I have is calling the proposed "solution" a solution at all.  It's more of a workaround.  Raymond didn't mention that multiple OS entries are required in the boot.ini file for this to work.  So a clueless user at a kiosk could come by and see something like "Please choose an OS within 100000 seconds" and just hit enter, causing the computer to boot before the wireless switch has restarted.  Even as a workaround it's not 100%

@J

Raymond didn't mention that detail because it is not important to his story.  I reread his blog post and it did not occur to me that a single kiosk will contain multiple operating systems or multiple configurations of the same operating system.

Let's be honest.  Do you really need a single computer inside a kiosk with multiple operating systems?  Or, do you really need a single computer inside a kiosk with multiple configurations of the same operation system?  No.  The situation is truly that simple, when the power turns back on the kiosks simply boot the normal operating system to resume normal business operations.

To complicate this simple example any further is to complicate the discussion and miss the point of the this blog entry.  Put another way, forget about kiosks and booting computers.  The principle of this blog entry is the following: You have a problem.  You can solve it one of two ways, the complex way or the simple way.  The complex way is to think inside the box and write complex software to complement complex software.  The simple way is to think outside the box and see that a simple low-tech answer can achieve the desired result.  Maybe the low-tech answer is a hack, maybe the low-tech answer is a proper solution.  That's a different story.

Tuesday, October 16, 2007 7:54 PM by Nicholas

"To complicate this simple example any further is to complicate the discussion and miss the point of the this blog entry."

That is untrue. I am all for simple solutions to problems instead of complex ones. However, a simple solution is only better than a complex solution if it does a good job and doesn't cause larger problems. Complicating the the discussion may be required in order to uncover places where the solution is not adequate.

These comments are great, but not as great as it would be to see the boot menu counting down from 11,000,000.

This question is similar to the maximum number of seconds you can delay a shutdown with shutdown.exe.  Using the -t switch you can delay up to 315359999 (0x12CC02FF) seconds, anything more and you get "The parameter is incorrect".  This is 3,649.999988 days which makes me wonder if 3650 days wasn't just an arbitrarily chosen limit.

LOL.  So shutdown can be delayed by 10 YEARS, but bootup can be delayed by "only" 128 days?  I guess that's a pretty safe limit, though; getting the uptime required to reach that limit would be quite impressive.

"But it's an interesting maximum because it's not the limit of any natural data type.  32 thousand or 2 billion would be more what one would expect.  Most likely the time is internally counted as days/hours/minutes/seconds with 1 signed byte for each.  It's probably code from when DOS was important that it just hasn't been worth changing."

Not possible... IIRC NT was recoded from the ground up to not rely on DOS anymore.  Plus that's when boot.ini was introduced... DOS had no comparative feature (config.sys boot menus don't really count since they're limited to the one partition anyway).

Also, some BIOSes let you configure a boot-delay, or even specifically a delay for the automatic power-on after power failure.

Argh, it's another numerology topic.

Why is it 11 million seconds? Even multiplying with 18.2 (the Bios Timer Tick value) doesn't give me 2^32.

If it's a 32 bit timer, it must be running at 390Hz, which seems too fast for Bios based stuff.

The downside is that when it's just this kiosk crashed and need a reboot, pressing the "reset" button next to screen (I assume it's kind of the common kiosk design I see in Universities), it'd requires a few minute to be ready to service again, instead of just be able to boot and login immediately.

This guy should just buy a cheap UPS battery for the wireless switch.

This article caused me to test editing the boot.ini file on one of my VMWares.  Apparently if you have at least 1 valid entry somewhere in the boot.ini, it can manage to figure out how to boot it.

It's kinda fun seeing how capable the bootloader is in loading Windows.

Marty: if the uptime of the power company is sufficient for their needs, why should they spend more money to improve on it?

My own guess is that the bootloader team had a deadline they had to meet in 128 days, so they couldn't test the "timeout = 129 days", so instead they made it 128.

No, I'm just kidding.

While the BIOS timer tick explanation sounds plausible, I'm going to put my money on another explanation, which also explains the 3650 day limit mentioned by Nick: the number is processed into a count of days, minutes and seconds (presumably for display purposes, although having never set a timeout longer than a minute I don't know for sure) and that conversion would fail with larger values (i.e., for bootup a signed byte is used to store the number of days, while for shutdown the formatting code wasn't designed to cope with more than one digit in the years column).

Sleep is not a synchronisation primitive.

Cheong, just hit enter.  If you can't get to the keyboard, you probably can't get to the reset button either.

Marty, even UPSes lose power, especially cheap ones.

I love how we now have 49 comments about the timer maximum...

MY first thought was: "Why would the timer actually fix the problem?"

The wireless driver doesn't start until after an OS has been selected.  So assuming the long time needed to restart the wireless device is the time needed for the driver to reset the device, find networks, connect, etc., how does this actually help?

Eric Wilson gets a -1 to reading comprehension.

But -1 is 0xffffffff in hex, used as an unbounded maximum in many Windows API functions.  So it's actually a complement.

Raymond's solution was good, except as someone mentioned in passing, it won't work in 99% of the cases of simple computers that have only one operating system listed.

To implement the workaround, in addition to changing the boot timeout from 30 seconds to whatever, you need to duplicate the single boot entry that is there so the boot process will actually count down.  There's nothing wrong with having two boot entries that are the same in boot.ini.

But yes, "normally" the 30-second timeout doesn't get invoked (on simple systems).

David

@John: a complement?  It's the complement of zero, if that's what you mean.

GregM: No. They make a little round metal button at the side of screen, whoever pressing it would hard reboot the kiosk.

And there's just touch screen keyboard, so no keyboard with enter key to press in text mode.

Ahhh old time GINA...

That time I had a lot of fun writing a mod of it...

Do Ben H. and Mark S. still work on that core OS components?

Cheers,

Ema! :-)

@Nicholas:

You think you are smart but you missed the point too -- isn't the simplest solution to REPLACE THE DAMN WIRELESS SWITCH?!?

Cheong, never seen a setup like that.

Igor, that requires a budget, which they may not have.

@GregM:

They have it, it is just a question where they will place it. Will they pay a programmer to create custom GINA, or an administrator to work overtime to change boot.ini on all machines or just go out and buy a decent wireless switch which gets ready faster than it takes for Windows to boot.

Oh I forgot, people love complicated solutions. A person I know once disassembled Sony Trinitron TV to bits trying to find out why it doesn't work anymore. Then my father came and determined that there was no power in the mains outlet to which the TV was connected. It just never occured to that person to check the fuse first and believe me that sort of backward thinking happens a lot in programming.

Igor, that may be true, but more than likely, the "pay a programmer" or "pay a [salaried] administrator" is already budgeted, and so it "doesn't cost anything" to do this.  If you've never had to deal with management that thinks this way, then you're VERY lucky.

Nothing particularly nefarious.