Funny thing, programming the clocks in assembler at the time of the moon landing was extraordinarily hard, especially since they had to code the timestamps in negative.
(Feels like a bit of a silly Gotcha! to do it live now - did anyone run their personal computer for 49 days, even counting laptops which went to sleep/standby? But hey, do what you want. :)
This wasn’t a limitation anyone ran into in the real world. I was lucky to get the original windows 95 to run for a day, let alone 49. Windows 95 OSR2 on the other hand was very stable. My most stable desktop from that era (late 90’s / early 00’s) was a debian stable build, the uptime at one point was over two years.
In the late 90s to early 2000s I worked in the Network Planning & Design group for UUNET. They were phased out before I left but when I started Fore/Marconi ATM switches were used for interconnect within PoPs and to terminate the circuits between PoPs. For a while the NOC had to reboot them periodically at a scheduled time or else they would reboot themselves after a certain period of time. I believe it was 45 or 90 days.
Long time lurker but I had to create an account to comment. My first job out of college was at Fore Systems/Marconi back in 2000 as a QA tester. One of my first assignments was to test bug fixes for several different uptime issues we had. My favorite was the PNNI 397 day uptime where it would flap a port causing the switch to relearn all its SPVCs.
Fore/Marconi was a great place to work back then but the dotcom bust and the migration to pure IP/MPLS was a death knell to them. My entire division was laid off in Oct of 2001. I was lucky and had jumped ship only weeks earlier.
Having used Windows 95 back in the day, I am deeply impressed someone managed to keep it from crashing for so long.
I have seen a Windows NT 4.0 system with an uptime of more than five years, but with Windows 95, even a whole day of uptime was pretty close to a miracle.
If so, that’s not a Windows NT license, but an add-on that allows five users (¿at a time?) to connect to a Windows NT system that requires its own license to run, isn’t it?
It's probably pretty easy if you do literally nothing on it.
Windows 95/98/Me had a very weak concept of protected memory. It was there, but it wasn't very hard for an application to go read and write into the virtual memory space of other processes. Even then, any semblance of protected memory only existed for Win32 applications. DOS and Win16 programs, both of which were very common at the time, would just have free reign over everything.
I used 98se for a long time, well into the Vista era --- and indeed the lack of protection affects stability, but that also means the stability is directly related to what software you run; and indeed if you regularly used the mass quantities of sub-par "shovelware" that was prevalent in those days, it would definitely make it seem like the OS was crashing constantly, when it was actually the software you added on top that caused it.
On the other hand, I didn't have much of a problem maintaining multi-week uptimes simply due to the fact that I kept the system relatively "clean" and wasn't trying out new apps every day.
It's long bothered me that Windows got a reputation of being an unstable OS when the issues were caused by poorly written software. Things got better when they moved over to the NT kernel, but drivers were still a frequent cause of BSODs since they ran in ring 0. A combination of WHQL certification and getting drivers to run in user mode instead of kernel mode has helped significantly with stability.
To be fair, not crashing under poorly written programs is a fundamental part of OS stability. Windows at the time had no resiliency against a CS101 student messing up on an assignment, it was unstable.
I had once a Win 98SE PC as a second system, mostly used for testing MSIE and accessing the company Outlook. (My production machine was a Mac running System 7.x. and System 8.) But it was also used by interns for production, running Photoshop, etc. I actually do not remember it crashing once. But this is probably quite averse to the common experience. However, it does seem to second your assumptions, as it had only a few "quality" applications installed.
I only ever used Windows ME for a while after starting to use Linux as my main desktop, so I could watch DVDs - CPUs back then were not quite fast enough to decode DVDs in software, and my MPEG decoder card was not supported on Linux.
It never gave me any trouble, but I admit this is not a representative use case. ;-)
I had Windows NT 4.0 with SQL Server 7.0 running for 6 years... never restarted (or patched)... This was our dev/qa server. Uptime from 1999 till October 2005.... then some fool shutdown the power to the whole dev cage....
Still remember the credentials too... sa and password Nimda
I feel like a fool this somehow put a smile on my face :)
And my memory may be hazy, but in those days Windows always crash every few days and we normally "shut down" our computer after usage.
But the most interesting thing is a running Windows 95 in English version. May be screenshot [1] weren't hard to come by. And we are lucky nuke didn't happen in 2020.
Nowadays I usually let my notebook hibernate (not sleep) for the night and when I return the next morning, I often discover that I forgot to stop my debugger and it is still attached to my running program. Not even a hiccup when resuming.
Heh. In the meantime, here I am having to software-reset my network card after almost every resume. Thankfully, like beer, Linux is the answer to _and the cause of,_ all the world's problems.
Microsoft used to release a "checked" build for each version of Windows on MSDN/Visual Studio Subscription downloads. [1] This was a build with the same compiler optimization settings as the release build, but with debug-build-only assertions and checks included. In the checked build kernel, the system uptime had 49 days artificially added to it [2], precisely to help developers find out problems like this.
At one point when I was on the Windows team at Microsoft, there was an internal push for us to selfhost (dogfood) checked builds of Windows, since they theoretically provided better bug telemetry than "free" builds (release builds, which are free of debug-only code). "Slows your dev box down by just half!" was the basic pitch of that campaign in a nutshell.
[1] I don't know if this was ever done for Windows 95. It was done for Windows XP up to Windows 10 version 1511, but it appears to have stopped since then, at least according to my quick search.
If you are a current Visual Studio subscriber with access to Windows downloads, chk builds are available on https://my.visualstudio.com/Downloads/Featured like regular builds. Search for "checked".
I don't recommend chk builds for routine use by anyone outside the Windows teams because even if the regular Windows release still receives updates, the chk build typically doesn't. CDN disk space isn't cheap, and neither is CPU time on the build or test machines.
A quick poke over at https://the-eye.eu/public/MSDN/ suggests the following (there may be more checked builds hiding in the sea of Latin filenames :P):
Some time back I did work at a devices startup processing data collected from trial runs. For some reason an earlier developer had chosen to use time-of-day, in seconds, rather than elapsed time, as the index for data recording. I'd registered this as a poor design decision, though it was difficult to articulate why.
That argument became far easier after a field trial spanned midnight, and the data series iterated from 86,400 to 0.
On the other hand, I've never had trouble remembering just how many seconds (or minutes) there are in a day, since.
The term ‘clock rollover’ reminds me of the 2007 incident where 6 F-22’s crossed the date line:
> “…At the international date line, whoops, all systems dumped and when I say all systems, I mean all systems, their navigation, part of their communications, their fuel systems.”
Back when we were writing alt shells for Windows 95/98/2000 (geoShell, Litestep, etc) uptime plugins/modules were all the rage. Screenshotting and sharing were popular and came with bragging rights.
I love this, and I don't understand why. Maybe it's the nostalgic combo of a physical midi synth with a physical pentium waiting for win95 to do what it's best known for.
Semi-related but I recently bought a knock off windows 95 t-shirt because I wanted a shirt with something old that would be recognizable but not mistaken for nostalgia. Kinda like a "oh yeah that used to be big" feeling.
It's weird how we can have things that are extremely well known / commonly used in our culture that suddenly disappear as soon as something better comes along never to be thought of again.
Longest lived non embedded system I've worked with was a Linux server with an uptime from 2007 through 2019 serving as a L3 router. Amazingly, after shutting it down, it turned on again :)
Yes. I forgot to maintain a Linux server after setting autoupdates, and it kept itself up for years. I’m ashamed of not monitoring the potential breaches on it.
Completely off-topic but yesterday I upgraded my Debian 10 home server to 11 and it rebooted fine! It had a 132 day uptime on it.
I run a unify controller on docker, pihole, influxdb, grafana and a bunch of other small scripts. I did need to upgrade my collectd Python modules to 3 but that was it.
I'm scared to even think about the NAS in my attic. It's running firmware based on a long dead version of Debian. I have no idea how long it's been running without a reboot but I'm guessing 2+ years.
The counter rolled over, then the system hung at about 6800 ms after the rollover.
The mouse responded and a ctrl-alt-del brought up the process-manager / restart dialogue, but the system didn't respond otherwise. It was restarted with a second ctrl-alt-del.
Final song was Toto's "Africa", followed by the theme to Terminator.
If the stream remains up, the next crash will occur on October 17, 2021.
Looks like the integer overflow had the system time try to start back over at zero, but that caused everything else to hang right after it did. Neat stream.
99 comments
[ 3.1 ms ] story [ 40.2 ms ] threadHow do they capture the screen output from the real CRT ?
News coverage at the time (2002 or earlier): https://www.cnet.com/news/windows-may-crash-after-49-7-days/
(Feels like a bit of a silly Gotcha! to do it live now - did anyone run their personal computer for 49 days, even counting laptops which went to sleep/standby? But hey, do what you want. :)
Fore/Marconi was a great place to work back then but the dotcom bust and the migration to pure IP/MPLS was a death knell to them. My entire division was laid off in Oct of 2001. I was lucky and had jumped ship only weeks earlier.
I have seen a Windows NT 4.0 system with an uptime of more than five years, but with Windows 95, even a whole day of uptime was pretty close to a miracle.
I think he's referring to CAL
Windows 95/98/Me had a very weak concept of protected memory. It was there, but it wasn't very hard for an application to go read and write into the virtual memory space of other processes. Even then, any semblance of protected memory only existed for Win32 applications. DOS and Win16 programs, both of which were very common at the time, would just have free reign over everything.
On the other hand, I didn't have much of a problem maintaining multi-week uptimes simply due to the fact that I kept the system relatively "clean" and wasn't trying out new apps every day.
It never gave me any trouble, but I admit this is not a representative use case. ;-)
Still remember the credentials too... sa and password Nimda
No issues ever... HP hardware....
And my memory may be hazy, but in those days Windows always crash every few days and we normally "shut down" our computer after usage.
But the most interesting thing is a running Windows 95 in English version. May be screenshot [1] weren't hard to come by. And we are lucky nuke didn't happen in 2020.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Nowadays I usually let my notebook hibernate (not sleep) for the night and when I return the next morning, I often discover that I forgot to stop my debugger and it is still attached to my running program. Not even a hiccup when resuming.
# echo 1 > /sys/bus/pci/devices/0000\:0b\:00.0/remove # echo 1 > /sys/bus/pci/rescan
At one point when I was on the Windows team at Microsoft, there was an internal push for us to selfhost (dogfood) checked builds of Windows, since they theoretically provided better bug telemetry than "free" builds (release builds, which are free of debug-only code). "Slows your dev box down by just half!" was the basic pitch of that campaign in a nutshell.
[1] I don't know if this was ever done for Windows 95. It was done for Windows XP up to Windows 10 version 1511, but it appears to have stopped since then, at least according to my quick search.
[2] https://docs.microsoft.com/windows/win32/api/sysinfoapi/nf-s...
EDIT: if you want to get the actual build, I can't help. I only remember it being available through MSDN AA back in the day.
I don't recommend chk builds for routine use by anyone outside the Windows teams because even if the regular Windows release still receives updates, the chk build typically doesn't. CDN disk space isn't cheap, and neither is CPU time on the build or test machines.
https://the-eye.eu/public/MSDN/Windows%207/
- en_windows_7_debug_checked_build_dvd_x64_398741.iso
- en_windows_7_debug_checked_build_dvd_x86_398742.iso
https://the-eye.eu/public/MSDN/Windows%20XP/
- en_windows_xp_professional_x64_chk.iso
Some time back I did work at a devices startup processing data collected from trial runs. For some reason an earlier developer had chosen to use time-of-day, in seconds, rather than elapsed time, as the index for data recording. I'd registered this as a poor design decision, though it was difficult to articulate why.
That argument became far easier after a field trial spanned midnight, and the data series iterated from 86,400 to 0.
On the other hand, I've never had trouble remembering just how many seconds (or minutes) there are in a day, since.
Not everyone is so fortunate: https://news.ycombinator.com/item?id=7717414
Not all days have precisely 86,400 seconds.
For longer intervals, not all months have 28, 29, 30, 31, 30.43685, whatever, days. Not all years have 365 or 366 days, etc.
Pull out your copy of "Myths Programmers Believe About Time" and read it, hard. It will bite.
> “…At the international date line, whoops, all systems dumped and when I say all systems, I mean all systems, their navigation, part of their communications, their fuel systems.”
https://www.defenseindustrydaily.com/f22-squadron-shot-down-...
Now I'm really curious of how time is managed in jetfighters, but couldn't find a good article on the subject.
It's weird how we can have things that are extremely well known / commonly used in our culture that suddenly disappear as soon as something better comes along never to be thought of again.
I run a unify controller on docker, pihole, influxdb, grafana and a bunch of other small scripts. I did need to upgrade my collectd Python modules to 3 but that was it.
Yep, it was funny.
The counter rolled over, then the system hung at about 6800 ms after the rollover.
The mouse responded and a ctrl-alt-del brought up the process-manager / restart dialogue, but the system didn't respond otherwise. It was restarted with a second ctrl-alt-del.
Final song was Toto's "Africa", followed by the theme to Terminator.
If the stream remains up, the next crash will occur on October 17, 2021.