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

441–450 of 481 posts

Re: Windows native app development is a mess

#441

Post by Kwpolska »

piskov wrote: post #315
Kwpolska wrote: post #157

> However, for no reason I can understand, Microsoft has decided that even the latest versions of Windows 11 only get .NET 4.8.1 preinstalled. .NET has new releases every year, supported for 2 or 3 years. That’s not really compatible with Windows release cycles. Also, if Windows 11 25H2 shipped .NET 8, and now Windows 11 26H2 would ship .NET 10, apps which depend on version 8 might break. Easier to just think of .NET…

Last time I heard WPF was basically abandoned (open-sourced) and handed over to die to some Indian folks. Something akin to WCF

At least WPF is seeing some development, and it is officially and fully supported in the modern .NET. WCF is a wasteland.

Re: Windows native app development is a mess

#442

Post by leptons »

philistine wrote: post #427
leptons wrote: post #391

Earlier quoted context omitted.

"Developers, Developers, Developers!" - Steve Balmer Microsoft has always had vastly more developers and development of software for Windows. Apple still after all these years has a tiny market share of overall platforms, software, all of it really. Not sure how you can suggest Apple is somehow the bastion of software development. If you write mac software, you'll be targeting a platform with 15-20% market share at b…

Isn't software development about making money? On phones, if you want to make money you have to target iOS, since this is where you have the people with money to spend on software. Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?

>On phones, if you want to make money you have to target iOS

It's funny that you think Android users are broke-ass nobodies. That's some reality-distortion-field fanboi nonsense. And it's also hilarious that you think phone apps are useful software that costs lots of money.

Most people in tech with high-paying jobs that I know are using Android, because it's actually pretty awesome compared to the locked-down walled-garden that is Apple. More than half my friends use Android or Windows. They use Android because it isn't as locked-down as iPhone. They use Windows because it runs all the software they want it to run. We also really don't care about Apple's blue bubbles.

No, Apple users are not the only ones with jobs. Plenty of Android users have plenty of disposable income. It's a ridiculous argument to make that Apple users have more money to spend.

>Do you believe that the vastly larger installed base of Windows guarantees more money for everyone?

I don't have to believe it, the market believes it. People vote with their dollars, and they aren't voting for Apple all that often worldwide. Plenty of wealthy people use Android and Windows. I'd wager that most big companies are still run on Windows - and I know this experientially, from back in the day setting up computers for major corps, it was 85% Windows, 15% Apple. Always was, always will be.

Re: Windows native app development is a mess

#443

Post by hbn »

ojeda wrote: post #280
userbinator wrote: post #227

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

Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations. > Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input. Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are st…

I was gonna say he addressed Microsoft's rust library, but apparently that was something different?

https://github.com/microsoft/windows-app-rs#this-repository-...

I'd say it's confusing but I wouldn't expect any different from Microsoft.

Re: Windows native app development is a mess

#444

Post by hbn »

asveikau wrote: post #366
joe_mamba wrote: post #262

Earlier quoted context omitted.

IDK man, I wonder how TF did the creators of Winamp do it? Were they so much smarter than the programers of today? And Winamp 2.95 still works on WIndows 11 today. IIRC Borland Delphi was the most popular tool back then for making Win32 apps since it was so easy to use.

> Were they so much smarter than the programers of today? Unironically the answer is yes. I've been watching this for at least 15 years. I think one inflection point is when everybody who was coming up became accustomed to GC languages. Within a decade of that trend starting, nobody could reason about memory anymore. With the AI boom we're going through another inflection point. When coding is synonymous with using a…

Also a lot of people got into the industry because they saw the salaries of programmers, but have no real passion for computers or software. They did the studying enough to pass the tests and write an algorithm to pass the interview and land a job. But they don't have the drive to make things better, think outside the box, or write something they can be proud of.

AI has accelerated this because it's becoming harder to detect the frauds.

Re: Windows native app development is a mess

#445

Post by ack_complete »

ptx wrote: post #229
ack_complete wrote: post #220

Earlier quoted context omitted.

Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not. Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in…

But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.

Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.

Re: Windows native app development is a mess

#446

Post by Klonoar »

smileybarry wrote: post #378
Klonoar wrote: post #167

Earlier quoted context omitted.

If you want JS, isn’t react-native-windows an option?

WinJS was a bit different, where your app was genuinely just a bundle of JavaScript and a UWP host process dealt with the rendering. (No Electron-esque to deliver with your app) Made for some tiny, succinct apps.

I am once again stating react-native-windows, the key part being native. It doesn't have anything to do with Electron.

Re: Windows native app development is a mess

#447

Post by sys_64738 »

gzread wrote: post #355
sys_64738 wrote: post #122

Earlier quoted context omitted.

I've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.

They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window. WinMain should create an instance of the app class and call Run. "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 wh…

> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair

I get that if I post more than six replies in an hour.

Re: Windows native app development is a mess

#448

Post by gzread »

sys_64738 wrote: post #447
gzread wrote: post #355

Earlier quoted context omitted.

They don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window. WinMain should create an instance of the app class and call Run. "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 wh…

> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 which feels pretty unfair I get that if I post more than six replies in an hour.

I've always been able to post several replies in an hour before.

Re: Windows native app development is a mess

#450

Post by jasomill »

int_19h wrote: post #316
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…

For what you describe, .NET + WinForms or WPF will work just fine. These days it can built self-contained executables, although they won't be small (but then again, when many websites have multiple megabytes of JS...). Or you can target .NET 4.8 - for something this simple I doubt there'd be much difference but then you can ship an .exe that measures in kilobytes, and the runtime is included with every version of Win…

You can build single-file executables for .NET 4, and I do, but there's no static linking, so you need to restrict yourself to assemblies that ship with the framework and whatever other prerequisites you're willing to install or assume will be installed.

Two notable caveats:

1. Certain newer C# language features require runtime support that doesn't ship with older versions of .NET, which can include quite a few DLLs.

2. In-process COM components can only be instantiated in .NET runtimes runtimes with the same processor architecture, even if the .NET program itself is processor-independent (which by default will use the runtime matching the native architecture), so you may need to ship multiple executables to match multiple COM dependency versions even if your program is otherwise processor-independent or you only intend to ship it for a single processor architecture.

For example, if you build a processor-independent program that relies on the Microsoft Access DAO library, it will by default work correctly on 32-bit Windows if 32-bit Access is installed, and on 64-bit Windows if 64-bit Access is installed, but there's no way to get it to work on 64-bit Windows with 32-bit Access without shipping a second executable (that can be identical with the exception of the 32BITREQUIRED flag in the CLR header[1] that can be set as part of the build process or with the .NET SDK corflags utility).

Rather than ship separate "32-bit (or 64-bit with 32-bit " and "64-bit" versions of a program that interops with some in-proc COM component , I prefer to build a single executable .exe, then create a copy 32.exe with the flag set as part of the build process, and ship both to be installed side-by-side.

Then, since the native COM DLL isn't loaded until you actually create an interop object referencing it, you can just try to create an Interop.. object at program start, catch ComException with HResult == REGDB_E_CLASSNOTREG, then in the exception handler, run 32.exe as a subprocess with identical command-line arguments and exit with 32's exit code, unless you're already running in a 32-bit CLR, in which case you just fail normally.

[1] https://ecma-international.org/wp-content/uploads/ECMA-335_5...

Post reply on HN