This topic was created by diodesign.
A minor cookie-handling bug in the KDE libraries since 2002 has now been fixed. This surely can't be the longest-standing code flaw? Anyone know of any more, perhaps even bugs allowed to stand because it would be impossible or unwise to fix?
For NDA reasons I can't say where...
but I'm currently having to write bug-compatible code against original Z80 code from 25 years ago...
And people say...
... that the open-source desktop is the future.
Re: And people say...
Indeed, because Windows and OS X have no long-standing bugs of a minor nature. They are all fixed within 5 minutes of being raised and patches released.
Oh wait, no they're not.
Re: And people say...
@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).
Re: And people say...
Aw hell, someone forgot to cancel the Anonymous Coward's sense-of-humour-ectomy!
Re: And people say...
Gets ridiculed on t'internet.
Tries to pass inane, anti-freedom drivel off as joke.
Bugs in Linux are fixed faster than closed source because of the eyeballs. Oh yeah.
Bugs in open source software are typically fixed in a time-frame that corresponds to their severity. This was obviously not hyper-critical.
Considering its backwards-compatibility nature, I'm pretty sure there'd be a raft of bugs in there that haven't been fixed in decades.
I can already think of one - the WMF vuln that was fixed in 2006 but existed since Windows 3.x - which was first released in 1990.
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?
Year 1900 Compliance
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.
Re: Year 1900 Compliance
C'mon, Excel still can't be made to read certain date formats out of a CSV.
"Any complex software package harbours all sorts of long-hidden bugs, some of which are probably never identified and fixed."
You know, whenever I try this reasoning on a Linux-booster with regard to a problem in some other OS, it gets shot down. Strange. Must be some misunderstanding.
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.
"I've never experienced this particular bug."
It trashes the cookies?
How the hell can this NOT be a "feature"? I have Chrome set to trash the cookies every 5 minutes - makes the webernet run much smoother.
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?!
"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.
Misc. bugs from the MS/PC-DOS 0.96 pilot build's command.com ...
... still exist in cmd.exe in Win8.
Re: Misc. bugs from the MS/PC-DOS 0.96 pilot build's command.com ...
Wasn't this an urban legend originating in the CP/M battle?
Y2K bug must've been 30+ years old and *everyone* knew about it...
Has no-one mentioned......
...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.
Services that run on port 445's according to SANS ISC... has varied though according to the graphs...