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.
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):
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.
The counter overflows/resets, everything wraps around, the system counts 6 more seconds, then Windows 95 freezes.
The mouse cursor still seems to work, but the message pump seems to have frozen, to the extent that End Task itself is unresponsive, and a second CTRL-ALT-DEL is needed to reset the machine.
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.
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.
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.
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 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
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?
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.
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.
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.
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.”
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.
So, it looked like what happened was the system didn't immediately crash, but quickly degraded. It looked like the system was partially responsive, and Foone reported that the ctrl-alt-delete screen wouldn't kill the app. The uptime monitor app hung, although it's unclear where that failure originated from.
(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.
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.
I'm curious what actually causes these effects. The counter rolls over --- so what? The maths still works fine over a wraparound modulo 2^32, and the tick counter is definitely treated as unsigned by the relevant code, or the symptoms would've appeared in half the time at 2^31. Unless there were some misguided/overly-paranoid attempts at overflow checking?
As someone who has written Win3.x/9x drivers for much newer hardware just to see if it could be done, I'd love to read an in-depth analysis of this bug, like https://www.os2museum.com/wp/those-win9x-crashes-on-fast-mac... --- if I had more time I might get around to doing it myself, and ultimately coming up with a patch to fix it.
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 gave my kid an old Toshiba with Win95 when he was 3 years. He is now 5 and still likes to use it. His favorite programs are Minesweeper, Word and MSPaint.
Thinking about upgrading to Raspberry Pi Keyboard.
Maybe we should try the 49.7 days overflow as an fun example in memory overflow.
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.
I'm a little annoyed at how anti climatic it was. I had a windows 95 machine (chunky IBM laptop) when I was 12, there's plenty of ways the crash could've been shown off a little more. System freezing all of a sudden was a daily occurrence, not much to write home about.
Windows is one thing, but I heard that Warcraft 1 or 2 had a patch to fix a crash that occurred after the game ran for three weeks. The mystery, to me, is how the hell did someone discover the problem.
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...