It is already the case (mostly thanks to an odd decision on AMDs part when designing AMD64) that you can't run 16-bit apps on a 64-bit Windows without some 3rd party emulator. This includes both DOS apps and 16 bit Windows apps, so really the backwards compatibility at least for 64 bit OSes is only going back 18 years.
And what is needed to support 32-bit Windows 95 apps is pretty much a subset of what is needed for current apps anyway, so there is no extra overhead being introduced.
The recent TIFF file security hole has nothing to do with backwards compatibility/legacy code. There is nothing in the TIFF format that allows executable code, that is a buffer overflow exploit in the specific decompressor for it. The NX MMU bit was added specifically to prevent this type of bug from being a security hole, and you can turn that protection on in Windows XP SP2 or later under Control panels->System->Advanced Tab (or advanced system settings link)->Performance section "Settings" button->Data Execution Prevention tab.
Why turning DEP on for all apps isn't a default by now almost 10 years after the feature was introduced I don't know. When Vista was released there were still enough apps that did self modying code triggering DEP to kill them that it made sense to not be a default. But by Windows 7 (and therefore obviously for 8) it should have been the default IMO. My guess would be because it still breaks some codecs, especially DivX, so you end up adding media players as exceptions. (Can't they tell DivX to fix their code?) Or simply not using DivX, since Windows 7 has built in H.264 support and all DivX is really buying you now is MKV container support, which you can get from Gabest or Matroska filters. In fact it is kind of sad nothing from the large variety of "Security Suites" out there doesn't prompt you to change this for you, maybe with a default list of exceptions for known problem non-malware apps like DivX.
Most current malware relies on user stupidity (i.e. spreads by having someone execute an e-mail attachment), and has nothing at all to do with legacy support.
Edit: Reading some more on the "TIFF" vulnerability -- it apparently defeats DEP, but the way it does that, the main problem isn't with the TIFF codec IMO. It requires an office document with embedded ActiveX controls that allocate tons of memory areas with the NX bit cleared, so that the overflow is into one of those memory areas. An ActiveX control could do this on its own without TIFF anyway, and it means there is a security warning about the control even being there when you open one of these malicious documents.
It does remind me of one other thing that could be done along the lines of "breaking backward compatibility for security as you were saying... but you would be breaking it a lot worse than you think. A new security feature of Vista and later is an executable flag to allow ASLR (address space layout randomization), so that hackers can't predict where in memory data used by an application will reside in order to exploit it. For 64 bit apps, this is not too bad. I don't actually know of any x64 binaries that would break if it were turned on. For 32 bit apps, it would be a real mess. A lot of applications rely on being able to get a large (at least hundreds of megs, in enterprise sometimes close to 3GB) contiguous allocation. Having the DLLs and other process initialization allocations loaded at randomized locations first fragments the heap to make that contiguous block not available, and this would cause a significant portion of the 32-bit apps out there to crash. Because many applications would break, this flag is defaulted to be turned off -- the application builder has to explicitly indicate their compatibility, and not that many do. In fact, the first compiler to allow you to do so was VS2008 -- MS could theoretically make a future OS where every process had ASLR turned on, but even for apps that worked most of the time in 32-bit, the virtual memory fragmentation makes it only really practical either for apps that don't need to deal with lots of data, or a pure 64-bit world -- not just a 64-bit OS, but ditching almost all 32-bit apps.
Facebook
Twitter