MS Suggests Using Shims For XP-To-Win7 Transition

eldavojohn writes "Windows XP (and a lot of MS OS code before that) had a fundamental security flaw whereby the default setting made the ordinary user run as the superuser. Vista & Windows 7 have fixed that and implemented The Correct Paradigm. But what about the pre-Vista applications written to utilize superuser privileges? How do you migrate them forward? Well, running a virtualized instance of XP in Windows 7 is an option we've talked about. But Microsoft is pushing the idea of using 'shims,' which are a way to bypass or trick the code into thinking it's still running as user/superuser mode in Windows XP. This is an old trick that Microsoft has often employed, and it has brought the Windows kernel a long ways, in a duct-tape sort of fashion. At the TechEd conference in LA, Microsoft associate software architect Chris Jackson joked, 'If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps.' So for you enterprise developers fretting about transitioning to Windows 7, shims are your suggested solution."

Comments

I know you slashdotters hate to hear it

[Anonymous Coward]

But MS's support for backwards compatibility is THE REASON they own the desktop.

You can slam all you want, but they will continue to own the desktop because they run all the apps you want.

Re:I know you slashdotters hate to hear it

[WMD_88]

Just to play devil's advocate, linux runs any X11 app and that goes back decades and decades (e.g., nethack is from 1985).

Nethack may be old, but the binary you use on Linux was compiled recently. Set up an old Linux system (RH 6.2, to throw something out there), run Nethack on it, and then try to run the same binary on a new system. It won't work.

Having the software be open-source alleviates most of this, but closed-source will never work too well on Linux unless they stop breaking everything all the time.

Re:I know you slashdotters hate to hear it

[EvanED]

The whole reason shims exist is because the APIs change over time, so what was correct usage in Win2000 or WinXP might not be correct in Vista or 7.

Well, depending on how you interpret that statement, that's only part of the reason, because MS rarely breaks an API in a backwards-incompatible way.

There are basically two reasons why software stops working on windows:

1.) It makes assumptions that are at a higher level than what the API does. For instance, that the user is running as administrator. At least on the NT line, it has never been the case that the API has "allowed" a program to assume that a requested access to HKEY_LOCAL_MACHINE will succeed, or that it can write to Program Files. (Starcraft crashes at the end of a game when run as a limited user under XP -- presumably because it tries to write LastReplay to Program Files.) Even if the API can theoretically return an 'access denied' error, the programmer assumes that it won't actually arise in practice.

Another example of this is DOS programs that assume they can access the hardware directly and stuff like that, which "of course" doesn't work under NT.

2.) It makes assumptions that are not part of the API proper, but just artifacts of the implementation. For instance, assuming HANDLEs (which the API says should be opaque) are pointers which can be directly accessed (which is true in version A but not true in version B). One good example of how subtle this can be is a shell namespace extension that implemented a function signature wrong by giving the wrong number of arguments. This creates the strong potential for stack corruption. On Windows 95 and NT 4, it worked because Windows was compiled with frame pointers, which left it robust to that error. With Windows 2000, Windows was compiled with the frame pointer optimization, which meant that program crashed Explorer. At no point was "Windows will be compiled with frame pointers" part of the API.

(Then there are higher level problems of a similar nature. There are programs that will open up the display properties dialog then send tab messages or otherwise enumerate the controls present, then change, say, the fifth control so it has the setting they want. What if MS changes the tab order or adds a new control? Boom.)

So if you say that "the APIs change over time" means that their defined behavior changes, this is the decidedly minor aspect of compatibility problems. It's only if you allow implementation-specific details to creep in (which I don't consider part of the API) that your statement is true.