Comment by DaiPlusPlus | Hacker News Reader

Comment by DaiPlusPlus | Hacker News Reader

Parent Full thread

This is exactly what is holding back Win32: there has not been any serious development of the desktop developer story since WPF in 2005 (WPF only received token updates since then, the last major update was in 2010 when they finally added a DataGrid control, lol) - but WPF is not well-suited for many types of software which have to fall-back on “pure” Win32 and the story there is nothing but depressing.

Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers).

Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.

> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks

I think this might be the other way round: if they're not eating their own dogfood, it's much easier for the UI framework to come adrift from actual use cases.

It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one.

To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications.

"It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one."

That's really infuriating. Makes me wonder what all these devs they have are doing the whole day.

"To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications. "

WPF had great potential and I think they could have made it a wonderful environment if they had kept improving it. Clean up XAML syntax (maybe something like they with ASP.NET and Razor) , simplify data binding syntax and debugging, make MVVM first class citizen and it would be great. Instead they (almost) stopped development of WPF and cranked out a series of half baked successors like WinRT, Silverlight and UWP.

WPF was really nice from what I remember of it. MVVM was super easily integrated with XAML.

MVVM is great if you want to unit test all your UI code but who wants to do that.

For me the whole thing was cumbersome and nowhere near as productive as WinForms. Not only that but problems it purported to solve like high-dpi support still had issues.

With some more work like better Visual Studio integration and maybe some compiler magic it could have been fantastic.

I do Windows development since 3.0, currently maintaining a couple of Forms and WPF applications, the Forms are the hardest to maintain due event handling spaghetti code instead of proper MVVM with data binding, no use of Table/StackLayout components and still do background handling in BackgroundWorker classes.

How is the Visual Studio WPF designer these days? I worked on a WPF app around 5 years ago, and the form designer in Visual Studio was appalingly slow and quite buggy.

I also wasn't a big fan of XAML - no matter how much time I spent using it, it mostly seemed more difficult and awkward to get components where you wanted them than with WinForms.

Quite good. I always do a mixture of Blend and Studio.

Never had any big problem that I can remember of since Visual Studio 2012.

2012 had big internal architecture changes that did a lot to stabilize the designer.

The designer is fine now.

High DPI support for WinForms has been improved in the .NET Framework 4.8 https://github.com/Microsoft/dotnet-framework-early-access/b...

The majority had stopped at (right before) WPF it seems

> In fact, at a recent conference I was at with a large group of C# consultants. When the audience was polled on which desktop UIs their clients were using, the vast majority were WinForms, a small group was WPF, and almost no one was UWP

https://iamtimcorey.com/ask-tim-is-winforms-dead/

And many did long before WinForms

> Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API.

https://blog.submain.com/death-winforms-greatly-exaggerated/

When Apple introduced Cocoa they also introduced Carbon however, an extension of the legacy MacOS APIs. Apple already slowly killed their Win32.

It's actually kind of impressive how much transitional stuff Apple has introduced and then removed with Mac OS X and how right many of their decisions turned out. I guess Cocoa itself was an extension of the legacy NextStep API too. They also had Classic for running old Mac apps directly in OSX and later Rosetta for running PowerPC binaries on Intel (I guess the same tech was used for the 32->64 bit transition). So many technologies have been smoothly deprecated and removed over the years by Apple.

I don’t think you really can compare Apple’s and Microsoft’s situation here. Think of the extreme bigger amount of software that was written for Windows including all that custom made business software for small companies. Apple was always in the situation that a lot of their 3rd party developers were also „fans“, who are more willing to keep up with their transitions, where however most the Microsoft tech developers were just doing their job and want to keep their stuff only running with the least amount of work necessary.

Apple was always in the situation that a lot of their 3rd party developers were also „fans“, who are more willing to keep up with their transitions,

That's true, but Apple also got behemoths like Adobe and Microsoft to port over their applications to modern APIs (Cocoa and Cocoa Touch).

Because Apple does the "take it our way or leave" approach.

Which is also a reason why they hardly have a meaningful market share across the enterprise world.

Sure they do. It’s on mobile. While MS isn’t going anywhere in the Enterprise, anyone who is focused on the desktop when it comes to MS development instead of web, cloud, or even cross platform mobile development is headed down a dead end.

A little secret, laptops and 2-1 convertibles are desktops as well, while being mobile.

If we want to be pedantic, a desktop could be considered mobile too since you can pick it up.

But in the real world when people talk about “mobile software” everyone knows that people are talking about iOS and Android. No one is chasing after the Windows software market, it’s been a diminishing platform for the past decade.

In the real world people are working on laptops, while using iOS and Android mostly to consume content, play games, browse web and show plane tickets.

When they actually become a match to laptops and 2-1 convertibles, maybe.

And there Chromebooks are no where to be seen outside US school system, iPad Pros are mostly a gimmick in rich countries and Android 2-1 are basically phone apps with keyboard.

I am not saying that people aren’t using desktops to do work. What I’m saying that relatively few companies are putting money into writing desktop software. The jobs are limited compared to writing web based software.

If I ever got back into desktop software, it would be highly specialized low level C/C++ code and not WPF/Sharepoint/UWP software.

Yes and no. They've taken down the documentation, but there's still a number of (non-GUI, non-kernel) Carbon APIs that are still not deprecated (as of 10.11, at least), and still allowed in the Mac App Store.

I'm using AHGotoPage() because NSHelpManager has no equivalent and nobody has been able to explain to me how to make that class do a similar task reliably. (In hindsight, AppleHelp is such a disaster that I should have just avoided it entirely, as almost every other app does.) MAS reviewers have given me grief over many things my app does, but never any Carbon calls.

The last time I saw any Carbon APIs deprecated was 10.8, I think (6 years ago).

They're about to removed (carbon apis) AFAIK with the move to 64bit only no?

What's bad about GDI? (I used to do windows but have not been following, I remember that you need to do GetDC and ReleaseDC on a window handle to get the device context and then to release it - in pairs, else...)

It's a graphics API designed for early-1990s needs. It's missing things we expect today like 30-bit colour support and all-VRAM memory (GDI was hardware accelerated but they gimped it in Windows Vista to ensure compatibility with the DWM).

When working with Win32 it just isn't possible to avoid having to use GDI, for example dealing with painting to a window surface Win32 will give you a GDI device context by default - for example, similarly handling Win32 messages like WM_PAINT uses parts of the GDI API. Finally, each process on Windows has a limited number of GDI objects it can use as well. Oh, and using GDI/GDI+ in a service context (e.g. ASP.NET or a Windows Service, is not supported: https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-...)

Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.

SharpDX and SlimDX are fantastic wrappers for Direct2D, last time I was doing anything with it. SharpDX is the more active of the two.

> Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.

They do for Direct2D on UWP, https://github.com/Microsoft/Win2D

It doesn't do antialiasing.

GDI+ does.

GDI+ Is better in a lot of ways, but has the major downside of being limited to software rendering only.

GDI+ is a completely different replacement API, not just an extension/update of GDI.

> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks

The story is so bad because the Microsoft units making flagship desktop apps aren't productizing their UI frameworks (not suggesting that this is their choice), instead leaving the firm with public UI framework offerings not tightly grounded in that kind of use experience.

Good frameworks don't lead to internal flagship use, internal flagship use leads to good frameworks through tight feedback between real-world use and framework development.

remember WinJS, another vapourware

Reply on news.ycombinator.com