[0] - https://docs.microsoft.com/en-us/windows/apps/desktop/
Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.
If both platforms had to handle such migrations, I guess it's only fair to say that Windows' solution would be much more difficult given how committed Microsoft is to maintaining backwards compatibility.
Cocoa was not only older (the API comes from NextStep), it was also always marketed as being the "Native" API from day one [1]. Carbon was a secondary API marketed by them as a way of having "applications that also run on previous versions of the Mac OS (8.1 or later)" [2]. Carbon apps were uglier, clunkier and harder to write/maintain than Cocoa.
Now that I remember it: Back in the early 2000s Cocoa was so much better that they had to write iTunes (or was it Finder?) in Carbon to convince developers that Carbon was able to handle real world apps.
The problem with Carbon is that companies like Adobe, Autodesk and Microsoft overstayed their welcome and dragged their feet for almost 10 years instead of porting to Cocoa like Apple recommended in conferences. To convince them to port, Apple deprecated Carbon it in 2007 and removed it 12 years later in 2019.
[1] http://web.archive.org/web/20010617021453/http://developer.a...
[2] http://web.archive.org/web/20010620032754/http://developer.a...
I don't know much about the history of Finder in this regard, unfortunately. It of course existed from System 1.0 in 1984, but how much of Mac OS X 10.0's Finder was a complete rewrite and how much was ported from Classic Finder vs NeXTStep is something I have no idea about. It certainly had UX that came from NeXTStep (the column browser, for instance).
It was for Finder. During one of the WWDCs or MacWorlds (I don't recall which), Jobs specifically mentioned that Finder was written in Carbon as a way to show that Apple eats its own dog food. It was the big demonstration that Carbon wasn't some second-rate API … although, of course, it was.
Dogfooding as a concept isn't Apple-specific but it's definitely a meme in Apple circles — especially when Apple is detected as specifically not eating its own dog food!
- On old 90s hardware, Carbon could be faster (due to the C API)
- Apple didn't invent AppKit or Objective-C. That technology was inherited from NeXT and from what I understand there was push-back both within Apple and from the Mac developer community about adopting a language with an unusual syntax that nobody used.
Apple tried to transition Objective-C to a modern C++ style syntax, and failed.
Apple tried to get developers to use Java with AppKit (hence, the name Cocoa) and failed.
Apple tried to get developers to adopt garbage collection, and failed.
In the end, they didn't need to do any of that. Mac developers eventually became quite enthusiastic about Objective-C and AppKit and it quickly because the one true way to write Mac apps.
However, it took many years for Cocoa and AppKit to become fully formed. Up until 2009 and OS X 10.6, there were still many things that couldn't be done in Cocoa and required the Carbon APIs, mostly related to the Mac-specific features of the file system, like persistent file references, icons, metadata, etc.
For example, if you want to implement a UI for copying a file, you're going to want to display a progress bar and have the ability to cancel the operation. Up until OS X 10.6, that simply couldn't be done with Cocoa (NSFileManager, NSURL, etc.). You had to use gnarly Carbon APIs.
(Actually, it still can't be done with NSFileManager, but Apple added that ability to the Darwin file system APIs.)
That's why the Finder was initially implemented in Carbon.
And little bits if Carbon still live on in the modern 64-bit Mac world. If you want to implement global Hot Keys in your app you have to use the Carbon API and convert the Carbon key-codes to their AppKit equivalents.
Windows Forms and the native API share most of their controls' look and feel while WPF is a free-form application framework that allows you to ignore all UI standards if you desire to. I can't remember the last time I've seen a WPF application though, I think it's either dead or dying already.
UWP is the new API Microsoft really wants everyone to use. It comes preloaded with the "native" Windows 10 feel with their new design and is intended to be distributed through the MS app store (though you can install packages manually with some effort as a developer).
It's what new applications aiming to be Windows native probably should be using in my opinion, but most developers seem to stick to the native API or its wrappers. That means there's barely any UWP applications in use by most people, which means they aren't used to the UWP style, which means they find UWP apps weird, which means there's barely any UWP apps, etc., etc., etc.
https://microsoft.github.io/microsoft-ui-xaml/about.html
> WinUI 3 is the next version of the WinUI framework, shipping later this year. It dramatically expands WinUI into a full UX framework, making WinUI available for all types of Windows apps – from Win32 to UWP – for use as the UI layer.
[0] https://github.com/apple/swift/blob/master/docs/CppInteroper...
The C ABI is stable. Any (normal) C compiler and a bunch of compilers of other languages can produce blobs which can be linked with each other, and by extension with C++ code with extern "C" declarations.
In Windows there are totally different widget look and feels supported...