Earlier quoted context omitted.
.NET versions are not fully backwards compatible. Would you like every Windows install to ship with over ten versions of the .NET runtime?
> Would you like every Windows install to ship with over ten versions of the .NET runtime? A better approach would be to not break backwards compatibility in the first place.
Windows native app development is a mess
371–380 of 481 posts
Re: Windows native app development is a mess
#372Earlier quoted context omitted.
Only a very small minority of users actually care about dark mode. It is not a general expectation for software, as loud as those users may be on forums like this one.
And how do you know this? I decided to check myself, looked for dark mode statistics on android, and: >Dark mode is used by 81.9% of 2,500 Android users on their phones, in apps, and in other situations. 9.9% alternate between the light and dark So it's the other way around. Only a very small minority of users actually care about light mode.
Re: Windows native app development is a mess
#373I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…
Here's the source code for those who are interested: https://github.com/sergeax/stamputty
Re: Windows native app development is a mess
#374Given the size of some Electron software, bundling TCL/Tk with IronTCL and TCLLib+TKLib weights 58MB and you can develop your own software with it, and that with the source of everything included. And if you set a native theme for TTK in your code (literal two lines), your software will stop looking Motif-Industrial, the widgets will have the classic Win32 themes. It will look native from XP and up.
[1] https://en.wikipedia.org/wiki/Tcl_(programming_language)
Re: Windows native app development is a mess
#375I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++. Recently had to add a new feature to and old program that was last updated in the XP era and two things to note: 1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit…
To me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.
Re: Windows native app development is a mess
#376Earlier quoted context omitted.
I still think that WPF was the peak desktop UI framework. Extremely powerful with lots of small composable primitives, can easily do declarative but drop into more traditional event-driven imperative style where it makes sense.
I live in a bizarro universe where I started my career working on an expansive WPF desktop app on .NET Framework 4.0, and am still working on it now on .NET 10. From my perspective it's been WPF the entire time, and it's been pretty okay.
Re: Windows native app development is a mess
#377I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…
Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare. MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell. I think it's fair to say that the entire stor…
When I look at the apps on Windows, all I see are abandoned projects and MVPs with a borderline malware financial structure.
Re: Windows native app development is a mess
#378Earlier quoted context omitted.
Just wanted to add a shoutout to WinJS for posterity, with which I built a Windows 8 app that I had published to the Windows Store for a brief period of time. Then they open-sourced the UI part of WinJS and decided it was just a web framework instead of an officially supported method for building Windows apps iirc, which was the end of my foray into the Windows store. https://github.com/winjs/winjs
If you want JS, isn’t react-native-windows an option?
Re: Windows native app development is a mess
#379It’s been a long time since I had to touch Windows development. If I had to do it over again, I would use React Native for Windows UI where possible and low-level Win32-React Native module bridges for user space code. The last time I had to do Windows development was about 15 years ago. I used a library called WTL (I think a couple comments here mention it). I couldn’t use any of the newer stuff that Windows 8-10 wer…
And if you think using it will let you port your app to other platforms, think again. There's no drop-in compatible equivalent of RNW for Linux, and the version for Mac is even worse than the Windows version.
t. works on a huge app written with React Native Desktop
Re: Windows native app development is a mess
#380I agree with all the comments here saying "stick with Win32" --- this is "a mess" that you can easily avoid. Speaking as a long-time Win32 programmer, the requirements for your app are doable in a few KB (yes, kilobytes --- my vague estimate is less than 8KB) standalone executable. This is how I arrived at that: Enumerating the machine’s displays and their bounds A few API calls. Probably a few hundred bytes. Placing…
Using Win32 to write a UI in Windows is like pulling teeth. There are bindings for Rust but even still it's a nightmare. MacOS is slightly better but Apple's anti-competitive practices targeting developers makes it a tough sell. Linux is better still, technically, but due to the fragmented desktop environment landscape and distribution difficulties, it's also a hard sell. I think it's fair to say that the entire stor…
MacOS is not quite so simple: https://news.ycombinator.com/item?id=40085237