APIs are an essential piece of software technology, and they play a major part in making the various hardware components and software programs we use work together. Periodically, new APIs are created as a means of increasing efficiency and enabling more advanced features, but the side effect of designing new programs to use those APIs can limit software compatibility with systems that don't have them. This has resulted in some problems in the past, but Microsoft is developing a new technology in order to resolve these issues.
Microsoft's plan to deal with these problems is to group similar APIs into "contracts." Each contract is essentially a list of similar APIs that can perform the same task. Later, if a program tries to run and cannot find the appropriate API that it requires, but a similar API in the same class is present, it will be able to use that API instead.
Previously, many applications have been capable of running with multiple alternative APIs, but the programmer was required to anticipate that scenario and write in code that points the program to secondary APIs that it could use instead.
This could be quite time consuming, and often wouldn't cover all potential backup APIs. Program developers will need to tweak their code a bit in order to take advantage of this new technology, but now with a single line of code, they will be able to point to all potential backup APIs, making their work easier, too.
Eventually, this new method of dealing with APIs will extend program support across a wider range of platforms and devices, but it will have limited effect in the near future. Microsoft is implementing this approach to APIs starting with Windows 10. Because all Windows 10 systems will have essentially the same API support, these advantages won't be realized until later.
As Windows 10 is the first to group APIs into these "contracts," it will not help programs designed for Windows 10 to run on Windows 7, 8 or 8.1. Once the successor to Windows 10 is released, however, this technology will become increasingly useful to those who continue to use Windows 10, as it will allow applications designed to use newer APIs that Windows 10 lacks to run on the (at that time) older OS. It will achieve this by using the API contracts and selecting a similar alternative API that is capable of performing essentially the same task. This might result in a performance or stability drop compared to the newer system, but at least the application will be able to run.
When Microsoft releases Windows 10 on mobile devices, there should be some level of benefit to this technology right away, as mobile operating systems are typically somewhat cut back in order to save space.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
For now, this should help reduce the amount of work when writing a program without needing to point to multiple APIs, as the programmer can simply point to the API contract. In the long run, it could extend software support to multiple platforms and versions of Windows.
The upside is failover cases as mentioned in the article and seemingly automatic upgrades as stuff changes (AKA, code deprecation).
My worry is if this "contract" (used differently from "Design by contract") means that API usage can be swapped. What if I, say, add an ad to my app. What's to stop this from going "you seem to be using an ad API that may be slow and buggy, I'll swap out that API with my own which is fast an efficient... but you won't get the ad revenue"? You may never know (enough OSes have a "is debugger attached" check with certain high-use functions). Is it likely? No... but unless the source code is available, or they forgot to put the "is debugger attached" check before the function swap, what's letting you know that it happens?
This is an interesting counterpoint to their traditional "embrace and extend" philosophy, whereby Microsoft implements some standard API or format, and extends it with proprietary features that lock apps into their implementation. My guess is that they want to make it easy to swap in their implementation for apps written against competing APIs.
As a shear matter of practicality, I wonder how general it'll really be. Perhaps this is some marketing spin, when the reality is that some MS employees will be hand-coding the actual translation layer for each API. I actually hope that's the case, because any developer who's ever ported anything from one API to another will tell you that they're rarely identical in function. Constructs in one API nearly always have slightly different semantics and work in slightly different ways than comparable elements of similar APIs. So, color me skeptical.
