Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Windows Operating Systems Software Programming Upgrades IT Technology

MS Suggests Using Shims For XP-To-Win7 Transition 316

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."
This discussion has been archived. No new comments can be posted.

MS Suggests Using Shims For XP-To-Win7 Transition

Comments Filter:
  • by Anonymous Coward

    I thought it said "shivs". I guess that would be another way to coerce people into giving up their precious XP.

    • 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
      • by MrNaz ( 730548 ) * on Friday May 22, 2009 @01:20PM (#28056151) Homepage

        You can't always stay away from legacy apps. Legacy apps are made to fill a need that a particular company has in a particular situation. This usually means that when their app is finally put up against the wall, their choices are either stick with the entire old ecosystem, OS and all, or rewrite from scratch.

        Given finite budgets and a culture that values returns *this* quarter at the expense of every future quarter, guess which option gets picked most often.

      • Re: (Score:2, Interesting)

        by Tanktalus ( 794810 )

        I'm just curious ... what's the difference between having to shim ENTERPRISE CLASS SOFTWARE and, oh, say, just switching to Linux? Seriously, is this less work?

        • Re: (Score:3, Insightful)

          by skiflyer ( 716312 )

          Yes, training is almost always more expensive than the change.

          Let's take a small company using enterprise class software... say 15,000 employees. And let's pretend you pay them squat, $10/hr. Means it costs you $15/hr at least to have them.

          So every hour you spend training costs $225,000 ... windows -> linux would likely be a 4 hour afternoon session, so you're knocking at a million dollars just for your employees time. You haven't even paid the trainers yet, and this won't be one massive webinar, you're

          • Re: (Score:3, Insightful)

            by PitaBred ( 632671 )
            Sure, it costs money to switch. The problem is that MBA's don't understand (or don't care) how much just supporting the current system costs. How much do you spend on Windows licenses? How much on individual software licenses? Software maintenance and ongoing training (every time a virus hits...)? Doing one side of the costs of switching is necessary, but don't forget to calculate the costs of NOT switching.
            • Re: (Score:3, Insightful)

              by skiflyer ( 716312 )

              That's not just people being stupid. The assumption is the cost to support one is close enough to the cost of supporting the other to disregard any differences.

              The obvious issue bandied about for Linux - additional support cost (pricier personnel, fewer contracts/vendors, etc.) vs. the MS licensing cost.

              Mind you I'm not agreeing or disagreeing on this particular example, but there is a why.

          • by cbreaker ( 561297 ) on Friday May 22, 2009 @04:30PM (#28058887) Journal
            Since when does a small company have 15,000 employees?
    • Re: (Score:2, Troll)

      by CarpetShark ( 865376 )

      I thought it said "shivs".

      It said "shills".

  • by Anonymous Coward on Friday May 22, 2009 @12:45PM (#28055641)

    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: (Score:3, Insightful)

      Yep he's right.

      Not aggressive marketing or flagrant violation of antitrust laws. Certainly not stability of security. Inovation? Forget it.

      It's backwards compatibility for the win, ever since version 1.

      • Re: (Score:3, Insightful)

        by x2A ( 858210 )

        "It's backwards compatibility for the win, ever since version 1"

        Except version one wasn't exactly a 'win'... or two... three was where it really started taking off.

        Of course the fact that you could still run your old DOS programs was quite the benefit as people had a lot of them... oh no, there goes your argument!

        "or flagrant violation of antitrust laws"

        hint: they had to become a monopoly power first!

        • by jimicus ( 737525 )

          "or flagrant violation of antitrust laws"

          hint: they had to become a monopoly power first!

          Microsoft were competing unfairly long before they became a monopoly, and this is also illegal.

          Competing unfairly in ways like only offering discounts to companies that don't stock competing products - discounts so large that anyone who wanted to stock a competing product basically could not hope to sell anything by Microsoft at a competitive price.

          • by mea37 ( 1201159 ) on Friday May 22, 2009 @01:39PM (#28056483)

            "Microsoft were competing unfairly long before they became a monopoly, and this is also illegal"

            Citation needed.

            The example you gave is not illegal unless you wield undue market clout (such as that held by a monopoly). That is the case with any "unfair competition" law I've heard of - it's only unfair if competition in your market is limited (e.g. because you're a monopoly or because you and a few other players collude to maintain a collective strangle-hold on the market).

          • "or flagrant violation of antitrust laws"

            hint: they had to become a monopoly power first!

            Microsoft were competing unfairly long before they became a monopoly, and this is also illegal.

            IANAL, but...

            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.

            On the other hand, it is illegal for them to bribe, blackmail, or threaten someone to sign the contract.

            To summarize - my point (and the GP's point) is the antitrust laws define a monopoly, and unless the entity falls into that definition there is a lot they can do that they couldn't do otherwise. Anti-trust laws only limit what a monopoly can do - not everyone else.

          • Re: (Score:3, Interesting)

            by hairyfeet ( 841228 )

            Oh please! Look up the dirt on Commodore, or any of the other players then. They were ALL screwing somebody over. Remember this "Greed is good. Greed works" Wall Street? That was the whole culture then. It was Reagan and trickle upon you economics. Then are plenty of stories of Commodore screwing vendors and suppliers and anybody else that would give their company an advantage.

            Face it-They all did it, Bill Gates was just meaner. But don't worry, I predict that MSFT will just keep slowly sinking year after y

        • The argument is that it's ridiculous to suggest that backwards compatibility is "THE REASON" for MS's success - particularly without presenting evidence of competitors who losing market share due to poor performance in this area.

          Backwards compatibility isn't even that strong for MS. Windows XP broke plenty of apps (do a few searches the 'Why Applications Break' section of []

          • by x2A ( 858210 ) on Friday May 22, 2009 @01:44PM (#28056567)

            "The argument is that it's ridiculous to suggest that backwards compatibility is "THE REASON" for MS's success"

            I don't think the word 'the' was meant to be taken as a literal definite article, sometimes people exagerate to demonstrate their point as a shorthand way of explaining that the actual extent of their point is large enough to warrent exageration. It's something I personally prefer to not do, but I don't think it's too much of a problem when people do.

            I don't think anyone's going to suggest that MS OS's are perfectly backward compatible; sometimes things do need to change, and sometimes things rely on bugs that shouldn't be left open, but in all my own personal experience, they do win hands down next to Linux and Apple (I can't comment outside the scope of those three). Say what you want about "having the source code", but when things need certain versions of libraries for certain APIs, or relied on the way a particular version of GCC compiled their code that's now no longer the case, things don't stay so black and white. Yes I've been able to update a lot of old code myself to reflect changes and get it to compile, but there's still an awful lot I can't.

      • by sjames ( 1099 ) on Friday May 22, 2009 @08:04PM (#28061027) Homepage Journal

        That's why I refuse to get one of those newfangled autoMObiles until it knows what Giddap and Woah mean. I tried on once, but no matter how much I yelled or whipped it, it just wouldn't move.

    • 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.

    • Re: (Score:2, Flamebait)

      I don't dispute that most apps designed for older versions of windows run okay on newer versions, but you haven't given any evidence at all as to why this might be true. Just to play devil's advocate, linux runs any X11 app and that goes back decades and decades (e.g., nethack [] is from 1985). Also, often apps that runs on OS X can run on any version of OS X but there were some changes between point releases but I don't know of an app that fails to run on new versions. Also, the X11 server lets you run any
      • 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.

    • Agree and one can also not discount the WIN32 API and Visual Basic either. I loath them both at this stage in my career but they are what I and many others started on and there are thousands, if not more then a million, internal business apps running on both these technologies. The lure of easy was just too hard to resist, not to mention marketed brilliantly, (criminally even!) by MS.

      You're right, ./ers hate to hear it, I hate to hear it or say it, but your right.

    • Re: (Score:3, Interesting)

      It's certainly not the ONLY reason.

      Solaris has great backwards compatibility. Better than Windows, even, and not by a small margin, either. I am running a copy of xemacs today I compiled in 1997 or 1998... 5 major OS revisions back. You can even run third-part device drivers meant for 2.4 on 10 with a reasonable expectation that they will work, and work well. You can even run applications built for SunOS 4 and expect many to work. And SunOS 4 -> Solaris 2 was a major leap. About the same sized leap as M

      • We all know that Solaris doesn't own the desktop. Hell, I'm a Solaris fan as AFAIC they don't even HAVE a desktop.

        Just FYI, they _do_ have a desktop--at least, OpenSolaris does.

        I really liked what I saw when I tried out the OpenSolaris livecd, but I don't have a valid reason to run it anywhere, so I can't comment on the long-term quality/usability.

    • > they will continue to own the desktop because they run all the apps you want.

      Yeah, how's that iPhone dev work going for you? Xcode and the simulator working smooth, eh?

      Talk about termites stuck in amber...

    • by Z00L00K ( 682162 )

      And it's also the reason why we are going to hear about security issues with Windows even in the future.

      I certainly miss some of the abilities that *nix offers like chroot, setuid etc. that makes it easy to do things in a controlled manner.

    • Case in point against OS backwards compatibility: I use Photoshop on the Mac, and have done so since 1992, from the 68040 under System 7 to the PowerPC on OS9 to OS X on Intel. For all this time it's been the same program that has moved along with the times, as they were going to anyway to keep the product alive and relevant. I can't run PS 2.5 unless I use an emulator, find some System 7/8 disks, etc. But the bigger point is, except for retro-purposes, why would I want to?

      I'm beginning to wonder how much s

    • Re: (Score:3, Interesting)

      by Sparks23 ( 412116 )

      I'd agree that the backwards compatibility has been a huge factor in their dominance, especially in enterprise installs. But I would also say that the same backwards compatibility has been a curse as well as a blessing in some ways.

      A blessing, in that you could with a reasonable degree of certitude run custom in-house apps dating from the Win 3.1 era on later versions of the OS. This meant companies were free to upgrade to later versions of Windows without having to rewrite all their in-house code. This

  • by wjh31 ( 1372867 ) on Friday May 22, 2009 @12:46PM (#28055653) Homepage
    just to get the software to work properly, you may as well just move to linux
    • Re: (Score:2, Informative)

      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 th

      • by mangu ( 126918 )

        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.

        Well, since what you described looks something like what chroot+setuid do on a Unix system, 25 apps in 2 days by 3 people is *extremely* slow.

    • just to get the software to work properly, you may as well just move to linux

      Option #1: Refactor the application to use a totally different set of OS APIs, display libraries and system calls.

      Option #2: Refactor the application, removing all of a subset of "offending" API calls or wrapping them in a UAC-subroutine call.

      Option #3: Provide a thin application compatibility layer that emulates the "offending" API calls in a non-offensive way.

      I think that's in order from hardest to easiest, since you only have to do it once. Incidentally, given how well WoW64 works (and the answer is flaw

    • you may as well just move to linux

      Sounds great, does Linux support shims yet?

      • selinux, apparmor type security allowing it to run AS root while being locked down?
        or chroot allowing it to think its root, while its really in a fakeroot?

        nah i don't think anybody has been doing that for years on linux, nope not at all!

  • HA HA (Score:5, Insightful)

    by scribblej ( 195445 ) on Friday May 22, 2009 @12:54PM (#28055751)

    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.'

    Yeah, real funny. Our software is fragile as fuck, HA-ha

    Who's laughing at that goddamn joke? Oh, right, Microsoft is -- all the way to the bank.

    • Well, maybe it is. But it's the large number of other apps that are at risk of breaking. Even if every one were written correctly, it'd be tough to maintain 100% compatibility. Add in the fact that many are written massively incorrectly (i.e. fragile) and you have a really tough road ahead of you.

      Also, breaking 30 apps is peanuts, there has to be well over a million apps for Windows.

    • by x2A ( 858210 )

      "Yeah, real funny"

      It's slightly funnier if you don't think of jokes as being accurate representations of fact.

      But I guess once you're angry, you're angry.

    • Ummmm. yea. You try writing an operating system in such a way that it can run applications that were designed for an older version of the operation system. Then throw in apps that don't bother with standard application programming guidelines. I have seen so many commercial pieces of software that write user config files to the program files directory or do something else equally stupid. Then Windows actually makes some gains in security and these apps break. Then it is Windows' fault.

    • Re:HA HA (Score:4, Informative)

      by Migala77 ( 1179151 ) on Friday May 22, 2009 @01:34PM (#28056405)
      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.
  • i would downplay this notion of shims, and ballyhoo this notion of duct tape

    shims just sound like a lame hack. using a shim means you've given up on elegance and respectability

    but duct tape is awesome! if you use duct tape to solve a problem you are a manly mcgyveresque resourceful type

    windows 7: the duct tape os, is a mark of pride dude!

    • shims just sound like a lame hack. using a shim means you've given up on elegance and respectability

      Shims allow Microsoft to fix bugs in Windows without affecting applications. Changing how any API call works, even to fix something that is clearly wrong, can cause major problems, because there could very well be applications out there that rely on the broken behaviour.

      I'll give you a practical example. In Windows 7, they fixed the CreateFileEx() API call, which is used to create and open files. Pretty mu

  • love or hate it. (Score:5, Insightful)

    by DRAGONWEEZEL ( 125809 ) on Friday May 22, 2009 @01:05PM (#28055921) Homepage

    Shims work.

    It reminds me of the part in "Zen & the Art of Motorcycle Maintenance" where he suggests to John that beer can aluminum would be the perfect shim to keep his handlebars from slipping. John rejects the idea of using a beercan on his beemer, and so goes to buy "quality shimstock" which is probably made from beercans.

    We shim many things, and I had no clue till I took off the siding of my house, and redid a few doors. Shims are how we make construction look good, and still get it done in a timely manner.

    Surely it applies to programming as well?

    • I really like your comment, it's well written and interesting. The thing here is, Microsoft has no clear direction with their OS. Since win2k, they should have cleared up their security model, made everything clean, etc. But they didn't: alright, so sometimes mistakes happen. Fair enough.

      Windows Vista was supposed to be their complete rewrite that broke backwards compatibility. That's where they should have put the shims in. Windows 7 was just supposed to be putting a new skin on the top, removing V
  • by pecosdave ( 536896 ) * on Friday May 22, 2009 @01:06PM (#28055939) Homepage Journal

    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.

  • Well (Score:2, Interesting)

    by AdmV0rl0n ( 98366 )

    If you were really shafted, then the shims is worth a go.

    In many many cases, applications can be fixed to run without admin rights. By checking using regmon, filemon, and similar, you can get a handle on what an app is opening and where the permissions issue lies.

    This is a bit time consuming, and its a negative, but it is do-able.

    There are four things that proceed the problem.
    Lazy users
    Very lazy developers. -- The prime cause of security failures in Windows.
    People only too happy to simply run as admin -- Ba

    • Re:Well (Score:4, Interesting)

      by LordKaT ( 619540 ) on Friday May 22, 2009 @01:18PM (#28056127) Homepage Journal

      Everyone always cites lazy developers ... but I have to ask, is it really the programmers fault?

      Assume that some database program will only run as an administrator. Is this because the developer couldn't be assed to write proper code, or is it the result of a very tight schedule imposed by management, who needs to ship their product before Q4 so they can meet their debt obligations, thus forcing the programmer is take the quick and dirty route for this bug so he can focus on show-stopping bugs?

      Really, I think that this practice is a symptom of a much larger problem.

  • pointless (Score:4, Insightful)

    by Lord Ender ( 156273 ) on Friday May 22, 2009 @01:16PM (#28056107) Homepage

    For a single-user system (the majority of Windows desktops), it doesn't matter whether or not the user is an Administrator, at least from a security perspective. What threats are you protecting against by subjecting users to extra authentication buttons when installing apps? The only thing the single user really cares about is his own data! Malware running with his (non-administratior) access can destroy his data just as well as malware running as administrator. With either permission, the malware can spread via sockets, file infections, or web access.

    This obsession with UAC on single-user desktop systems is simply misguided. Yes, some existing malware may break if it runs with non-admin privileges. But once non-admin becomes common, malware authors will just stop presupposing admin access when coding.

    • What threats are you protecting against by subjecting users to extra authentication buttons when installing apps?

      If something wants to install or edit system files or even view some important system information, you get a warning about it and explicitly have to ok the event. If someone clicks what they think is movie download (but is actually a malware installer) then clicks run without looking closely, UAC will pop up and ask if you really want to let that program edit system files.

      Considering that the vast majority of malware is still caused by user initiated actions, that is a non-trivial piece of security.

      • Did you read all the way to the end of my post? Because most machines do not use this "feature," it can screw up much existing malware. But as soon as the feature becomes standard, it will be a worthless expense. The mistake you are making is that you are forgetting that the data, not the system files, is all that matters to the end user.

        • Maybe I don't get what you're saying here so let me summarize my argument for why UAC makes sense...

          UAC makes it much, much more difficult to install a program without the user's knowledge. UAC makes it much, much more difficult to make software run automatically on start up without the user's knowledge. UAC gives users more control over what is and isn't on their systems.

          You seem to be making the argument that UAC is about protecting my data from someone else who uses my computer. That's not what UAC is

          • You overgeneralized about UAC, and you completely misstated my comments.

            UAC is intended to prevent malware from harming the user. The idea is that malware running as a normal user (not as an administrator) can't harm the user or spread to other users. That's an absolutely false assumption--one which has its roots in the multi-user servers of yore, not the single-user desktops of today.

            Today, malware running as a normal user can both spread and destroy all data on a system which the user values. When UAC dep

    • erm
      1) its easier to remove non-root malware
      2) there are still many exploits for many programs, reducing the effect of these is still a good thing.
      3) not all problems are malicious, buggy programs as root can cause much more trouble than the same program in a jail/chroot

  • by Animats ( 122034 ) on Friday May 22, 2009 @01:22PM (#28056187) Homepage

    This seems to be aimed at applications which insist on running with administrator rights but don't actually use them. If the app actually tries to do something that needs administrator rights, it's going to fail anyway.

    If applications without administrator rights can put files in administrator directories, especially ones that have OS components, then turning off administrator privileges is sort of pointless.

    • The shim wouldn't actually grant any additional privileges to the app, of course. Look at what Vista already does - if a program attempts to write to the Program Files directory, the write gets redirected to an area in the user's profile folder. For non-filesystem calls, I'd imagine that the shim would request elevation through the usual means - i.e., UAC.
  • If it is not broken, don't fix it.

    If it is broken, and can not be fixed, provide a workaround.

    If after the workaround it is still broken, shim it.

    The shim is therefore the workaround for the workaround.

    Now then, if we Vertulize the Shim, and put it in the forest where no one can hear it crash, does the problem realy exist?

    Sounds like a great way to get to five 9's to me.


  • by vinn ( 4370 ) on Friday May 22, 2009 @01:36PM (#28056423) Homepage Journal

    This requires Windows source code so that you can hook the API's. Who the heck has that for any applications they run? Instead, this is a fix being presented to ISV's... however, if an ISV hasn't fixed their code yet, they probably aren't going to bother now.

news: gotcha