MS Suggests Using Shims For XP-To-Win7 Transition

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

Comments

An alternate solution?

[Anonymous Coward]

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

I know you slashdotters hate to hear it

[Anonymous Coward]

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

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

Re:I know you slashdotters hate to hear it

[RichardJenkins]

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

[x2A]

"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

[AmiMoJo]

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

[x2A]

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

[SBrach]

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

[multipartmixed]

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

[WMD_88]

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

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

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

Re:I know you slashdotters hate to hear it

[Volante3192]

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

[Applekid]

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

[mea37]

"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

[x2A]

"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

[VGPowerlord]

As I recall, "somewhere safe" is %APPDATA%\VirtualStore\Program Files\ etc or something that looks a lot like that. I can't check here because I'm at work and we use XP here.

Re:I know you slashdotters hate to hear it

[TemporalBeing]

"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:I know you slashdotters hate to hear it

[EvanED]

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

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

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

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

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

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

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

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

Re:I know you slashdotters hate to hear it

[x2A]

I dunno, does your computer play 'whoosh' sounds at you when you scroll down or anything? If it's confusing you, you should turn that off.

Re:I know you slashdotters hate to hear it

[Joe U]

Funny, Apple was able to make the transition from insecure, single-user based OS to more secure, multi-user OS without too much trouble and keeping a compatibility layer for older apps. Why can't Microsoft do the same?

When you only have about 20 apps for the platform, it's easy.

Re:I know you slashdotters hate to hear it

[hairyfeet]

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 year, and OS after OS. Because the Ballmer monkey will find a way to fuck up everything they do. He is just too much of a marketing drone addicted to buzzword bingo. MSFT without Gates is like Apple without Jobs-It just don't work. Gates may be a bastard, but he was a bastard that could put out a good business OS. All Ballmer does is bungle from one bad idea to the next. Kinda like when the Pepsi guy nearly bankrupted Apple. Of course MSFT has more money, so it'll take Ballmer longer than the Pepsi guy, but don't worry, just give him time.

The whole "Sell Starter in the USA so you can "monetize the IP" and create "upsell potential" to "maximize shareholder value" BS shows that he is on the right track. The way MSFT has been raising capital lately I bet Ballmer is planning a REALLY expensive dumbass purchase, which will help him get closer to the Pepsi guy's schedule. Just give him time.

Re:I know you slashdotters hate to hear it

[Sparks23]

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 meant they'd stick with Windows; if you have to rewrite your code for a newer OS, you're free to examine other options ("Would Linux serve us better? A Mac? Sun boxes?") you would not otherwise look into. By ensuring the enterprise users didn't have to do that, Microsoft kept them on Windows.

But this is also a curse, however, inasmuch as they now have to maintain that backwards compatibility or risk losing that same market. And that means you have to strike a careful balance; improve your security model, remove old and insecure APIs (or change them to be more secure) and you run the risk of breaking all of that software. Microsoft wants/needs to move forward, modernize the OS. But in order to do so, they likely will break older things. When even /rumors/ of incompatibility with Vista hit, you notice many companies didn't bother to test whether or not their stuff would run. They simply assumed that it would not, and did not upgrade.

So the backwards compatibility that helped them capture and hold the desktop market is *also* what drags them down a bit and prevents them from moving forward as much as they would like.

I think in some ways this makes the biggest competitor to Vista (and presumably Windows 7) not Mac OS X or Linux, but Windows XP. Simply because of that same 'backwards compatibility is important to the market' factor.

That's my $0.02 + state sales tax, anyway.

Re:I know you slashdotters hate to hear it

[icannotthinkofaname]

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.

That, I say, was a lucky gamble on Microsoft's part. If there had been a viable alternative that didn't cost anything, it would have been naturally cheaper than Microsoft Windows on the same hardware, and I imagine that Microsoft wouldn't have risen to the imperial power that it is today if it had had to deal with that kind of competition. Maybe Microsoft would still be a competitor, if this alternate universe had happened, but for that to be true, Microsoftware would have to have been a lot more focused on stability.

Given that Windows 3.0 was 1990 and Windows 3.1 was 1992, Linux was just a little late to the party. MS was just in the right place at the right time. And people are now so ingrained in Windows that viruses, license costs, IE, and daily application crashing are simply realities of computers, rather than shortcomings of Microsoft; these users who refuse to search for other options or learn different systems are the only reason that Microsoft still holds its power today. If the market were still a competition, instead of just ignorant users listening for a select few words, there would be a lot more pressure on Microsoft to deliver stable Microsoftware.

What part of history am I missing here? I'm sure that companies tried to compete with Microsoft back in the late '80s and early '90s, but what went wrong? Why was Microsoft, specifically, so appealing to sell?

Re:I know you slashdotters hate to hear it

[x2A]

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!

Re:I know you slashdotters hate to hear it

[sjames]

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.

if youve got to go through a bunch of hacks

[wjh31]

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

[Z_A_Commando]

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)

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

[DarkOx]

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.

HA HA

[scribblej]

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:HA HA

[Migala77]

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.

if i were a microsoft public relations flak

[circletimessquare]

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!

Meh, this isn't the issue 90% of the time...

[TrisexualPuppy]

When my company eventually switched over to Vista, the software just took a few tweaks here and there, e.g, what can be found here. So far in our tests on the RC, we haven't *had* to run anything as a SU, and everything has been "curable" with little hacks here and there.

If you are smart, you are usually on software support anyway, and your publisher can help you out. When we tried AutoCAD Inventor in Vista/Seven, it was just a quick call to AutoDesk to get it working. My thoughts on legacy software? Stay away from it!!!

Re:Meh, this isn't the issue 90% of the time...

[MrNaz]

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:Meh, this isn't the issue 90% of the time...

[skiflyer]

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:Meh, this isn't the issue 90% of the time...

[Tanktalus]

I get time is money. Which is why I'm curious. Is it really less expensive to teach employees to shim applications (and deal with any fallout from where shimming doesn't work) vs just teaching them an operating system that works? Both involve up-front costs. Both hit your IT department. Both hit your users (mostly in a "shut up and use it" kind of way). But the question is: how much do you trust shimming to work vs just getting out of the cycle altogether? Is the risk of shimming considered when discussing the costs, or is it just the up-front costs that CFOs are looking at?

Re:Meh, this isn't the issue 90% of the time...

[PitaBred]

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:Meh, this isn't the issue 90% of the time...

[cbreaker]

Since when does a small company have 15,000 employees?

Re:Meh, this isn't the issue 90% of the time...

[skiflyer]

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.

love or hate it.

[DRAGONWEEZEL]

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?

Lexmark is a horrible offender.

[pecosdave]

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.

Re:Mike

[afidel]

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

Well

[AdmV0rl0n]

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

[LordKaT]

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:Mike

[Nick Ives]

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.

pointless

[Lord Ender]

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

[nicodoggie]

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:Mike

[dave562]

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

[dave562]

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:Security flaw?

[x2A]

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?

[Animats]

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:Security flaw?

[Jamie's Nightmare]

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

[YesIAmAScript]

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

[mangu]

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:Mike

[Nick Ives]

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

[vinn]

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:But who has source code?!?

[Blakey Rat]

ISVs can create a "manifest" with their application telling Windows which shims need to be in-place to run the application correctly, without changing their code and without having access to the Windows source code. That's the point.

Microsoft already ships a compatibility checker utility: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971

But they can't force ISVs to run it, and they can't force ISVs to fix the problems it finds. What they can do is say, "hey, this shim is an easier fix than the compatibility checker you're already too fucking lazy to run" and hope that sticks.

Re:Win kernel devs + loud noises = broken apps

[VGPowerlord]

Why "Woooooooohoooooooo!?" He could just as easily run around shouting "Developers, developers, developers, developers!"