6 ms·

49.7 days is equal to 2**32 milliseconds, after which Windows 95 crashes (https://web.archive.org/web/20010331174127/http://support.microsoft.com/support/kb/art

by wzdd 4y ago

49.7 days is equal to 2**32 milliseconds, after which Windows 95 crashes (https://web.archive.org/web/20010331174127/http://support.microsoft.com/support/kb/articles/q216/6/41.asp 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.

JTbane 4y ago
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.
- geoffdunbar 4y ago
  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.
drewrv 4y ago
I would hope there's a margin of error baked in and stuff doesn't break on day 52 exactly.
dundercoder 4y ago
The 787 runs on VxWorks though. https://blogs.windriver.com/wind_river_blog/2011/09/boeing-787-the-long-certification-journey-comes-to-an-end/ https://blogs.windriver.com/wind_river_blog/2011/09/boeing-7...
- nerpderp82 4y ago
  Running in a VM running on Windows.
- Someone 4y ago
  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.
  - 0xbadcafebee 4y ago
    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.
- wzdd 4y ago
  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.
  - phpisthebest 4y ago
    Though Somehow I would not be surprised if it were true
Someone 4y ago
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.

by wzdd 4y ago

JTbane 4y ago

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.

geoffdunbar 4y ago
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.

drewrv 4y ago

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

dundercoder 4y ago

The 787 runs on VxWorks though. https://blogs.windriver.com/wind_river_blog/2011/09/boeing-787-the-long-certification-journey-comes-to-an-end/ https://blogs.windriver.com/wind_river_blog/2011/09/boeing-7...

nerpderp82 4y ago
Running in a VM running on Windows.
Someone 4y ago
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.
- 0xbadcafebee 4y ago
  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.
wzdd 4y ago
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.
- phpisthebest 4y ago
  Though Somehow I would not be surprised if it were true

Someone 4y ago

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.