Wine/Cedega and fedora 3

Mike Hearn mike at navi.cx
Wed Dec 8 11:39:35 UTC 2004


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.




More information about the devel mailing list