This topic was created by diodesign .
@Neil Alexander -
Only because linux on the desktop is clean, uncluttered, beautiful, smooth and bereft of chromey crud.
(Yes, these are extreme examples but they're also funny).
Or maybe the "maxiodatachunksz" constant which was used for splitting all IO requests since the glorious days of the first version of Windows NT - which was initially set to 64K, and never changed until Windows Vista. Ever wondered why your hard drives have these huge memory caches?
http://technet.microsoft.com/en-gb/magazine/2007.02.vistakernel.aspx
In the run up to the Millennium I checked a range of software to see if it could handle the previous century update. Most software that was date sensitive reported that the year 1900 was a leap-year.
It would be interesting to see if any of this non-compliant software remains in use.
non-compliant software
Yes, I can see that one being a really big, fat, hairy deal when the year 1900 rolls around again.
For older systems using 6-digit dates, I call that "expected behaviour"[1]. None of the test cases I saw for date handling around Y2K time had your idle curiosity as a consideration.
[1] Take two-digit year and divide by 4. Truncate the result to an integer and compare to the "full" result. If the same, it's a leap year. Known to screw up 1900 and 2100, but for the overwhelmingly vast majority of use cases this is not an issue. Even slightly. Important bit is it works for 2000, which is the only millennium late 20th-century software is ever going to see go past.
I have the *ahem* pleasure of being the maintainer for a suite of applications written in Turbo Pascal. One component, comprising roughly 250k lines is written in TP 3 and has never been "updated" to TP 7 due to the length and complexity (I seem to recall several estimates that it would take something like two man-years to do). In any case, there is a minor bug in one of the core routines that was written in about 1992 that the senior developers determined couldn't be fixed without said rewrite. So, we are now in roughly year 20 of this bug with no real hope of it ever being addressed. And yes, the code is still in use in hundreds of systems. Fortunately, the bug surfaces so infrequently it isn't *that* big of a deal, but it does take some effort to deal with when it does.
Yes, I've been using KDE since 1999, no I've never experienced this particular bug. (Don't get me wrong, there have been others...)
For me the point of the story is that the bug was noticed by someone with the skills and inclination to fix it. He didn't have to sign an NDA or otherwise trip up on someone's licence. He just fixed it.
Bugs can exist undetected for a long time if they produce the required effect most, or even all, the time.
We once moved an OS to new, but compatible, hardware. Rough testing had shown it would work. However when the official version was used - it kept misbehaving. The reason was that the OS filename had now been changed, for administration purposes, from "AAGJ1000" on the old hardware - to "AAKJ1000" for the new hardware. The third character was being mistakenly addressed as a flag byte for something totally unrelated. The required bit in the letter "G" had previously always steered the code down a proven path - but was reversed in the letter "K".
"How in Christ's name did you ever find that one?!"
When you are young in a new industry you do not to know that something is supposed to be "impossible". The system malfunctions - and it's your job as System Support to alleviate, diagnose, circumvent, and fix the bug in the developers' code or hardware - pronto. Usually such elusive bugs are found by a combination of serendipity, luck, and lateral thinking. It helps to have an obsession with trying to understand how other peoples' software/hardware designs "actually" interact - rather than how they all think it "should" work.
When I look back on some of my bug diagnoses it is amazing that I found the root causes in a short elapsed time. Many times it was a case of tripping over a pointer to the right answer whilst pursuing the "obvious", but wrong, answer. Unofficially I was the "lucky rabbit's foot". When all the specialist experts had failed to find the cause - then it was given to me. You don't learn that aptitude - but it takes a lot of practice to hone the talent.
BTW the title of "Wednesday" was meant to refer to a similar "wrong address location" bug - but I couldn't remember all the convolutions of that one.
...the Windows Registry.
If ever a long-standing bug needed stamping on, the whole concept of the registry must surely qualify?
Goes along with the concept that an application needs to be "installed" to the operating system. Applications should be separate from the OS for security reasons.
Not being independent is why OSs (particularly Windows) are open to malware. The OS should be COMPLETELY UNMODIFIABLE by any application. And as for DLLs - HELLO!?!?!?!?!? If you want a different subroutine, keep it IN your application, DON'T go modifying ones belonging to the OS.
This may all take up a bit more disk space but it would dramatically reduce malware.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
