Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MS Suggests Using Shims For XP-To-Win7 Transition

kdawson posted more than 5 years ago | from the you-get-7,000-of-them-for-free dept.

Windows 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."

Sorry! There are no comments related to the filter you selected.

An alternate solution? (2, Funny)

Anonymous Coward | more than 5 years ago | (#28055625)

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

Meh, this isn't the issue 90% of the time... (4, Informative)

TrisexualPuppy (976893) | more than 5 years ago | (#28055803)

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 [microsoft.com] . 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!!!

Re:Meh, this isn't the issue 90% of the time... (4, Insightful)

MrNaz (730548) | more than 5 years ago | (#28056151)

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:An alternate solution? (1, Troll)

CarpetShark (865376) | more than 5 years ago | (#28056437)

I thought it said "shivs".

It said "shills".

I know you slashdotters hate to hear it (5, Insightful)

Anonymous Coward | more than 5 years ago | (#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:I know you slashdotters hate to hear it (2, Insightful)

RichardJenkins (1362463) | more than 5 years ago | (#28055823)

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:I know you slashdotters hate to hear it (2, Insightful)

x2A (858210) | more than 5 years ago | (#28055911)

"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!

Re:I know you slashdotters hate to hear it (1, Funny)

Anonymous Coward | more than 5 years ago | (#28056221)

Is that a whoosh I hear?

Re:I know you slashdotters hate to hear it (1)

jimicus (737525) | more than 5 years ago | (#28056279)

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

Re:I know you slashdotters hate to hear it (4, Insightful)

mea37 (1201159) | more than 5 years ago | (#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).

Re:I know you slashdotters hate to hear it (1)

BrokenHalo (565198) | more than 5 years ago | (#28056537)

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

This is true, but Microsoft had very good mentors. IBM was hardly a stranger to the notion of abuse of power. But even so, the world might have been a different place if IBM hadn't allowed Microsoft to pull out the rug from underneath it, and from that point we might ponder what would have happened if IBM hadn't subsequently ploughed so much money and resources into Linux.

I can see this might end up hijacking the thread, which wasn't really my intention, but I think it's interesting...

Re:I know you slashdotters hate to hear it (1)

RichardJenkins (1362463) | more than 5 years ago | (#28056303)

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 http://books.google.co.uk/books?id=HFd8VyyU0e0C&pg=PA272&lpg=PA272&dq=%22windows+xp+breaks+apps%22&source=bl&ots=17EPij89Oa&sig=w9JKvyFhrcftGtww5SSha3qGyi8&hl=en&ei=qd8WSs2jMs-MjAfwppTwDA&sa=X&oi=book_result&ct=result&resnum=4 [google.co.uk] is a good place to start). Ditto Vista. Windows 7 is so bad at it they're suggesting you continue to run some apps in Windows XP. Would that be two VM's for Windows 8? What a mess.

Lot's of things go into making MS and Windows in particular a successful platform.

Re:I know you slashdotters hate to hear it (4, Interesting)

x2A (858210) | more than 5 years ago | (#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.

Re:I know you slashdotters hate to hear it (0)

Anonymous Coward | more than 5 years ago | (#28055851)

Incorrect.

All the app makers target Windows because thats what 90% of desktop users use.

Most of those use Windows because it has the apps they use or need.

Most of those are to lazy to learn a new set of apps that are typically less featureful and less interoperative with the apps their friends use.

Its a vicous cycle, its not due to MS backwords compatibility. If they totally dumped compatibility, they would piss people off. Those people would bitch and moan, then they will learn to like. They will buy (or more often pirate) newer apps that app makers rushed. MS is a monopoly ofter all, what are people going to do, stop using Windows? They only stick with compatibility so bussineses can upgrade Windows, which naturally means money going to MS. If they dident have compatibility, those bussineses would simply use the existing Windows OS, even long after updates have stopped coming. No money flowing into MS then.

Re:I know you slashdotters hate to hear it (4, Insightful)

x2A (858210) | more than 5 years ago | (#28056035)

Haha, for me, the best bit was where you said

"its not due to MS backwords compatibility"

and then followed it up by listing a bunch of arguments showing why it is due to backward compatibility! That totally caught me by surprise! But yeah, you're right, if they dumped compatibility people would get pissed off, because they do want backward compatibility!

"All the app makers target Windows because thats what 90% of desktop users use"

Do you think Windows would ever've gotten so popular if it didn't allow people to run their old DOS programs? Course not. It's called 'transition', and it's much less disruptive, esp to businesses, than quantum leaps.

Re:I know you slashdotters hate to hear it (4, Insightful)

Volante3192 (953645) | more than 5 years ago | (#28056189)

It's not 'lazy to learn' a new set of apps, it's 'utter panic and fear at having to move years and years of vital company data from one business application to another.'

I know companies that still use applications that are little more than absurdly complex DOS .BAT files because that's where all their data is.

Learning a new system is child's play compared to migrating all the data, ensuring nothing is lost, getting everything to work (laser printers, faxes, god forbid there's any dot matrix or thermal printers...)

Re:I know you slashdotters hate to hear it (0)

Anonymous Coward | more than 5 years ago | (#28055885)

The minute WINE works 100%, Linux will own the desktop in that case. Because WINE make it easy for your legacy apps to work better than ever, without any sort of shims or other garbage.

Re:I know you slashdotters hate to hear it (4, Insightful)

SBrach (1073190) | more than 5 years ago | (#28056073)

You say:

The minute WINE works 100%

Then you say:

without any sort of shims or other garbage

Wine is the definition of using hacks to get an app to run on an OS. If it is ok for Wine, why is it not ok for Win7?

Re:I know you slashdotters hate to hear it (4, Insightful)

Applekid (993327) | more than 5 years ago | (#28056305)

Wine is the definition of using hacks to get an app to run on an OS. If it is ok for Wine, why is it not ok for Win7?

Because this whole article is FUD.

I don't even know why shims are a problem. It's not like the API consumer needs to know they exist. Even more so, just use the API correctly and you'll never have compatibility issues in your app. The Microsoft philosophy is to let people to the wrong thing and let it work out right. I don't agree with that, but, hey, it doesn't really matter WHAT Microsoft does with Windows, really.

Shim for XP compatibility = LOL, Microsoft sux!
No-shims and screw XP = LOL, Microsoft sux!

Re:I know you slashdotters hate to hear it (1)

Thornburg (264444) | more than 5 years ago | (#28056549)

Because this whole article is FUD.

I don't even know why shims are a problem. It's not like the API consumer needs to know they exist. Even more so, just use the API correctly and you'll never have compatibility issues in your app. The Microsoft philosophy is to let people to the wrong thing and let it work out right. I don't agree with that, but, hey, it doesn't really matter WHAT Microsoft does with Windows, really.

Did you actually read the document? Do you know what shims are?

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. Shims let applications written for older versions of the API work on the current OS without the current OS having to have all the different API versions simultaneously active*.

*Wow, would that be one heck of a mess.

Re:I know you slashdotters hate to hear it (0)

Anonymous Coward | more than 5 years ago | (#28056205)

And why would you want to run WINE when the App works fine in Windows?

It's like buying a lambo, just to have to towed around everywhere you go.

Re:I know you slashdotters hate to hear it (3, Informative)

AmiMoJo (196126) | more than 5 years ago | (#28055977)

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:I know you slashdotters hate to hear it (1, Flamebait)

je ne sais quoi (987177) | more than 5 years ago | (#28056063)

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 [nethack.org] 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 linux or unix program that uses that as well. If you have an app that runs on OS 9, you can run that in classic mode (which I believe they stopped including for leopard, but I'm not sure), and that takes us back to 1999. Finally, I have all kinds of DOS or windows 3.11 apps that don't run well or at all on windows any more, even in emulation mode. We also used to have some kind of VB app that only ran on windows 95 and refused to run on anything else. Most of these are scientific software packages for driving instruments or interfacing with specific hardware, but not always.

I know you windows fanboys hate to hear it, but contrary to being perfect, windows does break backwards compatibility sometimes with new releases, AND there are other operating systems that achieve similar or greater (in the case of linux) backwards compatibility to their predecessors.

Re:I know you slashdotters hate to hear it (5, Insightful)

WMD_88 (843388) | more than 5 years ago | (#28056177)

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 (0)

RiotingPacifist (1228016) | more than 5 years ago | (#28056383)

The APIs are fairly stable, its the constantly shifting libraries that cause most of problems, but if you go completely closed that's not a problem.

Re:I know you slashdotters hate to hear it (0)

je ne sais quoi (987177) | more than 5 years ago | (#28056489)

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.

You can do that just fine, you have to install module software first though, e.g. this [sourceforge.net] , and the package you need to run it. It allows you to change to whatever runtime environment you want. Want to run an the old libc6 from redhat 6.2? Go right ahead. Want to use a different gcc library? No problem. This type of software is used on large supercomputer clusters to ensure that everyone can run all the software they want, e.g. there was a big break between mpich and mpich2, but thanks to modules, you can have both installed and run binary code requiring one or the other without having to uninstall anything.

Re:I know you slashdotters hate to hear it (1)

just_another_sean (919159) | more than 5 years ago | (#28056077)

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:I know you slashdotters hate to hear it (2, Interesting)

multipartmixed (163409) | more than 5 years ago | (#28056145)

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 MacOS 9 -> X.... in Sun's case they changed from BSD to SVR4 underpinnings.

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.

BTW, Solaris accomplishes this mostly with "shims", in the form of a well-thought-out dynamic linker with built-in versioning.

Re:I know you slashdotters hate to hear it (1)

Thornburg (264444) | more than 5 years ago | (#28056591)

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.

If you're a stump, maybe... (1)

djupedal (584558) | more than 5 years ago | (#28056169)

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

Mike (0)

Anonymous Coward | more than 5 years ago | (#28055643)

Leave it to MS to suggest hacking their own code to make it work.

First post??

Re:Mike (1)

lorenlal (164133) | more than 5 years ago | (#28055723)

This is not a new solution at all. At my company, we had to employ a shim to make one of our "in house" developed apps work in XP even...

Please save any comments about "forcing our developers to fix their code." I mentioned it, and I might as well have suggested we invade Russia by land. Unfortunately, we got it to work, and the appropriate funding to make the software better never materialized since there was "no need to fix it anymore."

Re:Mike (1)

TheRealMindChild (743925) | more than 5 years ago | (#28055799)

How did you create said shim?

Re:Mike (1)

lorenlal (164133) | more than 5 years ago | (#28055879)

Fortunately, I didn't have to. It happened before I started here. But I'm going to go out on a limb and guess that it was applied when the software was packaged into an MSI format.

We = company in this case. I should have specified.

The suggestions I made came long after the fact. I was informed by my leadership that they had already lost that fight, and that I shouldn't bother pursuing it any further.

Re:Mike (1)

GIL_Dude (850471) | more than 5 years ago | (#28056129)

It's fairly easy to do this; you don't generally go build a shim - as unless you are completely hacking the system - the shims already need to be known.

You simply download the Application Compatibility Toolkit from the MS web site and apply the required shim(s) to your app (stores the required config in a .sdb file). You deploy the .sdb along with your application.

There are also tools to help you determine what shims your applications needs. Once you get started with this, it is pretty easy to do.

Re:Mike (1)

dave562 (969951) | more than 5 years ago | (#28055827)

On one hand you didn't get the money to fix your code. On the other hand, Microsoft stepped up to the plate to "protect your investment in your legacy solution". The only cost to your organization was the time spent sorting out the shims. You mentioned you had to shim an app to get it work on XP. How old was it? Did it run on 2000? Was it developed for 2000 or NT? At the risk of comparing apples and oranges here, how many nearly ten year old Linux apps can you run on the current kernel without a recompile or rewrite?

One of my biggest gripes with MS has been needing "administrator" rights to run seemingly standard applications. Nine times out of ten the requirement comes from poor coding practice on the part of the developers. It is good to see Microsoft finally stepping up and providing a work around instead of forcing everyone else to wait for some developers who might not ever get around to fixing their apps.

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?

Re:Mike (1)

antifoidulus (807088) | more than 5 years ago | (#28055915)

Are you sure it was the application writer's bad practices that forced many apps to require admin privileges? Because the phenomenon of having to run most day to day apps as an admin seems to be limited to Windows. We run an all Mac/Linux shop with 100+ workstations and dozens of servers and we do some pretty complex stuff and NONE of our users has to be an admin to get their job done. That is just unheard of in the Windows world, but has been the norm in the *nix world for the past 2 decades.....

Re:Mike (3, Insightful)

afidel (530433) | more than 5 years ago | (#28056031)

Yeah but how many of those apps are SUDO or SUID? Oh and we run all but one of our apps on locked down Citrix servers where they users are just that users with fairly severe restrictions beyond even MS standard user rights, you just need an admin that knows what they are doing. (The one app isn't run on Citrix because of a graphics library problem not a permissions one, it doesn't run correctly on widescreen aspect systems either!)

Re:Mike (1)

iluvcapra (782887) | more than 5 years ago | (#28056157)

Yeah but how many of those apps are SUDO or SUID

Considering, under both systems, they won't sudo without getting a sudoer's password, probably not many. No Mac OS X Cocoa application runs as sudo or setuid, and you can't escalate on Mac OS X or any BSD without having a password. I can't speak for Linux programs.

The whole problem from the beginning was MS-DOS and friends presuming from power on that you wanted to be running as admin.

Re:Mike (4, Insightful)

dave562 (969951) | more than 5 years ago | (#28056115)

Since at least Windows 2000, Microsoft has provided guidelines about how to write code so the applications do not require administrative privileges. Most developers have either been ignorant of the practices, don't care about the practices, or don't know how to implement the practices. A lot of it has to do with where the DLL files get stored, and where the application writes its files to. In the *nix world, everything is pretty self contained within its own directory. For the most part, all of the files that an application needs are right there with the application. If they aren't in the same directory, symbolic links (something that Windows lacks) provides the application access to the necessary libraries.

I think you're blowing things out of proportion to say that it is unheard of it in the Windows world for users to be able to run as a something less than a super user. At my current job, we only have one app on the network that requires admin privileges. When I was consulting, most of our clients were all running as regular users.

The "problem" with Microsoft is that they have always catered to the lowest common denominator. When it comes to developers, they provide the developers with a powerful IDE and don't encourage them to think about how it works behind the scenes. That ease of use has come at the cost of security. Sure, devs have been able to come up with the applications that they need to meet the business requirements laid out for them. Unfortunately, those applications often times aren't properly hardened and crack when put on hostile networks.

I see the computer world working from two different ends. The Microsoft part of the world has provided the functionality and is backing into security. The *nix world has provided the security and the stable foundation, and now they are building the functionality.

Re:Mike (0)

Anonymous Coward | more than 5 years ago | (#28056473)

Dude your a moron. I'm not even sure where to start with this one.

Windows will compile and run code just like any *nix system, dependencies included. Windows didn't support FILE BASED sympolic links till recently which has not one fucking thing to do with DLL or code.

In one sentence you talk about how *nix rocks cause every file is in one place and windows sucks cause it can't use libraries.

Get THIS. Not only can I use shared libraries in windows I can dynamically or manually link to them depending on which I want or if i want to fail over functionality.

Microsoft yes has bowed to the "lowest common denomiator" of users. That speaks nothing about development. Spend some time on msdn.microsoft.com in the library section, It won't take long to realize just how stupid you are.

Re:Mike (1)

Amouth (879122) | more than 5 years ago | (#28056505)

"symbolic links (something that Windows lacks)"

It always pissed me off that MS never bothered to implement a simple way for people to use them.

Most people don't realize that NTFS has support for Sym links (vista & server08) and and also Junction points (limied Sym links) sence NTFS's first inception in NT

http://en.wikipedia.org/wiki/NTFS_symbolic_link [wikipedia.org]

they have it.. it's been there. and you can use it - i've used junction points for a long time..

people just don't realize they exist in Windows.

Re:Mike (1)

lorenlal (164133) | more than 5 years ago | (#28055993)

It was written in the 90s, in VB. That's about all I know. From what I understand, it did run properly in NT 4 SP6, but it was never tried on 2000.

Really, the point of the comment is that this is reuse of an old solution. Even during the attempt at migrating to Vista, shims were a suggested solution for applications that didn't work.

Re:Mike (3, Insightful)

dave562 (969951) | more than 5 years ago | (#28056173)

What should Microsoft be doing? The community is up in arms over their less than stellar security record. They introduce progressively better security with each iteration of the OS, but often times those security improvements crap all over previously accepted programming practices. What do they do? Pull an Apple and tell everyone to go out and buy the newest version of all of the software that was working just fine on the previous version of the OS? It seems to me like shims are a good solution. Older shops get to continue extracting value from their legacy code without having to invest money in rewriting the apps.

Re:Mike (1)

phantomfive (622387) | more than 5 years ago | (#28056451)

What should Microsoft be doing?

Oh, this is easy. Are you kidding? This is slashdot. Even I know the answer to this one. Microsoft should be rolling their own linux distro, complete with wine. See? Simple as pie.

Re:Mike (1)

dave562 (969951) | more than 5 years ago | (#28056601)

Oh yeah. As you can see by my UID, I'm new here. ;)

Re:Mike (1)

JStegmaier (1051176) | more than 5 years ago | (#28056579)

Pull an Apple and tell everyone to go out and buy the newest version of all of the software that was working just fine on the previous version of the OS?

That seems to have worked pretty well for Apple.

Re:Mike (3, Informative)

Nick Ives (317) | more than 5 years ago | (#28056095)

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.

Re:Mike (1)

dave562 (969951) | more than 5 years ago | (#28056223)

Thanks for the information. If you have to write code in the shim, how is that better than just rewriting the application? I guess it's less resource intensive, and helpful in situations where you might not have access to the original code.

Re:Mike (2, Insightful)

Nick Ives (317) | more than 5 years ago | (#28056363)

Those are exactly the reasons why you'd want to write a shim. Often it's just easier found out the part of a PE that's causing a problem and then write a hack for it. MS does exactly that for massive numbers of popular applications, it's how the Windows Application Compatibility Layer works.

That might sound crazy but it's actually the least bad choice. It means they can keep compatibility cruft out of mainline development meaning apps written and tested for Vista / Win7 will work because they're written The Right Way.

Re:Mike (1)

dave562 (969951) | more than 5 years ago | (#28056545)

I completely agree with you. The properly written apps will run better because they aren't depending on DLLs that are having to check for code that nobody has been using for ten years, but has been left in there for those random "just in case" scenarios. It probably slims down the core DLLs a lot because they can offload all of that to the shims.

if youve got to go through a bunch of hacks (4, Funny)

wjh31 (1372867) | more than 5 years ago | (#28055653)

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

Re:if youve got to go through a bunch of hacks (0)

Anonymous Coward | more than 5 years ago | (#28055689)

You don't get it obviously. The shims are transparent to the application. Deploying them enables your old misbehaved apps to work under Win7, in the same way that virtualization of Program Files and the Windows directory did under Vista.

Re:if youve got to go through a bunch of hacks (3, Insightful)

DarkOx (621550) | more than 5 years ago | (#28055913)

By that logic WINE is just as good an option. Its transparent to the application and provides compatibility prior versions of Windows. If you have load additional software on windows or develop compatibility layers on your own then there is no value in the backward compatibility any longer. You might as well pour the same efforts into getting your app running on WINE.

Re:if youve got to go through a bunch of hacks (2, Informative)

Z_A_Commando (991404) | more than 5 years ago | (#28055815)

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)

Try chroot on Linux (2, Insightful)

mangu (126918) | more than 5 years ago | (#28056277)

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.

Re:Try chroot on Linux (1)

RiotingPacifist (1228016) | more than 5 years ago | (#28056439)

in fairness
1) its a chroot with a custom set of requirements
2) your dealing with windows admins

Re:Try chroot on Linux... Fast, then slow? I'm (1)

davidsyes (765062) | more than 5 years ago | (#28056535)

confused...

I was looking around to insert, or shim, the conversation with my own thoughts about the shim-job. I was thinking that ms' shims were analogous to replacing leaky sphinctres with grommets and shims, but the code being dry stuffing. Or, the code is like glass fed to the machine, which... Oh, shim me... i need to shim my shim comment... my vision must be shimmery...

Anyway, it looks like either ms needs to provide virtualization to contain these bad apps, or just stop providing infrastructure support. Any 3rd-party devs who shim or bypass the non-support should (or could?) be blacklisted and clients warned their bad/leaky shims will not be plugged/supported.

Re:if youve got to go through a bunch of hacks (0)

Anonymous Coward | more than 5 years ago | (#28055881)

thats where your wrong becuase reguardless of the hoops you have to jump through just about anything you want to run will run, the same can not be said for linux

Re:if youve got to go through a bunch of hacks (0)

Anonymous Coward | more than 5 years ago | (#28055887)

I can has fakeroot?

Re:if youve got to go through a bunch of hacks (1)

Wrath0fb0b (302444) | more than 5 years ago | (#28055897)

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 flawlessly), I don't see how they can't pull this off fairly well.

Re:if youve got to go through a bunch of hacks (1)

eclectro (227083) | more than 5 years ago | (#28056137)

you may as well just move to linux

Sounds great, does Linux support shims yet?

Re:if youve got to go through a bunch of hacks (1)

RiotingPacifist (1228016) | more than 5 years ago | (#28056503)

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!

If your going to virtualize XP on 7 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28055679)

You might as well virtualize XP on Linux.

Re:If your going to virtualize XP on 7 (1)

x2A (858210) | more than 5 years ago | (#28056097)

Why? API redirection is like a zillion times faster than virtualisation.

Security flaw? (0, Flamebait)

RichardJenkins (1362463) | more than 5 years ago | (#28055747)

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

No way! Really? Next you'll be telling me you can't switch to another virtual console if your GUI crashes, or review the OS code to satisfy yourself it's not malicious.

Re:Security flaw? (3, Insightful)

x2A (858210) | more than 5 years ago | (#28056181)

I suppose you check the design schematics for your car and watched your house being built to make sure there're no bugs planted in the wall...

You have to draw the trust line somewhere. So a business wants to check the code's all alrighty, they have to pay someone to do it... except then you're relying on the trustworthiness and skill of that person. They may as well just be paying MS.

Don't get me wrong, my line of work's all open source stuff, and where people require windows servers they always go in a virtual machine, never on bare metal. But I'm not everyone, other people and other businesses have other priorities. Ignoring that helps no one.

Re:Security flaw? (1)

RichardJenkins (1362463) | more than 5 years ago | (#28056431)

You have to draw the trust line somewhere.

Yes - I think it's better to draw that line outside the company who makes a product.

I've never looked at a line of the linux kernel source, but I believe if someone slipped malicious code in there there is a pretty good chance someone would notice it and raise a storm. If malicious code were slipped into windows it'd be much less likely to get spotted.

I'm probably less trusting than most people, but the idea of anyone trusting a company that has been convicted of criminal charges to run you computer with an OS that no one can scrutinise without that company's say-so? No thanks.

Re:Security flaw? (4, Insightful)

Jamie's Nightmare (1410247) | more than 5 years ago | (#28056211)

Next you'll be telling me you can't switch to another virtual console if your GUI crashes

If your GUI is crashing, you should consider using a different OS entirely. GUI crashes seem to be an acceptable event among Linux users, but most other users would not tolerate such occurrences. In Windows, there is a chance the "explorer" file manager might crash. For example, due to a 3rd party extension behaving badly. However, since XP and onward, a crashed explorer will restart automatically. Since explorer is only part of the GUI, none of your applications are disturbed.

Crashes of the underlying GUI are almost unheard of unless there is a serious flaw with the graphics driver. Since Vista and onward, the WDDM (Windows Display Driver Model) can restart the graphics system if such a problem should occur.

or review the OS code to satisfy yourself it's not malicious.

I would suggest that if you are paranoid enough to warrant reviewing the entire source code to the OS you wish to choose, you should probably consider some type of therapy. Using computers will only exacerbate your underlying problems.

Re:Security flaw? (0)

cayenne8 (626475) | more than 5 years ago | (#28056443)

"If your GUI is crashing, you should consider using a different OS entirely. GUI crashes seem to be an acceptable event among Linux users, but most other users would not tolerate such occurrences."

You seem to imply by your statement that GUI crashes on a Linux system are 'common place', and therefore acceptable amongst the Linux user crowd.

Where did you get that idea? I find that any GUI I happen to be running on a linux box rarely crashes. Anecdotally, I find it certainly crashes less often than many windows boxes I've used.

That being said...while linux boxes and their GUI/Windowing systems can crash like any program can, it usually doesn't rile up the Linux users as badly as the MS Windows user, since on Linux, the Windowing system is running on top of and separate from the OS really. On linux, if your Xwindows or windows managers crashes, no big deal, you usually don't have to bring the whole system down to get it back up and started.

The same can't be said for windows, where when the GUI is gone...the whole OS at that point is hosed and you gotta reboot.

Re:Security flaw? (1)

RichardJenkins (1362463) | more than 5 years ago | (#28056543)

I was thinking more before explorer starts.

There's plenty of times when the login screen hangs after typing my credentials (usually because of Active Directory problems). Can't cancel and log on as a local user, just got to wait/reboot.

Less often explorer just doesn't seem to start, or takes ages to start. I suspect this happens when Windows installs updates, but I'm not certain. Anyway, it would be much easier to switch to another interface and check what's going on.

HA HA (4, Insightful)

scribblej (195445) | more than 5 years ago | (#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.

It's not the MS software that is fragile (2, Insightful)

YesIAmAScript (886271) | more than 5 years ago | (#28056225)

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.

Re:HA HA (1)

x2A (858210) | more than 5 years ago | (#28056229)

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

Re:HA HA (1)

MyLongNickName (822545) | more than 5 years ago | (#28056243)

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 (4, Informative)

Migala77 (1179151) | more than 5 years ago | (#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 [joelonsoftware.com] .

It will be a long time before Wine will have this level of compatibility.

if i were a microsoft public relations flak (3, Funny)

circletimessquare (444983) | more than 5 years ago | (#28055767)

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!

Re:if i were a microsoft public relations flak (0, Troll)

x2A (858210) | more than 5 years ago | (#28056337)

Because yeah if MS were any good they wouldn't need to use these 'shims' or whatever they sound like because they would've developed a time machine by now to go back in time and delay the release of their OS's until they had full multiuser support that didn't slow things down too much despite the fact that people didn't even need it at the time.

Mistakes happen, sometimes out here in the real world you just have to patch up and get on with it. You can't just rip everything out and start again every time you hit a design snag when there're people relying on said everything to continue working.

Re:if i were a microsoft public relations flak (1)

Daltorak (122403) | more than 5 years ago | (#28056501)

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 much every application out there uses this API, so changing how it works would be about as dangerous as changing how a core CLI utility on Unix like "sed" or "grep" works and then rolling out the change to production systems around the world.

The bug in Vista (but has existed in Windows for quite some time) is that if you were you request exclusive read access on a file that you do not have full access to, Windows would silently change your lock on that file to "shared read" access. Which is, of course, not what you asked for. There are plenty of other cases in CreateFileEx() where the API call will fail if you ask it to do something your user account doesn't have permission to do. They fixed this in Windows 7, but this is obviously a case where fixing a bug in Windows will cause many applications to crash or not function properly.

In order to provide this bug fix, and therefore make Windows better, they've added in a new (optional) application compatibility manifest that new applications can use that says, "hey, I want the Windows 7 behaviour!", and this CreateFileEx() fix -- as well as a number of other bug fixes -- will be in place for your application. Microsoft is saying that they will also maintain that defined compatibility level through future versions of Windows, too, i.e. on Windows 8, you'll get the Windows 7 API behaviour.

Sure beats having to keep up with KDE's world-breaking changes every few years, don't you think?

There really is no other good way of going about this. An "elegant and respectable" solution would probably involve every software company, ever, fixing every bug in their software, ever, that prevents their application from being compatible with Windows 7. What do you suppose the chances of that happening are? You might as well be a seven-year-old girl asking for a live unicorn for your birthday... you just might have better luck! A lot of software that needs to run on Windows is in-house jobbies written years ago by people who'd just learned the difference between "If" and "While" BASIC statements. It would likely cost a lot of money to scour the whole code-base and fix it... and that's if they even still have the code and can find someone to do the work! (What if the contractor ran off with it and is holding it for random? I've got a friend who's dealing with that very issue right now!!)

Microsoft's solution to this problem is to give IT people the ability to analyze the software they have to run and to apply shims to make it work. Microsoft will even help companies with this, often for no cost at all.

Elegance is nice, but it can be prohibitively expensive. Shims are for the real world.

Oh gawd (1, Informative)

Niris (1443675) | more than 5 years ago | (#28055821)

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.

love or hate it. (4, Insightful)

DRAGONWEEZEL (125809) | more than 5 years ago | (#28055921)

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?

Re:love or hate it. (1)

ausekilis (1513635) | more than 5 years ago | (#28056185)

Shims work.

Surely it applies to programming as well?

They do... They're called "hacks", and often come from a poor design decision and result in uglier code that's more difficult to maintain.

Re:love or hate it. (1)

BobMcD (601576) | more than 5 years ago | (#28056285)

I for one detest ugly hacks like shims and sudo... ...oh, wait.

Sure, (1)

DRAGONWEEZEL (125809) | more than 5 years ago | (#28056571)

but you can't retroactively design something.

Just as the beemer should have had a smaller space for the handlebars, what do you do when the product is already adopted?

Lexmark is a horrible offender. (2, Informative)

pecosdave (536896) | more than 5 years ago | (#28055939)

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... (0)

Anonymous Coward | more than 5 years ago | (#28055953)

The 3rd party apps guys need to learn to write their applications properly, and stop writing stupid, hackey code.

Your app does not need local admin or eleviated powers, thats stupid.

Code your apps to proper standards, and stop whining. You are just being whipped into doing things right, because MS is finaly tighting up the stardards they should have been enforcing from the start.

Don't bash MS for security, then whine when your apps can't run with elevated powers.

Thats retarded.

Well (2, Interesting)

AdmV0rl0n (98366) | more than 5 years ago | (#28056057)

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 -- Bad practice
MS setting users as admin to fit point 1,2,3

Windows is not insecure, not any level worse than anything else, but developers, users, and vendor run it insecurely, and worse, have an encouraging attitude for doing so.

MS have gone about the UAC thing very badly, but overall the step and move towards a UAC alike structure is long overdue, and is badly needed.

Re:Well (3, Interesting)

LordKaT (619540) | more than 5 years ago | (#28056127)

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.

Re:Well (0)

Anonymous Coward | more than 5 years ago | (#28056609)

well, instead of "lazy developer" he should have written "lazy software vendor".

pointless (3, Insightful)

Lord Ender (156273) | more than 5 years ago | (#28056107)

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.

Re:pointless (1)

MozeeToby (1163751) | more than 5 years ago | (#28056269)

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.

Re:pointless (1)

Lord Ender (156273) | more than 5 years ago | (#28056497)

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.

Re:pointless (1)

MozeeToby (1163751) | more than 5 years ago | (#28056603)

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 meant to do.

Does this really work? (3, Insightful)

Animats (122034) | more than 5 years ago | (#28056187)

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.

Re:Does this really work? (1)

typobox43 (677545) | more than 5 years ago | (#28056455)

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.

"Shim" and Its Many Meanings (0)

Anonymous Coward | more than 5 years ago | (#28056323)

Reading the title, did anyone else first think of the other sort of "shim"?

Let us do some study on this .. .. (1)

Ozric (30691) | more than 5 years ago | (#28056407)

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.

YMMV

But who has source code?!? (2, Insightful)

vinn (4370) | more than 5 years ago | (#28056423)

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.

Just re-write your poorly deisgned app to work... (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28056509)

Its these crap-tastic applications that caused problems in XP let alone the horrendous issues they will cause in Vista\7. To this day it baffles me that Developers assume end users are administrators of their computers, despite countless security experts explaining this is a bad idea. Aside from a few small (5-10 users) companies, no one gives administrator rights to their end users unless they are completely incompetent or just overburdened by political nonsense then it just creates more issues down the line. So just write it correctly the first time and your shims will vanish!

Win kernel devs + loud noises = broken apps (0)

Anonymous Coward | more than 5 years ago | (#28056573)

"If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps."

What if Steve Ballmer enters the room and do the Monkey Dance screaming "Woooooooohoooooooo!"

Besides breaking a chair or toes, what else would get broken?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?