5 ms·

I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped ar

I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped around the old Win32 APIs, like it's 1999. (Nor Hungarian Notation). I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.

ryanmarsh 6y ago
Windows dev is a superfund site
- dylan604 6y ago
  I always heard it was a dumpster fire, but you've upped the ante by calling it a toxic waste site. Nice. I don't think I have heard a more appropriate description.
  - LegitShady 6y ago
    A delinquent toxic waste site even
chin7an 6y ago
I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS. [0] - https://docs.microsoft.com/en-us/windows/apps/desktop/ https://docs.microsoft.com/en-us/windows/apps/desktop/
- thought_alarm 6y ago
  I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.
  - ratww 6y ago
    Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.
    - rvz 6y ago
      According to this document, direct C++ interop will soon be done without the need of extern "C" wrappers. [0] [0] https://github.com/apple/swift/blob/master/docs/CppInteroperabilityManifesto.md https://github.com/apple/swift/blob/master/docs/CppInteroper...
    - jacobush 6y ago
      That's as they say, not even wrong. :-D 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.
- wvenable 6y ago
  Microsoft wanted to take developers in a direction they didn't want to go. They seemed to have realized their mistake and trying to unify this mess. In the recent past, you wouldn't find WPF and Windows Forms mentioned in the same article as UWP. Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.
  - chin7an 6y ago
    That's interesting, did not know about the carbon to cocoa move, couldn't afford anything Apple back then :) 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.
    - ratww 6y ago
      Carbon/Cocoa wasn't really a "transition" per se. 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.apple.com/cocoa/ http://web.archive.org/web/20010617021453/http://developer.a... [2] http://web.archive.org/web/20010620032754/http://developer.apple.com/carbon/ http://web.archive.org/web/20010620032754/http://developer.a...
      - armadsen 6y ago
        Both iTunes and Finder were at least partly Carbon for a long time. I'm not so sure convincing developers was the reason for that, though. iTunes 1.0 was Mac OS 9 only, and didn't even run on Mac OS X. It was a continuation of SoundJam MP, a third-party Mac app that predated the release of Mac OS X. So, really, iTunes was ported forward to Mac OS X using the same process Apple expected developers of existing Classic Mac apps to use, but that probably wasn't a decision (solely) made for developer relations reasons. 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).
- jeroenhd 6y ago
  For a language compiling to native instructions, there's really only the C(++) API. UWP is barely used in my experience and WPF/Windows Forms are basically exclusive to the dotnet framework. 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.
  - donor20 6y ago
    The push now for UWP is so misguided. I have no clue why they've decided to spend decades making apps jankier and weirder.
  - jmnicolas 6y ago
    UWP is so last year! We're all about WinUI now! ;)
    - irq-1 6y ago
      The comment looked like a joke, but somehow I new it wasn't. Microsoft always has a next-new-thing to spend your time on... https://microsoft.github.io/microsoft-ui-xaml/about.html 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.
- saagarjha 6y ago
  On macOS there’s three: Cocoa, Catalyst and SwiftUI.
  - coldtea 6y ago
    All map to more or less the same underlying libs and widgets, so there's no real difference... In Windows there are totally different widget look and feels supported...
tomc1985 6y ago
I hope WinForms never dies, it is the OG Windows "look" and much less amenable to all the web-app looking BS that permeates desktop apps today
- ygra 6y ago
  A lot of Windows Forms is non-Win32 controls with custom drawing, by the way. Especially things like menus, toolbars, etc. So a lot of Windows Forms controls are basically as native as WPF controls (just a lot harder to work with imho).
  - ratww 6y ago
    Are you sure? The source is available for both Core and old .NET and to me they all seem to be Win32 controls with some customization... unless I'm missing something. AFAIK WPF uses DirectX for rendering, so it's a bit different (it's more like Flutter... or a game engine). Button: https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/ButtonBase.cs#L1273 https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ButtonBase.cs,1266 https://referencesource.microsoft.com/#System.Windows.Forms/... Toolstrip (also base for menu): https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/ToolStrip.cs#L4792 https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ToolStrip.cs,4709 https://referencesource.microsoft.com/#System.Windows.Forms/...
    - ygra 6y ago
      Okay, perhaps my wording was off. Yes, they're Win32 controls in that sense, but many (most?) of the newer controls are no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing.
      - jug 6y ago
xfer 6y ago
WinRT/UWP is not a replacement for win32 because it's missing lots of OS apis, it's not just about the UI related apis.
- fomine3 6y ago
  True but it's intended. Win32 is too useful so it makes some security problem.

ryanmarsh 6y ago

Windows dev is a superfund site

dylan604 6y ago
I always heard it was a dumpster fire, but you've upped the ante by calling it a toxic waste site. Nice. I don't think I have heard a more appropriate description.
- LegitShady 6y ago
  A delinquent toxic waste site even

chin7an 6y ago

I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS. [0] - https://docs.microsoft.com/en-us/windows/apps/desktop/ https://docs.microsoft.com/en-us/windows/apps/desktop/

thought_alarm 6y ago
I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.
- ratww 6y ago
  Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.
  - rvz 6y ago
    According to this document, direct C++ interop will soon be done without the need of extern "C" wrappers. [0] [0] https://github.com/apple/swift/blob/master/docs/CppInteroperabilityManifesto.md https://github.com/apple/swift/blob/master/docs/CppInteroper...
  - jacobush 6y ago
    That's as they say, not even wrong. :-D 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.
wvenable 6y ago
Microsoft wanted to take developers in a direction they didn't want to go. They seemed to have realized their mistake and trying to unify this mess. In the recent past, you wouldn't find WPF and Windows Forms mentioned in the same article as UWP. Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.
- chin7an 6y ago
  That's interesting, did not know about the carbon to cocoa move, couldn't afford anything Apple back then :) 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.
  - ratww 6y ago
    Carbon/Cocoa wasn't really a "transition" per se. 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.apple.com/cocoa/ http://web.archive.org/web/20010617021453/http://developer.a... [2] http://web.archive.org/web/20010620032754/http://developer.apple.com/carbon/ http://web.archive.org/web/20010620032754/http://developer.a...
    - armadsen 6y ago
      Both iTunes and Finder were at least partly Carbon for a long time. I'm not so sure convincing developers was the reason for that, though. iTunes 1.0 was Mac OS 9 only, and didn't even run on Mac OS X. It was a continuation of SoundJam MP, a third-party Mac app that predated the release of Mac OS X. So, really, iTunes was ported forward to Mac OS X using the same process Apple expected developers of existing Classic Mac apps to use, but that probably wasn't a decision (solely) made for developer relations reasons. 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).
jeroenhd 6y ago
For a language compiling to native instructions, there's really only the C(++) API. UWP is barely used in my experience and WPF/Windows Forms are basically exclusive to the dotnet framework. 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.
- donor20 6y ago
  The push now for UWP is so misguided. I have no clue why they've decided to spend decades making apps jankier and weirder.
- jmnicolas 6y ago
  UWP is so last year! We're all about WinUI now! ;)
  - irq-1 6y ago
    The comment looked like a joke, but somehow I new it wasn't. Microsoft always has a next-new-thing to spend your time on... https://microsoft.github.io/microsoft-ui-xaml/about.html 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.
saagarjha 6y ago
On macOS there’s three: Cocoa, Catalyst and SwiftUI.
- coldtea 6y ago
  All map to more or less the same underlying libs and widgets, so there's no real difference... In Windows there are totally different widget look and feels supported...

tomc1985 6y ago

I hope WinForms never dies, it is the OG Windows "look" and much less amenable to all the web-app looking BS that permeates desktop apps today

ygra 6y ago
A lot of Windows Forms is non-Win32 controls with custom drawing, by the way. Especially things like menus, toolbars, etc. So a lot of Windows Forms controls are basically as native as WPF controls (just a lot harder to work with imho).
- ratww 6y ago
  Are you sure? The source is available for both Core and old .NET and to me they all seem to be Win32 controls with some customization... unless I'm missing something. AFAIK WPF uses DirectX for rendering, so it's a bit different (it's more like Flutter... or a game engine). Button: https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/ButtonBase.cs#L1273 https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ButtonBase.cs,1266 https://referencesource.microsoft.com/#System.Windows.Forms/... Toolstrip (also base for menu): https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/System/Windows/Forms/ToolStrip.cs#L4792 https://github.com/dotnet/winforms/blob/master/src/System.Wi... / https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ToolStrip.cs,4709 https://referencesource.microsoft.com/#System.Windows.Forms/...
  - ygra 6y ago
    Okay, perhaps my wording was off. Yes, they're Win32 controls in that sense, but many (most?) of the newer controls are no longer mere wrappers around something that exists in Win32, but rather implement all functionality in managed code, both behavior and drawing.
    - jug 6y ago

xfer 6y ago

WinRT/UWP is not a replacement for win32 because it's missing lots of OS apis, it's not just about the UI related apis.

fomine3 6y ago
True but it's intended. Win32 is too useful so it makes some security problem.