Note I said 'deprecated' and not 'abstracted'. Back in the days of the MFC, the WinAPI wasn't deprecated because, from what I've read, the MFC merely abstracted the WinAPI. There's a difference, for a deprecated API is one who's functionality has a newer slide-in replacement as opposed to a layer on top.I ask in light of the direction Windows has taken. First, GDI objects were bypassed with WPF by using DirectX. Unless I've read misinformation, this means the Windows GUI could have been reimplemented in an API that doesn't need GDI underneath.Then came Windows 8, announcing the move to HTML/JavaScript interfaces, which means DirectX isn't needed too. Ha. Of course it is, the IE engine running such interfaces probably uses hardware acceleration provided by DirectX these days. But GDI isn't needed right?In fact, because GDI isn't needed anymore, doesn't that deprecate GDI, GDI+, MFC, and the various other templating libraries built on the GDI?Now, contrary to common thought, it's known that Windows traditionally took backwards compatibility very seriously. But how long will they go before dropping GDI? How long until .NET's core libraries are rewritten to call the kernel and private low-level Windows routines directly for services without going through the WinAPI itself? After all, C# supports unsafe code, so the public WinAPI layer being bypassed isn't inconcievable even for the lower-level stuff.I'm not talking about the C code being eliminated or anything like that. Just wondering if some of the public interfaces presented by Windows might not be available if MS deems them unneccessary in the future.
Windows GUIs: How Long Will 'Deprecated' APIs Last?
c#;.net;c;windows;mfc
Microsoft (almost) never deprecate core API functionality.And new major libraries almost never get rewritten. There is too much risk of breaking something for no obvious benefit at great expense