Windows 2000 to Windows Vista: Road to Compatibility | Charles

PolymorphicCode

If an application was written in Vista, would it be backward compatible with XP, 2000, Me, 98, 95? Or will it only wok for Vista? and then Have to write one for the other earlier Versions of Micro$oft Windows Operating Systems?

Charles
Welcome Change

PolymorphicCode wrote:

If an application was written in Vista, would it be backward compatible with XP, 2000, Me, 98, 95? Or will it only wok for Vista? and then Have to write one for the other earlier Versions of Micro$oft Windows Operating Systems?

Well, it depends on whether or not the application relies on Vista-specific APIs which will of course not be present on earlier versions of Windows... It depends on what the app does and what it expects to be present on the underlying system to do it's work successfully.
C

littleguru
<3 Seattle

PolymorphicCode wrote:
If an application was written in Vista, would it be backward compatible with XP, 2000, Me, 98, 95? Or will it only wok for Vista? and then Have to write one for the other earlier Versions of Micro$oft Windows Operating Systems?

If you don't use any of the Vista only features, why not? And if you use Vista only features you only need to check in your app for the current OS version before using these features and do a fall back to another mechanism if the OS doesn't support them.

It's easier to write code for an existing OS then write code that should work on currently non existing OSes.

To achieve a working app for future OSes follow the guidelines specified by the Windows team or/and use the .NET framework, which is somehow OS indipendent.

PolymorphicCode

Thanks for the replies.

More specific question is with respect to User Account Control, would my vista application break in xp, as xp has a different model for the way access is granted than Vista?

The checks and balances would return errors? If Check for admin privilage, no account elevation, must supply admin password? Account switching , cross thread account validation?

Vista is new, so Micro$oft is giving us hardtime to adapt to these things. I wish things just work and the .NET Framework would do the magic underneath, and I program the same way I do in XP Expressionless

Nick Manley

PolymorphicCode wrote:
Vista is new, so Micro$oft is giving us hardtime to adapt to these things. I wish things just work and the .NET Framework would do the magic underneath, and I program the same way I do in XP

I too was wondering about native win32 versus .NET code. From what I understand the .NET framework will handle the UAC and most .NET developers shouldn't worry too much about it. I imagine though that anyone who developed using the native APIs will be the ones who see the majority of these problems. Can anyone confirm this or provide additional information? Also, the video seemed to imply that Windows will "watch" the application and when it sees that it is trying to perform an admin function (altering system files, registry, ect.) will invoke the UAC prompt. Is this correct or does the developer need to invoke the prompt in his code via a function call of some kind?

ZippyV
Fired Up

I think it's important for Microsoft to make the 'Compatible with Windows' guidelines more known to other developers/companies. This is something where they failed in with Windows XP, so I hope things will change with Vista.
There are still too many companies that release software which violates every possible 'best practice'.

Fayez AlMutairi

wrong place Smiley

brokeMyLegBiking

Nick Manley wrote:

I too was wondering about native win32 versus .NET code. From what I understand the .NET framework will handle the UAC and most .NET developers shouldn't worry too much about it. I imagine though that anyone who developed using the native APIs will be the ones who see the majority of these problems.

The short answer is if you turn off UAC, my .NET app works fine on Vista.

When I took the effort to switch from VB6, to .NET (which was no small migration), I too believed that my app would work just great in Vista without any code changes. As far as class libraries and methods, these are all there and work great on Vista, but as far as UAC, it is not pretty:

1) .NET methods and libraries work without a problem on Vista just like they do in XP. This is great, and this is what I hoped for by migrating my app to .NET. I don't have to worry about creating separate installers like I did for my VB6 app for Win2k and XP. Another example: I don't have to worry about differences from XP to Vista regarding the operating system paths because by calling the System.Environment.GetFolder(Desktop) for example because .NET will resolve it correctly on both platforms, even though the physical paths are different.

2) Ok, now the bad news. UAC causes lots of problems for my app during install and auto-updating. Like they said in the video, apps which "auto-update" and try to write to the program files directory have problems.

The good news is that you can turn off UAC. Anyone who runs my app on Vista is going to have to turn off UAC and run as an administrator to be able to install or update my app. The app runs fine for a standard user, but for updating its database, which happens once a month, they are going to have to turn off UAC, which makes Vista more XP-like as far as priviledges. I'll work to make my app work as well as possible with UAC, but I'm a one man development shop, so it's going to be a few months, if ever.

Rasmus Therkelsen

If you store your database in the Vista equivalent of "Document and Settings\All Users\Local Application Data\your app name\databasefile.dat" you shouldn't have any problems at all.

Furthermore, if your application stores data in the registry, always fall back to writing in CURRENT_USER instead of LOCAL_MACHINE if you get an access denied when attempting such operations.

I think this really will solve your problem because six months from now no one will accept an application where you need to turn off UAC.

Just my two cents... Smiley