Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows native app development is a mess

domenic.me

Post reply on HN
Print view View original

61–70 of 481 posts

Re: Windows native app development is a mess

#61

Post by c-linkage »

sylens wrote: post #37

Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment? It's another example of how they have completely abandoned any attempt at providing a good user experience across their products

There are a few reasons that I can see why they don't integrate the latest .net.

First is that the security model changed with .net 5. Next is that they subsume Mono/.net core into the foundation of the language and this cost them them the ability to support Windows native development, specifically anything to do with Win32 API.

If you look at .net 10 and compare that to .net 5 you can see that they are trying to reintegrate the Win32 API but now it is in the all new Microsoft namespace.

The amount of change is too significant to act as a drop in replacement for the original .net framework. Maybe they could have gone a side-by-side installation, but the rapid development of The NET Framework I think made it too hard to tie to an operating system update. They wanted to free it from that update cycle of once a year or every two years and allow the development to progress rapidly at the cost of having to download it and install it each time.

Re: Windows native app development is a mess

#62

Post by kwanbix »

rwmj wrote: post #59

This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit. My first thought was MFC. Basic, fast, well understood. But then maybe WxWindows so we can…

Delphi or Lazarus (https://www.lazarus-ide.org) should solve it.

Re: Windows native app development is a mess

#63

Post by rwmj »

kwanbix wrote: post #62
rwmj wrote: post #59

This is quite timely as we need to write a simple UI for Windows (a few buttons, status, maybe a file menu). The main constraint is it must compile to a single binary (.exe) with no dependencies such as runtimes, DLLs, languages etc. It also needs to run on some older unsupported Windows systems, probably Windows >= 7, 32 bit. My first thought was MFC. Basic, fast, well understood. But then maybe WxWindows so we can…

Delphi or Lazarus ( https://www.lazarus-ide.org ) should solve it.

Nice, I didn't know there was a free software version of Delphi nowadays.

Re: Windows native app development is a mess

#64

Post by flohofwoe »

fsloth wrote: post #29
bentt wrote: post #12

I wonder if Unity (the game engine) actually has a sneaky potential here. It’s cross platform, fast, and maybe just maybe less bloated than carrying around an entire browser like Electron?

Sure but different target market. CRUD apps are non-trivial. If Unity were to ship platform native replacement for WPF equivalent (hell or even winforms) it would become a really enticing app development platform.

> CRUD apps are non-trivial.

Aren't these pretty much the most trivial UI apps possible? E.g. compared to other native apps like Photoshop, Blender, Visual Studio or Office, CRUD is mostly just about banging together custom UI frontend for a database.

Unity's editor is implemented in its own (old) UI system, same with Godot, so in both engines it's possible to create 'traditional' non-game UI applications.

Re: Windows native app development is a mess

#65

Post by 762236 »

user____name wrote: post #45
cv5005 wrote: post #11

I'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…

I feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they c…

This is such a wonderfully beneficial comment to the HN community. It should get an award.

Re: Windows native app development is a mess

#66

Post by mcswell »

samiv wrote: post #42
cv5005 wrote: post #11

I'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.

Repeat after me: New! Fresh! Clean!

Re: Windows native app development is a mess

#67

Post by domenicd »

c-linkage wrote: post #61
sylens wrote: post #37

Author raises several good points. Why isn't the latest .NET runtime pulled down into Windows 11 devices via Windows Update? Why isn't there a better path forward for deployment? It's another example of how they have completely abandoned any attempt at providing a good user experience across their products

There are a few reasons that I can see why they don't integrate the latest .net. First is that the security model changed with .net 5. Next is that they subsume Mono/.net core into the foundation of the language and this cost them them the ability to support Windows native development, specifically anything to do with Win32 API. If you look at .net 10 and compare that to .net 5 you can see that they are trying to rei…

Side by side is what I'm asking for. Just like there's WebView (IE-based) and WebView2 (Chromium-based, evergreen, updated every 4 weeks).

I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.

Re: Windows native app development is a mess

#69

Post by rwmj »

samiv wrote: post #38

Seems to me that really the simplest solution to authors problem is to write C++ safely. I mean...this is a trivial utility app. If you can't get that right in modern C++ you should probably just not even pretend to be a C++ programmer.

Just write C++ safely! Why didn't we think of that?

Re: Windows native app development is a mess

#70

Post by Dwedit »

jordand wrote: post #17
cv5005 wrote: post #11

I'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…

The one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.

In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.

But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.

Post reply on HN