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

101–110 of 481 posts

Re: Windows native app development is a mess

#101

Post by rwmj »

raw_anon_1111 wrote: post #73
Dwedit wrote: post #70

Earlier quoted context omitted.

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 poin…

That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs

Ah yes, these 68000 pointers have a spare 8 bits for me to use! Because nothing will ever need more than 16 MB of memory. Sigh.

Re: Windows native app development is a mess

#102

Post by moomin »

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’s two versions of .NET. One is “legacy”, which is stable as anything and bundled with the OS. The other is “Core”, that only has support for three years and isn’t 100% compatible. The reason the latest .NET runtime isn’t bundled is the above: the stable version is bundled.

Re: Windows native app development is a mess

#103

Post by moomin »

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…

But that’s the point the article’s making. At the C level you’ve got a fully functional system. Above that level (even at the C++ level), feature support is a mess.

Re: Windows native app development is a mess

#104

Post by Atotalnoob »

moomin wrote: post #102
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’s two versions of .NET. One is “legacy”, which is stable as anything and bundled with the OS. The other is “Core”, that only has support for three years and isn’t 100% compatible. The reason the latest .NET runtime isn’t bundled is the above: the stable version is bundled.

Core is compatible with non deprecated apis.

That’s why they had .NET 5im stead of .net core 5

Re: Windows native app development is a mess

#105

Post by dcrazy »

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 patently false. To add a button to your UI, you open your window’s nib file Xcode/Interface Builder, click the plus button on the toolbar, and add a button. Then you control-drag from the button to File’s Owner and choose the method that you want to invoke when the button is clicked. Done.

Re: Windows native app development is a mess

#106

Post by rcleveng »

dardeaup wrote: post #94
GeoAtreides wrote: post #76

come back home Delphi 7, all is forgiven

It seems that peak native Windows dev tools were Delphi 7 and VB6. It's a tragedy that something at least as good as VB6 is not still developed and supported by Microsoft.

There's nothing as good as VB6 that's developed and supported by *anyone*. It's not a Microsoft only phenomena.

I think programmers started wanting "real" languages (notice the quotes), and henceforth got more complexity and things take longer, although with GenAI, we may be back to the "draw as screen and do this" that we were with VB6. Just now the source generated should be considered the object code, and the prompt is the new source (at least for those types of apps)

Re: Windows native app development is a mess

#107

Post by Atotalnoob »

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…

.net will work. Use a weaver (fody) or the modern features to roll everything into 1 .exe.

Use self-contained to have everything together.

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

Re: Windows native app development is a mess

#108

Post by finghin »

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…

‘Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule’ —F. Nietzsche

(tongue in cheek)

Re: Windows native app development is a mess

#109

Post by jasonjei »

It’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 were pushing because it needed backward compatibility. It seemed way less bloated than MFC, but not as annoying to use as ATL or rawdogging Win32 APIs.

Ironically, I was developing a Win32 app to build a cloud bridge to a Rails app (talking to Quickbooks COM API which was hell on Earth, with XML and XML definitions) on Mac, using VMware on Mac to talk to Quickbooks Windows. I was so annoyed with Win32 development I used the Chrome Embedded Framework library to build the UI for the Win32 app so I wouldn’t have to wrestle WTL for UI and just have browser-based views to drive UI.

I think it was very tempting to drop C/C++ development for .NET code, but I didn’t want to drop off user adoption by requesting users to download a huge .NET runtime if their computer didn’t already have it.

This was when I was building Levion, a Quickbooks Windows to Cloud Rails app…

Re: Windows native app development is a mess

#110

Post by sethhochberg »

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.

I think its at least as much of a working environment preference.

Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration.

I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well.

Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).

Post reply on HN