On Tue, 07 Dec 2004 23:43:48 -0800, Kenneth Porter wrote: > Makes me wonder if MS has the same problem when it wants to modify its > kernel. Yes they do, see the /3gig switch to the kernel. Changing the VM layout in this case revealed a lot of code which assumed it'd never get a pointer above the 2gig boundary so they stored information in the high bit of pointers, etc. The now-disabled 4G/4G VM patch on Linux showed the same problem. So you can modify the address space, but you have to manually enable it. Perhaps if it was a more widely wanted feature they'd have put code in to enable it on an app-by-app basis. It's not just the kernel. Same problems occur when they want to modify anything, really. They have multiple dedicated app-compat teams which buy/download software and regression test it. They also have an advanced patching/shimming system so some of the most broken software can still work. That's common when a program checks the result of GetVersion() and refuses to run on anything but Windows 95 exactly, for instance. The thing is, their programmers salaries are directly linked to upgrade sales so, outside of a few power-play examples, they take great care not to break things. Because they have such a huge base of software relative to Linux, and because they value backwards compatibility so highly, that means they have to move slower and sometimes not make a certain change because it'd break stuff. That's a simple equation: the utility of a feature is outweighed by the negative utility of the breakage. Once Linux gets as widely deployed as Windows is, it'll have to move much slower too. Oh sure the patches may be written even faster, but that doesn't mean people will actually be *using* them. In the specific case of execshield, compatibility issues aside the way they implemented shared libraries would make it very hard to do efficiently.
