Windows 2000 to Windows Vista: Road to Compatibility
- Posted: Dec 05, 2006 at 11:52 AM
- 29,786 Views
- 11 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- MP3 (Audio only)
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
As operating systems evolve so too must the applications that run on them, but at the same time, the new OS must support the applications that ran well on previous versions.
If you're a developer, then you know the drill: You get your app to run on OS A, then we come up with OS B and you need to do work to make your app run on OS B. Of course, the Windows team spends a great deal of time writing code to make it as easy as possible for you to transition your app from OS A to OS B without having you rewrite your app...
Sometimes your app just works (no code changes on your part), sometimes you have to tweak a tiny bit of code, sometimes you have to make a fair amount of changes to your code, and sometimes you are left scratching your head wondering how in the world you're going to get your app to run on the new platform.
Well, meet Doug Wood, Maarten Van De Bospoort, Vineet Sarda, and Pat Altimore. These are some of the folks who spend their time ensuring you don't have to pull your hair out to get your app running on our new OS offerings.
Here we talk about the most common gotchas in XP to Vista app migration, dig into the compatibility problem space in general, and address developer concerns when it comes to making their code run successfully on our latest general purpose operating system. Tune in. Learn.
Check out Vineet's C9 Screencast covering session 0 isolation of services in Windows Vista and what to look out for if you are a services developer...
If you're a developer, then you know the drill: You get your app to run on OS A, then we come up with OS B and you need to do work to make your app run on OS B. Of course, the Windows team spends a great deal of time writing code to make it as easy as possible for you to transition your app from OS A to OS B without having you rewrite your app...
Sometimes your app just works (no code changes on your part), sometimes you have to tweak a tiny bit of code, sometimes you have to make a fair amount of changes to your code, and sometimes you are left scratching your head wondering how in the world you're going to get your app to run on the new platform.
Well, meet Doug Wood, Maarten Van De Bospoort, Vineet Sarda, and Pat Altimore. These are some of the folks who spend their time ensuring you don't have to pull your hair out to get your app running on our new OS offerings.
Here we talk about the most common gotchas in XP to Vista app migration, dig into the compatibility problem space in general, and address developer concerns when it comes to making their code run successfully on our latest general purpose operating system. Tune in. Learn.
Check out Vineet's C9 Screencast covering session 0 isolation of services in Windows Vista and what to look out for if you are a services developer...
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
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
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.
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
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?
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'.
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.
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...
Has anybody published an exhausive list of actions that a program may attempt that will evoke the UAC dialog?
One hopes that, in time, the complexity of this transition solution will be replaced with a much simpler security model that one can keep in one's head as one develops killer apps for Microsoft Windows.
The Session 0-Session N problem, where applications falsely believe there is only one Session active at any given time is absolutely hilarious. What is really needed is a window that incarnates Session 0. The window opens in whatever Session is being viewed at a given time. This is much better than having dialog boxes open to announce (for example, printer) problems to an invisible Session. On mainframes, there is such a thing as "an operator's console" where system global state messages constantly appear. Windows doesn't have, yet now requires, something similar.
Remove this comment
Remove this thread
close