Slashdot Mirror
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."
When my company eventually switched over to Vista, the software just took a few tweaks here and there, e.g, what can be found here. So far in our tests on the RC, we haven't *had* to run anything as a SU, and everything has been "curable" with little hacks here and there.
If you are smart, you are usually on software support anyway, and your publisher can help you out. When we tried AutoCAD Inventor in Vista/Seven, it was just a quick call to AutoDesk to get it working. My thoughts on legacy software? Stay away from it!!!
Apparently not. According to Microsoft partners (i.e. consultants), a team of 2 or 3 consultants can teach a team of 3 or 4 internal people to shim applications in a hands-on fashion. The majority of this training centers around teaching what the shims are and what they do, not actually fixing software. That's reserved for the last 2 days of the 5 day session. During that time the consultant claimed they would shim a minimum of 25 apps to provide a broad understanding for the internal people
Something the article doesn't mention is how the shimming actually works, unless you read the linked Microsoft document. Essentially you use ACT to scour your intranet for software. You can't just look in Add/Remove programs since enterprises are notorious for not actually "installing" apps. The program creates a database of all applications that don't work with Vista/7 and why not. Then you go through and apply shims to the database. Now whenever a program starts up it looks at its internal DB or the external DB (depending on if it's been started before) to see if there are any necessary shims. If there are, it uses them and the user shouldn't notice any issues.
To your point that it's a lot of work, 25 apps shimmed in 2 days by 3 people who are learning to do it is pretty quick. You can always hire the consultants to do it all for you anyway. Plus moving to *nix would definitely require a bunch of hacks on your current system (read a complete rewrite)
So maybe it's just in my area, but I always heard the word Shim as a reference to a shemale (she-him). Helping with Windows transitions... hrm.
Try getting a Lexmark all in one device to work while NOT admin - ain gonna happen. If you call up Lexmark to ask why their shits broke, they pawn it off on Microsoft. I spent quite a bit of time figuring out folders to change ownership permissions on to make that bastard work without giving admin to everyone.
The preceding post was not a Slashvertisement.
Vista has had these "shims" all along too. The filesystem and registry are virtualised, so any stupid program that tries to write to $PROGDIR or do anything else stupid has the changes re-directed to somewhere safe.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I'm reading the documentation right now, but I'm curious if it resolves the security problems. I'm guessing that a shimmed app is running in a sandbox? Or is the shimmed app given fully elevated privileges so that if gets compromised, the exploit code can still own the system?
Neither. The shim code just lies to the app and says it has admin rights, it's just like fakeroot in Unix.
You then write code in the shim to intercept any calls that really require admin rights and deal with them appropriately. If it's something dumb like wanting to write to something in the Programme Files directory you can redirect it to the users home dir. If it's something that really requires admin then you can ask for it and the user gets a UAC prompt.
Nick
The 20 to 30 apps you'll be breaking are not MS apps, but are (usually misbehaving) third party apps. Read the SimCity example from Joel.
It will be a long time before Wine will have this level of compatibility.
As I recall, "somewhere safe" is %APPDATA%\VirtualStore\Program Files\ etc or something that looks a lot like that. I can't check here because I'm at work and we use XP here.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
ISVs can create a "manifest" with their application telling Windows which shims need to be in-place to run the application correctly, without changing their code and without having access to the Windows source code. That's the point.
Microsoft already ships a compatibility checker utility: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971
But they can't force ISVs to run it, and they can't force ISVs to fix the problems it finds. What they can do is say, "hey, this shim is an easier fix than the compatibility checker you're already too fucking lazy to run" and hope that sticks.
Comment of the year
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.
> It depends on what they did to "compete unfairly". For example, it is not illegal for a vendor to have a contract with an OEM that the OEM could not buy a competitor's products if the vendor is not in a market monopoly position.
IIRC, they broke contracts, screwed over partners, and out-and-out stole other people's code and products. They lost several lawsuits over this, but the fines were small enough that they came out ahead. Wikipedia doesn't have as many details as I remember, but some of how they bent over Stac Electronics should give you an idea of the kind of games they played. There are also more recent things like this and this.
They've never been a nice company. They screw over their 'partners' more than anyone.