,AndyC wrote

One of the things said during the keynote was that trying to come up with a complete replacement for Win32 in WinRT was too much for a single release, so the initial focus was on Metro. Which is why I think it's to be seen as the start of a clear shift in direction away from all the legacy tools whether they be WPF, Silverlight or Win32 itself.

As a rule of thumb, APIs that are documented on MSDN will continue to work as documented for at least 5 full years after they become marked as "obsolete do not use", and core APIs used by everyone won't change for at least 10 years afterwards.

The simple reason for this is backwards compatibility of programs and of source code. If Microsoft said "LoadLibrary" is now obsolete - all you guys using "LoadLibrary" now need to call "LoadWinRTLibrary" then every piece of software currently running on Windows would need to be recompiled, retested and reshipped to customers (massive expense to developers) and for all the programs that didn't (e.g. old games, old versions of software and software where the maker went bust or got bored and moved to do other things) would need to be shimmed by Microsoft, at massive expense to Microsoft.

What normally happens is that new APIs are formed and one calls the other (usually the old calling the new, but sometimes both calling a new intermediary). That way LoadLibraryA, LoadLibraryW, LoadLibraryExA and LoadLibraryExW all work as expected, but the functionality is all contained in LdrLoadDll and NtMapViewOfSection, even though nobody outside of Microsoft ever calls those functions directly.

In summary, Win32 will still be functionally equivalent to today's Win32 in 2020, with WinRT becoming the standard over the next decade, rather than becoming mandatory in the next release.