3 ms·
Adobe had a bug which worked because of a Bug in memcpy(), the bug was fixed and Adobe's code broke. win95 had a similar one with the game Civilisation, they a
by kjhgfghjm 16y ago
Adobe had a bug which worked because of a Bug in memcpy(), the bug was fixed and Adobe's code broke.
win95 had a similar one with the game Civilisation, they actually put code into win95 to detect the game and change the way the OS worked - doesn't sound like a good solution
- ot 16y agoI guess you are referring to this: > I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it [...] the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it. (from http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html )
- flomo 16y agoWhat? The whole raison d'être of Windows 95 was backwards-compatibility with primordial PC junk. The entire thing was a hack from top-to-bottom, far beyond a workaround for a particular game. Also, to quote Linus: "And what was the point of making [an OS] again? Was it to teach everybody a lesson, or was it to give the user a nice experience?"
- azernik 16y agoRead the spec for memcpy: memcpy's behavior on overlapping memory regions is undefined - not "required to corrupt memory", but undefined. Changing memcpy from not breaking on overlapping memory regions to breaking does not fix any bugs. Adobe should not rely on non-spec-defined behavior, but there's no reason why glibc <i>should</i> be making this change without making a major version number change.