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."
I know you slashdotters hate to hear it (Score:5, Insightful)
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.
If your going to virtualize XP on 7 (Score:1, Insightful)
You might as well virtualize XP on Linux.
HA HA (Score:5, Insightful)
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.
Re:I know you slashdotters hate to hear it (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:I know you slashdotters hate to hear it (Score:3, Insightful)
"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:if youve got to go through a bunch of hacks (Score:4, Insightful)
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.
love or hate it. (Score:5, Insightful)
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:Mike (Score:4, Insightful)
Re:I know you slashdotters hate to hear it (Score:5, Insightful)
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 (Score:5, Insightful)
Then you say:
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?
pointless (Score:4, Insightful)
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:Mike (Score:5, Insightful)
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:Meh, this isn't the issue 90% of the time... (Score:4, Insightful)
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:Mike (Score:4, Insightful)
Re:I know you slashdotters hate to hear it (Score:5, Insightful)
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:Security flaw? (Score:4, Insightful)
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.
Does this really work? (Score:4, Insightful)
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:I know you slashdotters hate to hear it (Score:5, Insightful)
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:Security flaw? (Score:4, Insightful)
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.
It's not the MS software that is fragile (Score:3, Insightful)
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.
Try chroot on Linux (Score:3, Insightful)
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:I know you slashdotters hate to hear it (Score:5, Insightful)
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:Mike (Score:3, Insightful)
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.
But who has source code?!? (Score:3, Insightful)
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.
Re:I know you slashdotters hate to hear it (Score:5, Insightful)
"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).
Just re-write your poorly deisgned app to work... (Score:1, Insightful)
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!
Re:I know you slashdotters hate to hear it (Score:5, Insightful)
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:Meh, this isn't the issue 90% of the time... (Score:3, Insightful)
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 doing at least a dozen or two sessions.
Tack on the ramped up support costs at the start of the deployment cycle, and the fact that skilled linux personnel command a higher salary than skilled windows personnel.
Then add in the fact that you bought the enterprise class software in the first place because it does what you want. Odds are OS was a minor concern when you purchased it to start.
So yes, it's a big difference.
Re:I know you slashdotters hate to hear it (Score:2, Insightful)
Try a little harder to follow the
Re:pointless (Score:2, Insightful)
But really, when did such buttons ever convince most users to consider what they're doing? I remember reading an installation guide somewhere, a long time ago which said "Just press the 'Next' button until the 'Finish' button appears, and then press 'Finish'"
This was the root of most problems during the early ActiveX era, and as far as I can tell, still is today. I doubt UAC would stop anyone from being click happy.
For some reason, I'm beginning to think that the mouse is the single biggest security risk on a computer.
Re:Meh, this isn't the issue 90% of the time... (Score:3, Insightful)
Re:Meh, this isn't the issue 90% of the time... (Score:5, Insightful)
Re:Meh, this isn't the issue 90% of the time... (Score:3, Insightful)
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.
Re:I know you slashdotters hate to hear it (Score:5, Insightful)
The browser thing is so hypocritical it's almost beyond belief. MS were bundling IE with Windows right back to Win95 with IE2 IIRC. At the time, Netscape was closed source, paid for software, often licensed by ISPs to give out to their customers. We used it because it was what came with our ISP package and knew no different. I discovered IE when I double clicked on a .htm file on the harddisk once and wondered what it was. No one complained, because Netscape had pole position of mindshare and possibly (I'm guessing but cannot confirm) was better anyway. Then... IE started actually getting good, and there was competition, and all of a sudden it was "unfair that they're bundling a browser", even though it wasn't "unfair" for years before that. Now we have a range of open source, free browsers. We would still be buying them if IE wasn't given away with Windows. If you think that's unfair, then you can donate to your favourite browser team.
I liked that IE was integrated into the OS! Just as how I like that KDE does (or did, I've not used KDE4 to know if it's changed). But now, because other people weren't choosing to use other browsers, I now can't choose what I wanted. The whole things stinks of hypocrisy. But yes... this is slashdot huh. Oh well... I'm sure no one else will read this now anyway!