Slashdot Mirror
MS Suggests Using Shims For XP-To-Win7 Transition
eldavojohn writes "Windows XP (and a lot of MS OS code before that) had a fundamental security flaw whereby the default setting made the ordinary user run as the superuser. Vista & Windows 7 have fixed that and implemented The Correct Paradigm. But what about the pre-Vista applications written to utilize superuser privileges? How do you migrate them forward? Well, running a virtualized instance of XP in Windows 7 is an option we've talked about. But Microsoft is pushing the idea of using 'shims,' which are a way to bypass or trick the code into thinking it's still running as user/superuser mode in Windows XP. This is an old trick that Microsoft has often employed, and it has brought the Windows kernel a long ways, in a duct-tape sort of fashion. At the TechEd conference in LA, Microsoft associate software architect Chris Jackson joked, 'If you walk too loudly down the hall near the [Windows] kernel developers, you'll break 20 to 30 apps.' So for you enterprise developers fretting about transitioning to Windows 7, shims are your suggested solution."
I thought it said "shivs". I guess that would be another way to coerce people into giving up their precious XP.
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.
just to get the software to work properly, you may as well just move to linux
You might as well virtualize XP on Linux.
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."
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.
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!
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
How did you create said shim?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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!!!
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.
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?
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.
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.....
Monstar L
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?
How much is your data worth? Back it up now.
Try getting a Lexmark all in one device to work while NOT admin - ain gonna happen. If you call up Lexmark to ask why their shits broke, they pawn it off on Microsoft. I spent quite a bit of time figuring out folders to change ownership permissions on to make that bastard work without giving admin to everyone.
The preceding post was not a Slashvertisement.
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.
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!)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
We`re all equal
I'm reading the documentation right now, but I'm curious if it resolves the security problems. I'm guessing that a shimmed app is running in a sandbox? Or is the shimmed app given fully elevated privileges so that if gets compromised, the exploit code can still own the system?
Neither. The shim code just lies to the app and says it has admin rights, it's just like fakeroot in Unix.
You then write code in the shim to intercept any calls that really require admin rights and deal with them appropriately. If it's something dumb like wanting to write to something in the Programme Files directory you can redirect it to the users home dir. If it's something that really requires admin then you can ask for it and the user gets a UAC prompt.
Nick
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
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.
.sdb file). You deploy the .sdb along with your application.
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
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.
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.
Don't blame me, I voted for Baltar.
> 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...
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.
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.
The revolution will not be televised... but it will have a page on Wikipedia
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.
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.
"When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
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.
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.
http://lkml.org/lkml/2005/8/20/95
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.
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.
Nick
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
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.
----- obSig
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.
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.
Qxe4
"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
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.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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!
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.
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
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.
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.
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?
How much is your data worth? Back it up now.
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.
Oh yeah. As you can see by my UID, I'm new here. ;)
Case in point against OS backwards compatibility: I use Photoshop on the Mac, and have done so since 1992, from the 68040 under System 7 to the PowerPC on OS9 to OS X on Intel. For all this time it's been the same program that has moved along with the times, as they were going to anyway to keep the product alive and relevant. I can't run PS 2.5 unless I use an emulator, find some System 7/8 disks, etc. But the bigger point is, except for retro-purposes, why would I want to?
I'm beginning to wonder how much software is in existence that is still running that requires some long, long, depreciated API. The typical examples are the home-grown accounting system, the weird shareware program that does this *one* thing we need, etc. How much of this software is *really*, and I mean *really* out there, that exists in this form and this form only.
To this point, I know someone who has a Mac running OS 8 because he runs an accounting package that was written just for him by a long-gone programmer who's last message was "no, it won't work on OS 9". Instead of feeling the pressure to upgrade his system, he just keeps it running on his original Mac Centris something-or-other while he does all his other work on his Mac Pro.
0 run with escalated privileges because the users aren't admins, and they don't need "admin rights" to certain programs. The Microsoft model is, and always has been, severely flawed. I couldn't believe the hoops we had to go through just to get a scanner working on a windows box. We had to grant the users groups admin privileges on the app that ran the scanner, which of course increases the chances of getting owned significantly.
In the OS X world, other than perhaps needing an admin to install the software, the users have no problem using peripherals and don't need us to grant the programs that use said devices extra privileges. That is just fundamentally insecure. Granting admin rights to a program instead of user is unheard of in the land of real operating systems.
Monstar L
Next you'll be telling me you can't switch to another virtual console if your GUI crashes,
Your GUI crashes? Seriously?
If that *ever* happens, you should just pack up and move OSes. Not acceptable.
Comment of the year
You must be talking about some crazy, bizarro *nix world, as the one in this world tends to split directories up by what the files are for, not by application.
For example, /etc has configuration files, /usr/bin and /usr/local/bin tend to have executables, /var/log has log files... I could go on.
Very infrequently, apps will install their entire directory structure into something like /opt, but that's very, VERY rare.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I lost mine in WW2, you insensitive clods!
No wait... you said shims?!?!
Nevermind.
It takes an idiot to do cool things - that's why it's cool!
Why "Woooooooohoooooooo!?" He could just as easily run around shouting "Developers, developers, developers, developers!"
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Maybe running as a normal user is the "correct" way of doing it (gotta love the arrogance there...) but I personally will never run that way.
I have heard all the arguments, from the fact that its easy to type rm -rf /, to the fact that viruses auto install with an IE misclick. The problem with the "correct" way of doing things is that it is very annoying to be typing in passwords all the time! Just try and use a apple mac computer. It asks you to authenticate the keychain consistently. Especially, when as a technician, you are making lots of changes to the OS. I would hate for windows to go this direction. Personally, I believe that it desensitizes people into typing their password into any box that asks.
I will submit that in all the years I have been logging in as root on linux, and administrator on windows, I have NEVER mis typed a file system altering command, deleted my hard drive, or had any other negative experiences running as super users. I also turn off the delete confirmation on my recycle bin. Does this make me a dangerous user? I doubt it.
I just really resent the arrogance of the summary basically stating that super user logins are a design faux pas and should be eliminated anywhere and everywhere. Does my argument have merit? does no one else constantly run as root/admin?
As a potential lottery winner, I totally support tax cuts for the wealthy
The future is the Virtual Machine.
Imagine for a moment, that every application included it's own OS. Of course that OS would be a very dumbed down sort of thing, but it would be entirely independent of the host OS except for some standard inter-vm communication requirements for clipboards, file management, etc.
Your host OS would be responsible for managing the file system, display, and networking, all of which it would provide access to via some standard protocols. The applications would support those protocols and contain their own OS and drivers tailored to those standards. The applications could be built in a NTVM, LinuxVM, BSDVM, SolarisVM, etc as long as it was just complete enough to support the application.
Imagine it like a typical virtual machine, but even less dependent upon the host OS. Sure the applications would be larger, but that's rarely a problem anymore.
Sometimes the best solution is to stop wasting time looking for an easy solution.
Those two programs handle vista really well. If you launch either with insufficient permissions for it to do its work, it'll tell you. If Vista moved some files into whatever safe zone Vista sometimes moves things, the mod manager will tell you and offer to move them back. The author "timeslip" did a great job.
Hahaha, yeah ok whatever. There are plenty of Unix/Linux daemons that only work if setuid/setgid, if there weren't the feature wouldn't be there. Oh and here's a quick example of how setuid bit early Mac OSX, that particular problem might now be fixed but don't act like Unix is some magic security land.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
> They may as well just be paying MS.
Except that's where you're wrong. The last person you trust is the person who made the software, or the car, or the drug. They have, shall we say, an incentive to be dishonest? The concept of independent third party is important, no less in software than anywhere else. The problem is that in software, the independent third-party is crippled, whereas car schematics and even drug formulations are published and reviewable by people who are both qualified and uninvolved.
The fact is that I do trust software makers, even Microsoft, to do their best to write high-quality software, but with the qualification that they have only a limited budget. The goal of high-quality is always in conflict with the goal of high-profit. Therefore, you need someone looking at it who doesn't have a profit motivation, either to promote or to skewer Microsoft for their software.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
I probably won't get modded at all thanks to catching this discussion so late in the game, but I managed to get an insider poke at SysInternals, hard enough that they updated their BGInfo application to fix just this problem (for a test-lab Win7 machine no less). Difference is, I routed it through a guy at Microsoft who actually lives and breathes this stuff - Aaron Margosis. Check out his blog on application compatibility and least user access, he's been working through it since XP came out, and has really helped my company make strides towards a solid-performing (more) secure desktop for my users. http://blogs.msdn.com/aaron_margosis/
Um, the daemons don't run under the user's UID, so if the user's account becomes compromised, the attacker cannot escalate privileges unless he also figures out a way to hijack the daemon. That is what I was talking about, not saying that no processes run under admin privileges. So I guess you are the one that should be mocked.
Monstar L
It's my machine. Nobody uses it but me. Why the hell would I ever run it in crippled mode? Freedom requires responsibility: fine. I'll take responsibility for what I install. I don't install dodgy software or software with viruses.
Quit treating the users like five-year-olds and let them do what they want with their own damn machines.
I piss off bigots.
"The last person you trust is the person who made the software"
I wouldn't be running software written by anyone who I distrusted that much.
"you need someone looking at it who doesn't have a profit motivation"
If they're doing it for a living, they have a profit motivation. Plus, you don't think that if MS were up to the naughties they couldn't corrupt the parties that are charged with auditing the code? Maybe not everyone, but then maybe not everyone who would see the code actually inside microsoft would keep as quiet about it as ms'd prefer.
It I guess does just come down to where you draw the line. I'm perfectly happy trusting that my copy of 2003 is perfectly fine for me to run and that ms haven't shipped it with malicious code that they're gonna use against me... and it's not blind faith, I don't think it would do their business any good, especially if word ever got out, and word would get out.
The revolution will not be televised... but it will have a page on Wikipedia
Big whoop... I've been using shims to space my HTML for years...
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.
It's a mix of blame. On one hand, there are (and have been) plenty of programs out there that don't require admin rights, and there have been for a long time. We used several on NT 4 boxes back when I was in school. So it's not like MS has made it impossible to develop them, or even much harder than it would be to develop a non-root program on Unix.
The part that MS does have some blame for is the long history of not even trying to encourage the practice. 95 didn't really have any security to speak of, and a lot of programs just targeted that platform. (Games come to mind here.) Even on NT, by default I think users had admin rights. Because almost everyone ran as admin anyway, there was little need to write your program to support limited users, which meant that app developers didn't do it.
There is a Linux distribution called GoboLinux that makes this the norm. Installing a program puts it into its own directory but also sets up some symlinks and such in /bin so that you can still call it.
It's actually quite a spiffy idea, though I haven't actually tried it. (A friend did try the package manager on another system since we wanted a package manager that doesn't require root (*remarkably* hard to find actually -- all of the major ones seem to require it; being able to install programs as non-root is one place where Windows actually wins quit a bit at, since it's usually possible, while on Linux you're thrown back into the days before package managers when you had to go through the bitch of resolving dependencies manually) without much luck, but that might have just been the weird quirks of what we were trying to do instead of anything in GoboLinux itself.)
Mostly yes, but some no: /etc used to be for everything else. In fact init was in there. To this day rc scripts live under there. /sbin used to be for static binaries and that has fallen out of fashion for reasons I never understood.
Many of the X.org/XFree86 crashes I've experienced have resulted in the entire system locking up (mainly with Intel and ATI GPUs.)
I've had quite a few graphics driver crashes in Windows as well, once again with Intel and ATI, but very few that crashed the entire system in Windows Vista. Instead, Vista restarts the driver and the session keeps on going. I've had one situation where the ATI driver caused the entire system to crash - when I was using hardware decoding to play back a corrupted H.264 video stream.
Windows Vista also has the ability to change/upgrade the display driver without losing the session - this is how Remote Desktop works.
As for OS X... I have had a few kernel panics caused by the ATI driver.
Well, that may be part of my anecdotal experience. I've never used ATI stuff...always went with NVIDIA...so, like I posted above, never really had many problems at all with graphics on linux, nor them taking the whole system down if there was a problem.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
...any stupid program that tries to write to $PROGDIR or do anything else stupid has the changes re-directed to somewhere safe.
When Vista first came out, and I was asked to test my WIN32 app to make sure it still worked, I was pleasantly surprised to find that all my ...PrivateProfile code that uses the default location no longer required me to grant global access to an .ini file in the Windows directory. They seem to make a copy under 'application data' and use that. A very simple and elegant solution that fixes a nasty problem for apps that want to just work on all WIN32 platforms.
Of course, I could've changed the app to explicitly copy the .ini files someplace writeable, but then I'd have to pick different places depending on what version of Windows I was running under. Having a default location that actually works is a much better solution. So, I cancelled my plans to code an app-specified location, figuring Vista would just solve the problem for me. But then again, Vista was Vista, so the problem never got solved. I sure wish they would've just installed this particular shim into XP. But then again, Microsoft is Microsoft, so...
Posted from my Android phone. Oh, I can change this? There, that's better...
is designed for these sort of situations. http://www.beyondtrust.com/
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?
If it's accompanied by a drastic price drop (like, 55%-75% price cut) and 99%-100% malware incompatibility, then yes.
I figure a price drop that big should be more than enough to convince a lot of users to purchase Windows, instead of pirating it and searching for cracks.
Let q be a radix > 1. I am in ur base-q, killing 10 d00ds.
The registry was supposed to replace .ini files. Of course now everyone is going back to text config files to make their apps portable.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
A bit of a shameless plug, but if you'd like more information on these "shims", I've started a series of articles on the technology (still hoping to complete it shortly) on my blog at http://www.alex-ionescu.com/?p=39. FYI, there's over 8000 of them in Windows today, and each time you launch an app, these checks are made.
Well put. +1 if I had it
In the first place...
In the second place, I think you're missing the main point of setuid. An executable can't be setuid unless the owner actually sets it setuid, or an installer program sets it setuid, which it can only do if it has inherited or received the privilege from the user that ran the installer. An executable under Unix can setuid, but only if that user has actually put in their password at some point in the past to permit it. You can't just drop an executable on a Unix filesystem and run it as root without first (1) making the executable's owner root, which requires the root password and (2) chmoding the executable, which also requires the root password.
Under windows before the modern user privileges, the application could escalate itself, with the owner of the system at no time authorizing it, through an installation process or any other means. You could drop an executable onto the filesystem from anywhere, double click on it, and it would run as admin based on a function call or a (world-settable) reg entry.
Don't blame me, I voted for Baltar.
This type of thing has been used in Windows terminal servers for awhile. Microsoft uses certain workarounds to allow more applications to run in a terminal environment with less privileges than one might have on a full workstation. Yea, not every app works in Terminal Server but most do.
In my opinion, most of this is blown way out of proportion. Most applications run fine in Vista, and Windows 7 is even better when it comes to its compatibility mode. Sure, drivers are a little point of contention but even in 64-bit Vista/W7 the support from vendors has become really good.
There's always going to be some old legacy applications that won't work right, but they're the exception, not the rule. Workarounds will be required for these applications but they're just not a prevalent as people seem to make them out to be.
- It's not the Macs I hate. It's Digg users. -
You know, nobody bought Vista anyways, and if this new debacle isn't proof enough, maybe its time for MS to let "legacy" compatibility go the way of the dodo.
I want to delete my account but Slashdot doesn't allow it.
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.
No, they're definitely not acceptable amongst *nix users. The difference is, when X11 or your WM dies (rare, but it does happen) you can just restart it without taking down the whole OS. Up until Vista, that wasn't the case with Windows.
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.
Indeed. This is no different than gnome-panel or nautilus dying (for example.) Rare, but crashes do happen.
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.
Yes. With Windows, MS has finally caught up such that the Windows GUI is now as flexible in this regard as X has been for... err... a really long time.
The real litigious bastards...
Do you need your program to work on Windows 3.1? The Windows Registry has been the preferred location for storing program data since Windows 95. I think the problem here is that you need to get with the mid-90s and rid of your calls to *PrivateProfile* APIs.
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.
If you're the military, and you DON'T review every line of code in the software you use, you should seek therapy.
> It depends on what they did to "compete unfairly". For example, it is not illegal for a vendor to have a contract with an OEM that the OEM could not buy a competitor's products if the vendor is not in a market monopoly position.
IIRC, they broke contracts, screwed over partners, and out-and-out stole other people's code and products. They lost several lawsuits over this, but the fines were small enough that they came out ahead. Wikipedia doesn't have as many details as I remember, but some of how they bent over Stac Electronics should give you an idea of the kind of games they played. There are also more recent things like this and this.
They've never been a nice company. They screw over their 'partners' more than anyone.
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.
On vista, if the display driver crashes it is restarted and none of the applications are affected. For example you could have an MP3 player in the background and if your display driver crashed, the screen would freeze for a second, and then black out, and come back while your MP3 continues to play perfectly. The user then gets a little popup notification in the system tray area stating that the display driver crashed and has been restarted.
I used to have a certain version of the ati driver that would often crash and the only time the system became unusable was during the display driver crash and if the driver crashed repetitively. But Vista makes it pretty clear to the user that the culprit is the display driver, and not the OS.
On something like linux, you'd have to have the command line skills to survive a driver or X crash. When the screen freezes, most users aren't going to do ctrl+alt+F1 get to a terminal, and restart X or unload and reload their display driver module. The fact that Microsoft attempts to do that entire process for you automatically (restart crashed driver or explorer) is what earns them the profits.
Even if the window manager crashes, the fallback non-composite manager takes over. If the shell crashes, it restarts and redraws everything. If explorer.exe crashes, ctrl-alt-delete still works, is still captured, and can be used to start task manager which can run explorer.exe.
All of those are much, much better than kicking me back to a command line.
Ctrl-Alt-Backspace
No command line involved.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
...not immediately thing of "chroot" when he heard this?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Like DLL Hell, getting the correct collection of shims to run multiple legacy apps sounds just like the situation we call DLL Hell.
I know that other Unixes do better in this regard. My comment was in reply to Linux being specifically mentioned.
how about a link to those guidelines? mea culpa I am ignorant. Then again I haven't written a win32 desktop app since 1995 ;)
Still I'm curious ;)