Earlier quoted context omitted.
Because Microsoft supports critical applications that businesses use for well over ten years in a lot of cases. Zero other operating systems have to provide the platform stability that Microsoft does. So, of course, if they have to focus on supporting only one, archaic platform, they never move forward or create anything new or improved. Which doesn't make sense. So you continue to create newer, better platforms, but…
They only have to provide this because they lock down their products. They do it to themselves.
Calling Windows 10 APIs from a WinForms or WPF application
21–30 of 71 posts
Re: Calling Windows 10 APIs from a WinForms or WPF application
#22Earlier quoted context omitted.
Because Microsoft supports critical applications that businesses use for well over ten years in a lot of cases. Zero other operating systems have to provide the platform stability that Microsoft does. So, of course, if they have to focus on supporting only one, archaic platform, they never move forward or create anything new or improved. Which doesn't make sense. So you continue to create newer, better platforms, but…
They only have to provide this because they lock down their products. They do it to themselves.
This will probably never change.
Re: Calling Windows 10 APIs from a WinForms or WPF application
#23Some Apple docs for comparison: https://developer.apple.com/library/content/samplecode/Metal...
Re: Calling Windows 10 APIs from a WinForms or WPF application
#24Earlier quoted context omitted.
They only have to provide this because they lock down their products. They do it to themselves.
This is only partially true. A large issue is that most of the software that runs on top of their products is also locked down. So when people have business critical software that's no longer supported by the original developer there's no way to fix it if the operating system gutted support for something they depend on.
"Sure we can update from Win32 to $modern. We estimate it to take between thirteen to seventeen man-months. You know the usual rate for a man-month, let us know when you want to start the project."
Re: Calling Windows 10 APIs from a WinForms or WPF application
#25Re: Calling Windows 10 APIs from a WinForms or WPF application
#26As a user i find going the other way more troubling. Say i want to use a UWP file manager on Windows 10. Out of the box the folders i can access are limited, and adding more require that i use the age old Win32 file picker window. Similarly both Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default one. Something that is not alwa…
I find UWP pretty terrible. :( It feels like developing for a weakest link (the traditional cross-platform problem) which is often Windows Phone or something. Which doesn't exist!! Windows Phone doesn't bloody exist! If MS had amazing mobile market penetration UWP would be amazing but what is this?! How is UWP exactly better than WPF for Windows desktop apps? It isn't. But it's where MS now wants you to be, because t…
CoreWindow lets you recolor the window decorations without having to owner-draw the entire thing. But that's all i've got.
Re: Calling Windows 10 APIs from a WinForms or WPF application
#27Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.
Because Microsoft supports critical applications that businesses use for well over ten years in a lot of cases. Zero other operating systems have to provide the platform stability that Microsoft does. So, of course, if they have to focus on supporting only one, archaic platform, they never move forward or create anything new or improved. Which doesn't make sense. So you continue to create newer, better platforms, but…
Re: Calling Windows 10 APIs from a WinForms or WPF application
#28Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.
+ All your apps look the same - Half of your apps are no longer supported I think mostly everyone who uses their computer to make their living (ie the prime audience of MS) does not consider this a good trade-off
Deprecating all but one GUI framework doesn't mean breaking all but one. It just means picking one option and adopting it wholeheartedly. How different would all these Microsoft frameworks have been if they were only finalized after gaining the experience of porting over the entire OS? Microsoft might have ended up with a solution that could unify the landscape on its own merits.
Apple's OS X/macOS has always had an evolving look and feel with notable first-party apps that don't conform, but it's never been half as inconsistent as Windows has gotten.
Re: Calling Windows 10 APIs from a WinForms or WPF application
#29I absolutely love WPF development. I'm all web now, and I love it too, but sometimes I just wish I could go back to the good old WPF days! The extensive tooling involved with frontend web development and the constant religious wars between frameworks can get exhausting.
As a mostly C++/.NET dev since over a decade, I've tried to embrace the "modern web" a bit more, but as soon as I did... Web development in 2016 feels comparatively _insane_ to a dev used to structured .NET full stack development in a big IDE made for the purpose, on a platform with slow incremental improvements over the years with a vision and coherence from a single company. It's like assembling a castle from brick…
The biggest problem isn't just that, it's that those big frameworks change fairly frequently too.
I've witnessed web projects go from backbone to angular to react in the span of a year.
I'm mainly a Qt dev, however I needed to add a Cesium component to the application I'm working on. What a mess. Everything about the javascript ecosystem seems to be in a constant state a flux. I tried to make it better with Typescript, but after trying that for ages I realized I was only complicating things for myself, many of my libraries didn't ship typescript definitions, the main one I was working with needed to be generated based on the documentation and once that was done was severely lacking in much of its functionality.
From crashing editors that wipe your files to dependencies that have breaking updates every few days. And there's a dozen options for everything, at least 5 different module loading systems, of which I had to use several in order to get something compatible with both Cesium and node since both use different module formats and I needed a loader that would support both.
Then there's the packing tools which didn't support what I wanted to do at all without a lot of manual hacks.
Eugh, I don't want to touch it again, the whole thing just made me feel incompetent and thrown around.
But I know I have to, and now I'm sitting here asking myself if React or Backbone would help clean up some messy UI code...
Re: Calling Windows 10 APIs from a WinForms or WPF application
#30Earlier quoted context omitted.
They only have to provide this because they lock down their products. They do it to themselves.
The enterprise market has repeatedly chosen locked-down-and-supported over free-but-you're-on-your-own. This will probably never change.