Versioning WPF
Versioning is a fascinating topic to me because it's such a hard problem. The goal is to ensure a high level of compatibility without sacrificing the ability to innovate. There's two major strategies -- "roll forward", where old programs always use the latest version of WPF, and "side-by-side", where multiple versions of WPF can coexist on the same computer and old programs use the version of WPF they were designed for. Both can work, Microsoft has used both at times, but they come with some hard trade-offs.
The problem with roll forward is that any change is potentially an incompatible change. Before I came to Microsoft, I thought compatibility was easy -- don't change any API signatures, and you're compatible, right? If only it were so. Applications have been broken by fixing a memory leak (they used data after they freed it). By fixes to buffer overflows (they passed in too small a buffer and didn't care about the memory that got clobbered). By the order in which virtual methods get called. By recompiling a function with a different compiler (some applications copy system functions and patch them). By changing parameters to an internal function. By returning screen coordinates that weren't possible on previous versions of Windows. Etc.
So the reality is, with a roll forward strategy, there's no such thing as perfect compatibility. And for a really widely used program like Windows, the only way to achieve a Windows level of compatibility is with lots and lots of testing, together with a lot of shimming. Shimming is where Windows patches an application so it can run successfully -- it's expensive to test the applications, it's expensive to write shims, and you never get every last application -- but it's better than not being compatible.
Side-by-side says that nothing is as compatible as the platform you developed against, and that no amount of features or perf work in the newer version is going to outweigh compatibility. But side-by-side has its own problems, namely that you're dealing with an explosion of versions. Ten versions later, does every computer need ten versions of WPF? Having 10 copies taking up disk space and memory is an obvious problem, but that's not even the biggest problem. How do you test it all? Because now, you need to make sure WPF versions 1-10 all work with the rest of Windows 2016. Remember, there's always some component that can't be side-by-side (having side-by-side desktop window managers would be pretty weird), so you need to retest everything with each version of Windows.
It gets worse. If you have to test it, you also potentially need to change it (Windows doesn't shim Windows!). Plus, a released version actually changes over time -- think of security patches and service packs. And there's even issues about which compilers you use -- every version of Windows uses a different version of the Visual C++ compiler. So if you have N versions of Windows, you're looking at N * (N+1) / 2 different WPF binaries to test -- and you need to test all of them if you come out with a security patch that affects all N versions. And we haven't even begun to talk about mixing and matching different versions of different DLL's!
So a realistic side-by-side plan has to constrain this somehow. One proposal I've heard (and as far as I know it's just a proposal) says that you cap the number of supported versions in accordance with Microsoft's support lifecycle. And you version of all the side-by-side DLLs together -- no mix and match. And WPF 2006 on Windows 2009 will be the exact same binary as WPF 2006 on Windows 2006. Which limits the number of binaries and puts a cap on N, although it's still an N * (N+1) / 2 test matrix since you need to test them on all the different versions of Windows.
So where does WPF stand in all this? Right now, we're doing the only sensible thing -- we're keeping our options open. We're trying hard to be extremely compatible in case we do roll forward. But we're also making sure we support side-by-side. Because right now, we just don't have the data we need to make an informed decision -- how many applications are going to be using WPF 1.0, and what kind of compatibility problems will they have with WPF 2.0? Pretty hard to say when you haven't even finished beta two. <g>
Comments
- Anonymous
October 30, 2005
Side-by-side can work great for standalone apps, but if you are developing plugins/extensions (or if your app can accept plugins/extensions) then you can quickly run into problems. Take for example the limitation of one CLR running per process: Your app can't have two plugins running with two CLR versions. (see http://blogs.msdn.com/marcmill/archive/2005/09/17/470671.aspx for how this affects Windows Explorer)
I'm assuming that WPF, since it is built on top of a specific version of the .NET framework/CLR, will be limited to one instance/version per process. In cases like this, forward compatibility is the only option. - Anonymous
October 30, 2005
I think in the Internet age where it is standard that programs get updated for ex. security reasons, it's not too much to ask for 2-3 major versions of roll-forward with breaking change possibility. By this I mean that an app devd for .NET 1.0 for example, would be required to be updates at worst case 2 times unless there's breaking changes in service packs. Thus making one update round at .NET 2.0 and .NET 3.0.
After that .NET 3.0 would go side-by-side, so if there is a .NET 4 ever, the 3 would be kept around.
Or alternatively
Roll-forward for 1 to 2, then have 2 kept for side by side with 3 or 4 (another roll-forward). - Anonymous
October 31, 2005
The comment has been removed - Anonymous
October 31, 2005
I believe that all major frameworks need to be a side-by-side. This includes, the .NET framework, WPF, WCF, WinFS, etc...
As long as the applications are marked with the versions of the particular framework they are compiled for, everything should be fine, and innovation won't suffer. - Anonymous
October 31, 2005
I like the SxS with limited supported versions. It gives you the flexibility you need to change the API between versions and guarentees that your update will not destroy existing applications.
How you choose which versions are supported and for how long, well that's always gonna be tricky. Nobody's ever going to be happy with the answer, 'cause let's face it there's someone out there still trying to run their business on some old DOS app, but wants to upgrade everyone in their company to Vista and they just expect it to work. Personally I find this ridiculous and wish Microsoft would be a lot more willing to break compatibility than they are today. For example, I personally wouldn't shed a tear if Vista wasn't backwards compatible with anything other than XPSP2/2k3SP1. ;P
Just my 2¢,
Drew - Anonymous
November 01, 2005
The comment has been removed - Anonymous
November 02, 2005
Wasn't .Net going to, at some point, include a new organizational structure above Library, like Framework, to alleviate versioning issues of this kind? It's been so long since I read that, I can't even recall the details as to how it would even work, but I think the idea was to simply add a way to version a set of assemblies that denotes a particular framework (i.e. .Net or WPF/WinFX, etc.), which gets you somewhere close to "Works with XP and Above" - Anonymous
November 07, 2005
The comment has been removed - Anonymous
April 06, 2006
Raptor, you're wrong about Win32 and Office compatibility. I recently did a Windows update on my girlfriend's machine and some Office app started crashing on launch. Luckily, I realized there might be a update for Office, applied it, and the crash went away. (In fact, the release notes described it.)
And yes, I then signed her up for automatic updates of both Windows and Office. - Anonymous
April 06, 2006
Marc Brooks, you need to spend more time reading Raymond Chen's blog so you can divest yourself of this notion that Microsoft has the option of breaking apps which misbehave. Although many entries cover this kind of territory, here is a decent example:
http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx