Hacker News Reader

Comment by wzdd | Hacker News Reader

49.7 days is equal to 2**32 milliseconds, after which Windows 95 crashes (https://web.archive.org/web/20010331174127/http://support.mi...). That's close-ish to 51 days. Maybe they start the counter with a value other than zero.

View on HN

The 787 runs on VxWorks though.

https://blogs.windriver.com/wind_river_blog/2011/09/boeing-7...

Running in a VM running on Windows.

FTA: Editor's note: An earlier version of this article mentioned the Boeing 787 CCS uses a Wind River VxWorks real-time OS product at its heart. While this is true, Wind River has been in touch to remind us "the CCS is made up of 80 to 100 applications," as well as VxWorks, and said the bug described in this article is not the fault of its operating system.

"The functions of VxWorks have nothing to do with the data issue you are highlighting in the 787," a spokesperson added. We are happy to clarify our coverage.

VxWorks is the only software in the entire system that I would not question. Sadly, somebody has already added this thing about the airplane to VxWorks' wikipedia page.

I didn't mean to imply that the 787 ran critical infrastructure on Windows 95, just to give an example of a system which was affected by a timer overflow of about that duration.

Though Somehow I would not be surprised if it were true

I immediately though of the GetTickCount win32 function, which, as you said, wraps around to zero every fifty days or so. A lot of programs would crash if you left them open for this long.

I worked at Microsoft on the NetShow Encoder, later known as the Windows Media Encoder, in the Windows 95/Windows NT4 era. I remember carefully writing millisecond code that would deal with differences, instead of absolutes, so that we could run longer than 49 days. Honestly I don't recall whether the limitation was GetTickCount, the recording API, the file format, or all three.

In our debug build, I added a registry key that would start the concept of time at 49-ish days, so that we could test that everything was working without waiting 50 days. However, before we shipped, the intrepid test team did actually run the encoder for 50 days to prove that it worked. (On Windows NT, of course. Windows 95 with good hardware and drivers was perhaps more stable than its reputation, but still...) Though TBH we definitely wouldn't have delayed a release by 49 days if it had failed at the last minute.

Or maybe there’s an error in that calculation of 51 days. 49.7 times 1.024 is 50.8928, so there could be a 2¹⁰ = 10³ error in there.

I would hope the advisory leaves some room for error in the reboot interval, though.

I would hope there's a margin of error baked in and stuff doesn't break on day 52 exactly.

Reply on news.ycombinator.com