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

321–330 of 481 posts

Re: Windows native app development is a mess

#321

Post by badsectoracula »

magicalhippo wrote: post #286
tsss wrote: post #58

Earlier quoted context omitted.

Honestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.

> Try writing something like Spotify in WinAPI and that's not even a complicated GUI either. Fruityloops, now FL Studio, was written in Delphi and to my knowledge still is[1]. When ot launched there were no options but Win32 for Delphi. That's just one example. Win32 makes it reasonably easy to skin things, and back in the 2000s a lit of programs did. [1]: https://blogs.embarcadero.com/fl-studio-is-a-massively-popul.…

> Win32 makes it reasonably easy to skin things

Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.

Re: Windows native app development is a mess

#322

Post by int_19h »

jerhewet wrote: post #261

Steve Gibson, Gibson Research. https://www.grc.com/freepopular.htm Just scroll down the page and look at the size of the completely self-contained executable programs. THIS is what Win32 is capable of. Something we always had with Win32 that was thrown away with .Net and C#. And _please_ just spare me your opinions of how Steve Gibson "doesn't know anything about security". That's not what's important here. What's im…

.NET runtime has been bundled with Windows since Win2003.

And if you don't have to drag the runtime around, .NET binaries are even smaller than that, since the bytecode is more compact.

Re: Windows native app development is a mess

#323

Post by int_19h »

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.

I'm not sure how you define "native" here. If you mean native widgets then WinForms does what you want, is still fully supported, works on modern .NET versions, and Visual Studio still has all the GUI designers etc. WinForms is very obviously a calque of VCL, as well, so it can do everything Delphi did, but better.

If you mean native code then VB6 doesn't belong in this category (even if you compiled it to a standalone .exe it was still effectively bytecode).

Re: Windows native app development is a mess

#324

Post by int_19h »

domenicd wrote: post #53
whobre wrote: post #32

Interestingly, no mention of WTL

Ahah, I knew I missed one! I originally had ATL in there, but my proofreading squad (Claude and ChatGPT) told me that ATL was a more niche thing for COM, and looking at the Wikipedia article I was convinced they were right. But WTL was what I was thinking of---the step between the MFC and .NET that I forgot.

WTL was never a "step between the MFC and .NET" in any meaningful sense. It was more like a very lightweight subset of MFC+ATL, never officially supported or recommended, just something that Microsoft used internally that it decided to publish and then community picked up.

Re: Windows native app development is a mess

#325

Post by kulahan »

joe_mamba wrote: post #262
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…

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.

Software seems to have quality and capability as diametrically opposed attributes.

Re: Windows native app development is a mess

#326

Post by [deleted] »

userbinator wrote: post #279
feznyng wrote: post #235

Earlier quoted context omitted.

How do you make your win32 app look good to the average person?

Depends what you mean by "look good". The main function of the app being discussed here is to draw solid black rectangles on the screen. Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows le…

[deleted]

Re: Windows native app development is a mess

#327

Post by lelandfe »

userbinator wrote: post #279
feznyng wrote: post #235

Earlier quoted context omitted.

How do you make your win32 app look good to the average person?

Depends what you mean by "look good". The main function of the app being discussed here is to draw solid black rectangles on the screen. Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows le…

There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-fi...

Would that UI be hard to accomplish?

Re: Windows native app development is a mess

#328

Post by bloomca »

lelandfe wrote: post #327
userbinator wrote: post #279

Earlier quoted context omitted.

Depends what you mean by "look good". The main function of the app being discussed here is to draw solid black rectangles on the screen. Don't forget the "average person", I'm assuming someone relying on software as a tool, doesn't care about the stuff "designers" seem to obsess over, and will actively hate if you break their workflow by doing things like adding useless padding that makes them scroll more or shows le…

There's a pretty simple settings window: https://github.com/domenic/display-blackout?tab=readme-ov-fi... Would that UI be hard to accomplish?

You mean conceptually or to match it? Native components are pretty much impossible to match without actually using the native framework which provides them, so you need WinUI/WPF.

Win32 provides its own components which are basically Win95 style apps, and you can draw the components using some graphics APIs by yourself.

The whole native development area is a mess exactly because making your own (decent) renderer is a huge undertaking.

Re: Windows native app development is a mess

#329

Post by badsectoracula »

Rohansi wrote: post #190
NetMageSCW wrote: post #188

Earlier quoted context omitted.

No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.

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

Re: Windows native app development is a mess

#330

Post by perching_aix »

feznyng wrote: post #235
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…

How do you make your win32 app look good to the average person?

They really don't. Though if Microsoft wanted to, they could solve that too. For example, the OS control panel used to be extendable. Technically still is, just not the new one (and of course both remain). Then you could have this UI or something very similar to it right in there.

Several integration points like this have been removed, supposedly because third party software was just too bad in how they used them, causing issues. Or at least so goes Microsoft's perspective. Personally, I find that very believable! If by integration points the only thing one can imagine is calling into random third party code on the regular that the user has installed, bang spank in the middle of critical user flows, on the same thread and in the same process as itself, that's exactly the kind of grief I'd expect to occur...

If only there was a way to provide a way to craft e.g. custom flyout menus for the taskbar or custom pages in the Settings app, without invoking arbitrary third party code and possibly causing crashes and hangs in system apps and menus... or just not letting crashes and hangs affect the application (e.g. Windows Explorer) calling them in the first place.

Post reply on HN