I agree that Microsoft's documentation is stellar for their Windows APIs. Apple's is noticeably worse.
However Microsoft's APIs are not "more stable" than Apple's - in fact the Microsoft APIs change constantly. See Win32 -> MFC -> WinForms -> Silverlight -> WPF -> UWP -> WinRT... Or for languages, maybe you want to use or C++/CLI or C++/WinRT or C# or VB.NET or F# or JavaScript or the language they'll introduce next week. The treadmill is real and exhausting; what is a modern Windows app anyways?
For comparison Apple wants you to write Mac or iOS apps in Swift, or in Objective-C if you can't use Swift.
> However Microsoft's APIs are not "more stable" than Apple's
You can pretty much always run apps for Windows XP (released 2001) on Windows 10. You can't run any apps from OS X 10.0 (released the same year) on modern macOS. Yes, there was a processor architechture change in there (and a subsequently dropped compatibility layer), but the APIs have changed enough that that isnt the main issue.
Microsoft abandon the entire API, and replace it with something new every couple of years (the grandparent comment has a good list). This has the benefit that once software does work it should continue working more or less indefinitely.
Apple have mutated the same API over many years, however Xcode's default settings drift, deprecations are frequent, and the new macOS is rarely backward compatible with a large application. This means that each summer when the new Xcode/macOS combination is released you have to spend some time getting up and running again.
I doubt that the ideal situation of a continually developed API with perfect backwards compatibility exists. In that case the getting your code building and running with the new Xcode/macOS each summer is likely less time consuming than rewriting against a new API every 5/10 years. If you are maintaining well established code, then the opposite is true.
I recently installed something that was probably first targeted Windows 98.
The APIs listed by GP are deprecated and the platforms are not shipped/enabled by default, but that's worlds apart from intentionally breaking them (with almost no communication).
Of course, I still prefer a good package manager and direct access to the source on GitHub/GitSomewhere, but MSDN is very well maintained.
Microsoft is a little weird. The safe bet for a desktop application is to do it in WinForms. I'm pretty convinced that Winforms will outlive any of the newer frameworks from Microsoft.
The XAML developers will jump to whatever the next thing is when it comes around, but the conservative WinForm developers won't go anywhere anytime soon, forcing Microsoft to continue supporting and developing Winforms.
Throwing together a quick WinForm application is still much faster than building something using XAML, in my opinion. Especially if you don't know what you're doing, and that still how many in-house business applications seem to be built.
MS has backwards compatibility for existing software, but it's a gamble to start a new project using MS tech, you don't know what they will cancel, rename or invent next year.
Apple doesn't have backwards compatibility for existing software and stuff breaks regularly from version to version. However, one can count on Objective-C to pretty much work (although Swift is still work in progress).
I generally like MSDN's documentation, despite Google always sending me to an old version every single time (get on top of your SEO, Microsoft). That said...
Fairly recently, I was looking in to controlling a service using C# and while the docs claimed that System.Management was deprecated, I could not find code samples anywhere that did what I needed without using System.Management.
It doesn't seem like it's actually deprecated, and I couldn't find any corroborating claims that System.Management was deprecated, the mention only seems to exist on a single MSDN page. This one, in fact: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
> Classes in the Microsoft.Management.Infrastructure namespace. (The System.Management namespace is no longer supported). For more information, see WMI .NET Overview.
What exactly does "no longer supported" mean if not deprecated? Why is it still in use if it's not supported? Why don't the System.Management docs mention this at all?
Full disclosure, I'm saying this as a very non-C# guy, so my relative inexperience with that ecosystem is absolutely a factor. But my thinking is that, if you're already a decently skilled programmer, you should at least be able to interpret documentation so long as it's not astoundingly terrible. In this case, there isn't a clear answer to my question, so I'm just left feeling like I'm writing doomed code.
Sorry for the rant. It's a relatively minor gripe, to be sure, but it needs fixing.
No, he means Swift and Objective-C. That's what was, is and will be supported.
On the other hand, Microsoft's API screw-ups are legendary at this point... not even they know what developers should use for Windows apps. I think Windows Phone was recently canceled, so that simplifies things a bit.
And even if there was such a blessed SDK/language combination, they'd probably drop it or rename it next year ;-)
I've found that C++/MFC and C#/WinForms are the one that are stable and actually work over the long term. Our >20 year old app runs a lot of MFC code that is unmodified from that era.
However Microsoft's APIs are not "more stable" than Apple's - in fact the Microsoft APIs change constantly. See Win32 -> MFC -> WinForms -> Silverlight -> WPF -> UWP -> WinRT... Or for languages, maybe you want to use or C++/CLI or C++/WinRT or C# or VB.NET or F# or JavaScript or the language they'll introduce next week. The treadmill is real and exhausting; what is a modern Windows app anyways?
For comparison Apple wants you to write Mac or iOS apps in Swift, or in Objective-C if you can't use Swift.