I sick to death of people complaining about UAC.
Any program that doesn't take UAC into account, or wrote before vista could have problem with vista.
It's not vista's fault, it the program's programmer's fault.



When will people learn that An Administrator Group user on Vista not the same as an XP Adminstrator.

Most of the time their problems arise because they are using old way doing things. (95 98)
Or keep assuming things are in the same place, so hard code file locations into their program.

Probably this topic should be in Software Development. Moved.

And I would agree that since Vista is pretty well established, UAC should be taken in the account. And it is actually not that hard to do that - embedding a manifest that will grant the needed privilegies depending on the situation.

The main problem I have with Vista is it's lack of backwards-compatibility. Why will ActiveX controls only work with Vista if they were created using ATL 8.0 or later? This is going to screw up a lot of legacy applications.

If someone created a program before Vista came out, why is it the programmers fault that it doesn't work with Vista? Surely Microsoft bear some of the responisbility there?

It's a good question.

How far should backwards compatibility be required of M$?

M$ has to drag around a huge amount of old code to keep enterprise environments happy. That's why they are the premier workplace OS provider. And it's why the enterprise take-up of Vista has been minimal (in relative comparison to the move to XP).

Whether home users should expect their very old code to run on their new machine is an open question. At some point people have to let history be history and move on. Where that cut-off point is is an interesting question.

Anyway, it will all be over soon and the whinging and whining about Windows 7 can start the game again.

Happily, I get to just watch it all from the sidelines with a wry smile while I happily use OS X at home and leave the hassles of getting Windows to run to the network admins at work.

Not saying there is anything "wrong" with Windows. Just that I am glad to be able to avoid the boring "UAC sux" / "Vista sux" / etc conversations with a simple "Get a Mac" response and move on with my day.

Actually I believe software developers (and hardware for that matter) hold 100% responsibility to make something work with the OS. Why should Microsoft hold responsibility for each and every software (and hardware developer) on the planet? It's not like Apple where their OS and hardware are all created and worked on by the same company. Microsoft offers an OS, and people who want their software out there should be the ones responsible for making it work with the current OS.

Just my 2¢

So, what if someone writes a program that is too advanced for Windows? By your definition, Microsoft should upgrade Vista to support it? What if the programmer cannot get access to newer versions of controls that are compatible with Vista?

Personally, I think that Microsoft should have put more backwards compatibility into Vista. Surely allowing ActiveX controls created using ATL 7.1 or earlier would not cause any harm.

Amen to that. UAC is a great feature. If you don't agree, try running Windows XP as a regular, non-admin user for a couple of months. After that, UAC seems like a real user-friendly convenience feature. At least, that's how I felt.


That's PsychoCoder's whole point, though. It's the control vendor's job to update their stuff for the new OS. If they refuse to do that, or they've gone out of business, well... sorry, but you backed the wrong horse and you're just going to have to find another set of controls. Yeah, it stinks, but it's not Microsoft's fault.


I'm not so sure of that. I wasn't familiar with this issue, so I did a little reading. As I understand it, it's not that pre-8.0 ATL controls don't work at all, it's that they don't work with DEP in certain circumstances. Apparently, Windows will actually recognize and account for this when the components is run in a program that is not marked as NX compatible, so old programs should continue to work just fine. The issue comes when a program is recompiled with the flag to enable NX compatibility or when the old component is loaded into a program that is NX compatible. In those cases, DEP kicks in and things crash. There are ways around this (like disabling DEP for that process), but the recommended fix is just to get NX compatible components.

To me, this actually seems like the correct way to do things. With thunk emulation, old programs that are totally oblivious to DEP should be able to work correctly, which seems like a good solution. But when it comes to NX compatible programs loading controls that aren't NX compatible, why should that work? If an NX compatible process can still run code from non-executable memory segments, doesn't that completely defeat the purpose of DEP?

Maybe it does, but personally, I think this may have been one of the reasons Vista did not take off. Microsoft announced this wonderful DEP and UAC to help protect the computer and the user, then didn't tell programmers or software engineers about the changes they would have to make until after it was released.

And currently, no I'm not able to get an up-to-date version of the control I've been using, and because it is an item I work with, there is no way I could get a different control (and this is my fault apparently?). And trying to find out why my control wasn't working took months of poring over Microsoft and third party websites and constant frustration until I eventually discovered about ATL and DEP. After that, I had my application completely up and running in a matter of minutes, by flagging it as not compatible with NX. Yes, disabling DEP would have been easier, but I have no guarantee that my application would be used on computers with DEP disabled.

Also, what is the point of writing applications if you need an emulator to run them?

For once, I totally agree with psychoCoder. Making sure your software works with Win is not MS's problem.
If you buy a new car stereo, you don't go to your car dealer complaining that the wiring harness doesn't match.
No, you buy a converter.

There is absolutely NO way that MS can possibly make sure that every program ever created will work with their OS, so
you really can't expect them too.
If you say "Well they should at least go back 2 years."
what about the other guy that wants 5?
or the other one who wants 10?

No, the decision should be up to MS with guarantees past it's lifecycle. It's the only sane way

and you really can't bitch about UAC. Use linux and try su or sudo to get root privliges to do anything. almost the exact same thing?

This post has been edited by TechWar: 2 Jun, 2009 - 07:23 AM

Well it's certainly not Microsoft's fault that the control vendor doesn't offer a compatible version of their control to work with Vista, now is it? As pointed out by TechWar, if I go buy a new stereo for my Toyota truck, is it Toyota's fault that the wiring harness that came standard with the stock radio doesn't match up to the one on the new stereo, well no it's not.

I get so tired of everyone blaming Microsoft because they application they (the developer) doesn't work with Vista, it's not Microsoft's fault that the developer didn't do their due diligence to find out what they need to do to make it compatible (that information has been available for a long time now).

I'll agree that it isn't Microsoft's fault if the control vendor does not upgrade their control for Vista, but it's hardly my fault either, is it? Still bloody annoying though.

When Vista was first released, they did not make life easy. In Europe, they had a court case with the EU about making parts of Vista more open so people could release compatible hardware/software. This is why there were so many compatibility issues when Vista came out. Because Microsoft did not offer proper support to people developing for their new OS.

And as for the information being freely available, yes it was. Providing you knew exactly what you were looking for and where to look for it. Trying to trace this problem down from a pop-up box on Vista saying 'This program has encountered an error and needs to close' is a little more tricky. Like I said, I was able to get my program working with Vista within minutes of finding out about this, but it took a long time to get to that piece of information.

Of course, if you had known about it, it would have been nice of you to share the information with the rest of us.

I have another simple question: Why do some people insist on writing "M$".

Does it make you feel special? Do you get 2$ from Linus everytime you write it like that?

Because "MS" is a very horrible disease that was known as such long before Bill Gates started his company.
http://www.faqs.org/health/Sick-V3/Multiple-Sclerosis.html
"MS" is taken.

Does "M$" touch a nerve?
Does it upset you?
Does it make you feel people may think less of you for choosing one of their products?

I can assure you that no-one judges you on your support or otherwise of M$. But getting a little hot under the collar about seeing it does allow judgements to be made.

There was another thread in the C++ forums about this. Basically, the reason Windows is such a security black hole is because of all the backwards compatibility. I think it's great that Microsoft is taking some steps forward.

Of course M$ makes sense for Microsoft. It's a company, it wants to make money like every single kind of companies in the world.

The funny thing I find about most UAC Complainers is that the group contains a hell of alot of linux users, specifically noob ones using Ubuntu or something similar.... Erm hellooooo? `sudo` at command line? The "keyring" at GUI? It's almost the same thing.

I personally believe UAC is a great feature, and it was just made even better in Windows 7 now that it's scaled down a little in the amount of times it requires attention from you (when logged on as an admin account).

To join the off-topicness that's started about backwards compatibility, I don't believe it's Microsoft's fault at all. The way I see Windows is like any other product... Take cars for example. If someone made a body kit for a 1999 VW Golf, would you still expect it to work on a 2009 VW Golf? No.