3 ms·

A key difference with the Microsoft approach vs the Apple approach is that on Windows the API that exposes every single feature is such a beast that developers

by mhenr18 10y ago

A key difference with the Microsoft approach vs the Apple approach is that on Windows the API that exposes every single feature is such a beast that developers are expected to work at a level above that API. Whether it's WPF, WinForms, WinRT, or whatever the new flavour of the day is, it's always a layer on top. And that layer is never perfect, because you still have to do the occasional [DllImport("Kernel32.dll")] interop reference. Here are the currently supported ways to deal with windows on Windows: * HWND * System.Windows.Window * Windows.UI.Xaml.Window On OSX, you use Cocoa. When Apple introduced Swift, they didn't have to layer on top of the API accessed by ObjC. When you write Swift code, you call the exact same APIs as you would have done with your ObjC code. Here are the currently supported ways to deal with windows on the Mac: * NSWindow

pjmlp 10y ago
You use Cocoa in 2016. There was the Object Pascal Toolbox, replaced by C Toolbox (MacApp), replaced by MPW, replaced by PowerPlant, replaced by Carbon, replaced by Cocoa. I can list many other examples, even Cocoa has lots of deprecated APIs since OS X 10.0.
- mhenr18 10y ago
  Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. Carbon/Cocoa was the last time that OS X has had a dual-API situation but even then, Carbon was always referred to as the transitional library and Cocoa was always referred to as what you should use for new code. While Apple floundered during the 90s with their OS strategy, their API strategy in OS X has been absolutely rock solid. It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all). Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated.
  - pjmlp 10y ago
    > It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all). There are quite a few 32bit apps making use of it and they will never be ported to Cocoa. > Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated. Win32 and MFC are deprecated for new applications, the way forward is UWP with XAML. Project Centipede is just for porting existing code into UWP world. Windows Forms was officially deprecated at BUILD 2014. https://www.infoq.com/news/2014/04/WPF-QA https://www.infoq.com/news/2014/04/WPF-QA
    - deleted 10y ago
      [deleted]
  - CJefferson 10y ago
    > Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. That's not a bad thing. It means if I wrote an app 5, or 10, or 15 years ago, I can keep working on it and updating it without having to throw most of the code away and start again.

by mhenr18 10y ago

pjmlp 10y ago

You use Cocoa in 2016. There was the Object Pascal Toolbox, replaced by C Toolbox (MacApp), replaced by MPW, replaced by PowerPlant, replaced by Carbon, replaced by Cocoa. I can list many other examples, even Cocoa has lots of deprecated APIs since OS X 10.0.

mhenr18 10y ago
Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. Carbon/Cocoa was the last time that OS X has had a dual-API situation but even then, Carbon was always referred to as the transitional library and Cocoa was always referred to as what you should use for new code. While Apple floundered during the 90s with their OS strategy, their API strategy in OS X has been absolutely rock solid. It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all). Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated.
- pjmlp 10y ago
  > It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all). There are quite a few 32bit apps making use of it and they will never be ported to Cocoa. > Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated. Win32 and MFC are deprecated for new applications, the way forward is UWP with XAML. Project Centipede is just for porting existing code into UWP world. Windows Forms was officially deprecated at BUILD 2014. https://www.infoq.com/news/2014/04/WPF-QA https://www.infoq.com/news/2014/04/WPF-QA
  - deleted 10y ago
    [deleted]
- CJefferson 10y ago
  > Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. That's not a bad thing. It means if I wrote an app 5, or 10, or 15 years ago, I can keep working on it and updating it without having to throw most of the code away and start again.