I understand backwards compatibility being a benefit, but why keep introducing new frameworks and ways of doing things if the old ones never get truly deprecated or cleaned up? Why highlight all the wonderful new Metro features and Universal apps if Win32/AFX/MFC/COM/COM+/DCOM/.NET/.NET not compatible with that other .NET/Silverlight/Metro never gets tidied up or moved on? It just leads to more bloat.
They've made a clean break with IE, why not do the same with Windows APIs one day? I like being able to run my ancient Win32 app and Windows API app as much as the next guy but there comes a point when they should tidy up, surely? Else why move to the new frameworks and APIs if I can still just write something in the ancient frameworks, replete with security issues?? Why bother moving to .Net?
If you love COM as much as I don't, try writing an MMC plugin in the C++ MMC API 2.0 (not the .net 3.0) one and see how well you get on with the joy of undecipherable COM messages and debugging.
I never said it was easy. It's enterprise features that HAVE to have a long lifetime.
But COM is simple interface dispatching (it is actually much easier to implement COM in C/C++ because you have actual control over the interfaces and marshaling) in the end with syntax that is a bit dated i agree. It is not rocket science by far...
They've made a clean break with IE, why not do the same with Windows APIs one day? I like being able to run my ancient Win32 app and Windows API app as much as the next guy but there comes a point when they should tidy up, surely? Else why move to the new frameworks and APIs if I can still just write something in the ancient frameworks, replete with security issues?? Why bother moving to .Net?
If you love COM as much as I don't, try writing an MMC plugin in the C++ MMC API 2.0 (not the .net 3.0) one and see how well you get on with the joy of undecipherable COM messages and debugging.