Ask HN: Why is building Windows apps so complicated? | Hacker News Reader

Ask HN: Why is building Windows apps so complicated?

382 pointsvixalien489 comments

So I decide to build a windows 11 app. I already know some .NET and C/family from school and look through the source of C# and it doesn't seem too complicated.

However, building Windows apps is very complicated even when you know C++ or C#.

1. I wanted to build Windows 11 apps and I had to choose between Windows Forms, WinUI3, Win32 and WPF I think. I don't really know the difference between the 3 and no one really explains that (unless Win32 which is obvious).

2. Apparently, WUP is no longer recommended. A few years they were pushing it to the max. Bummer.

3. I installed Visual Studio overnight (it comes with all the tools that building apps need). It downloaded 6GB of data and used 20GB of storage. All i want to build is a hello world app.

4. I create a project following a guide from Microsoft.

5. The app is extremely resource heavy and way too over-featured. I build the boilerplate app and Run it and it takes minutes to build (most of the time is downloading dependencies so not such a big deal).

6. I open the newly created app in Sublime Text (my editor) and I can't find a way to build the app anymore.

7. Because Visual Studio is so bloated, I download Visual Studio Code, which is far more simple but I can still not figure out how to build my app even with the various extensions VS code boasts.

8. After hours of googling, I formulate a script that can build the app from the command-line.

9. But I stil don't know how to build the app as the .exe file created does not execute.

10. I'm very disappointed.

The worst of all is that there is not even one good guide on the whole clearnet on how to do develop a Hello World windows app from scratch.

View on HN

1. Install the .NET 6 SDK: https://dotnet.microsoft.com/en-us/download/dotnet/6.0

2. Terminal ,pick a folder, `dotnet new wpf`

3. `dotnet run` and you have an (admittedly empty) hello world app

It's telling me it took 1.5s to build the app.

Want to publish the app?

`dotnet publish -o ./publish -r win-x64` which takes a bit longer as it has to download some runtimes (60 seconds max, then cached). Zip up the resulting folder and ta-da you have an application. Just unzip and run the .exe.

If you want a single-file exe (as in completely statically compiled without self-extraction) that's a bit more advanced and requires a few properties in the csproj to configure how to handle native assemblies that expect to exist on disk. If you want it to have no runtime dependencies, add `--self-contained`

dotnet does not work with winui3 apps. I can't link the relevant stackoverflow answer from a microsoft dev. You can only use msbuild.

That's pants on head stupid.

How so exactly?

The fact that 2 major Microsoft products don't integrate fully.

They're two almost-identical pieces of software that parse almost-identical file formats. They may or may not share a codebase (five minutes on github hasn't clarified this), and in most cases you can substitute one for the other. Except this one. And the developers (of whom there are not many for WinUI!) forgot this use case because they're focused on building inside VS.

>has to download some runtimes

As someone who had to develop software in an airgapped enviroment, I'm sending a special "fuck you" to whoever thought this is a good idea. God forbid you have the AUDACITY to not be connected to the internet at all times for any reason whatsoever.

Yes, I hate it when software that I thought was fully installed unexpectedly starts downloading more stuff when I run it.

What if I installed the software with the intention to run it without internet, or 5, 10 or 100 years in the future?

the default is online now for development, so nowadays by default if you need offline you need to test it :/

Who gets to decide what is the default?

On this case, Microsoft. It's their private garden, you are invited by their rules.

And yes, this sucks. But if you want freedom, there are other OSes (or even other dev tools) where you can have it.

Apparently in those 20GB there was no place for the runtime?

The installer for the sdk is 200MB

I think it started with Android.

You can download all versions of Android if you want, but i doubt that you would want that.

I think the first time I encountered it was in some makefile of Chrome or perhaps V8 that automagically downloaded dependencies. It sounds nice in theory, but then I expected the tarball to contain the entire thing which caused trouble and confusion down the line.

Well, it caches the packages... So only your CI system needs internet, or your PC the first time you ever publish.

And you can likely mention it as an explicit dependency in your csproj so that you can download it on first restore.

I feel like you are misunderstanding the rules associated with an air-gapped system.

Presumably all development frameworks require you to explicitly list your dependencies, download/restore them with internet, then snapshot and copy that to your air-gapped environment?

That's exactly what you have to do here.

Is there a rule regarding developing for a .NET framework from within such an environment?

I understand OC issues with the difficulties associated with using M$ tools with limited internet but wonder if the "Air Gapped" example may be a bit extreme.

Being required to work from home while still meeting an employers' secure network policies might be more common.

I developed with dotnet in an airgapped environment. Due to restrictions, you cannot use dozens of nuget packages. So, you create a nuget package repository in your airgapped environment. That's all it is. If you want something else, you use whatever the policy is to get a file from internet to airgapped side. When I wanted a newer version of a Nuget package, it took me 3-4 hours to get it on my workstation. But that's all.

Also, when you write something on those environments, you know users cannot install a runtime. So you get in touch with IT teams to ensure which version of runtime they are deploying. If and only if you have to update it for proper reasons, then they can deploy newer versions to the clients. For all or for a specific user base. This is how it works.

Without an actual business case or a security concern, you don't just go from a runtime to another, let's say 4.8 to 6.0. So yes, development in airgapped environments is PITA. But it's the same with Java, Python, Perl, etc. That's not the fault of the runtime but the development environment itself.

It's really not that big of a deal. You set up a package proxy that is itself behind the airgap, and you're good. Yes, you have to put some extra effort into moving packages across that airgap when you need to add or upgrade one, but then, isn't having to do things like that kind of the whole point of an airgap?

I certainly wouldn't want to ask that the other 99% of the world's developers avoid a feature that's useful to them just to assuage my feelings of envy about the convenience they enjoy.

> isn't having to do things like that kind of the whole point of an airgap?

Nope. The exe files are supposed to do it's thing without internet and no extra effort like it was for a long time.

Even in the past files wouldn't magically materialize on your harddrive.

In the mini-guide above they already moved the SDK ("Software Development Kit") across the air-gap, yet creating a hello world still requires downloading even more stuff, because the .NET SDK does not actually contain enough stuff to create hello worlds, apparently?

Contrast this with e.g. Zig for Windows is a ~60 MB zip file which contains the entire Zig/C/C++ compiler with cross-compilation support for basically everything, and also has complete Win32 headers + libraries in it. There's even DDK headers in there, though I'd expect to do some legwork to build drivers for NT with Zig.

Does that 60 MB include something like Qt, comparable to WPF? I'm not sure that comparison is fair.

If you're happy to sacrifice the benefits of .net and spend time writing basic Win32 apps, that's totally a choice you can make. Or even just use .net framework 4.6 and not add any extra dependencies.

I'm not really sure what you're complaining about here. .net core is split into tiny packages - if that is hard to handle in your very special environment, you get to use special solutions to make it work.

That's besides the point I was making, which is that there's runtimes/languages which lean towards "internet required for development" or even "internet required for building" while there are also languages/runtimes which are self-contained and independent.

That being said, WinForms is also "just" a Win32 wrapper, I don't see a compelling reason why a similar wrapper wouldn't be possible in pretty much any language. .NET 4.6 is a fine choice too, especially because you're not forced to ship runtime and standard library, as Windows already has both.

I believe that's very much related. The more of the nice wrappers you provide, the more you have to decide if someone needs them all or are you providing them on demand. With .net core doing more splitting than framework and with Java going through a decade of jigsaw, I think we collectively decided we don't want to include everything upfront.

We don't even require the internet for building/development. In .net land you require internet to get the dependency you're using the first time. If you want to get them all and distribute/install before you start development, you can totally do that. It's just not the default behaviour.

Files used to materialize without internet since beginning, it's not magical. We just needed the software installer file copied to hard drive.

It's gonna blow your mind when you realize that `dotnet publish` produces an artifact that IS machine-independent, and that you would just distribute that. Or if it somehow really bothers you, put it in a self-extracting ZIP or MSI, wow, so much better. And I don't know what golden age of the Internet you grew up on, but there's always been "apps" distributed as zips, or as more than just a single binary.

I get that you have opinions, but you seem to have entirely missed that the runtime is downloaded at build time and included in the bundle. And god forbid if you like doing everything by hand, you don't have to use Nuget and you can manage every last dep by hand, however you like (and you'll likely end up hacking something that is less usable than just setting up a private nuget server, but "opinions").

I'd call it a "yup," if we're talking about the point of an airgap. If I don't want executables contacting the outside world without my knowledge, and one is, then the airgap (or, more likely, firewall or suchlike) preventing that exe from being able to do so is a feature.

This does mean that certain programs just won't work, or won't work without some finagling. That's also a feature. The price of control is having to control things.

Granted, most people don't want to pay that price, and prefer convenience. That's admittedly not to my own taste - c.f.) log4j for a good example of why - but I think I'm maybe a little weird there. I certainly don't think there's anything audacious about catering to majority tastes. Maybe just vaguely disappointing.

Computers were able to work without internet since i was a kid. That's how me and my friends used them without any problem. Using the airgap word you are making it a new special setup that needs some special steps, some programs will not work etc. It's not a feature.

Saying people prefer one to another hides the fact that they were not given any other option. People will choose whatever default is given and then we may say they everyone prefers that. Or just make the other option (which was normal before) complicated so that nobody wants that now.

>It's really not that big of a deal. You set up a package proxy that is itself behind the airgap, and you're good.

Yes, technically easy but if their work environment is strict enough to enforce air gapped development, I imagine the bureaucratic process to accomplish such a thing to be a bit less than easy.

> set up a packaging proxy to [connect with a system outside the airgapped computer]

Do you even know what an airgapped computer is?

It’s not that kind of proxy.

This is a bit dramatic. You're a software developer, building an app which has dependencies, so of course you have to download those dependencies to build. Where else would they come from? Literally every language with a package manager does the same thing.

Being able to make a portable build of the software you are creating is such a basic feature it's baffling you have to fetch extra data to do that. Also nowhere in "dotnet publish -o ./publish -r win-x64" I said "Connect to the internet and fetch megabytes of binaries"

What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.

`dotnet publish` performs an implicit `dotnet restore`. So, yes, you did.

If you don't want it to download anything then you use the `dotnet publish --no-restore` flag, which is used a lot in CI/CD pipelines. If you don't have the package dependencies cached it will then simply fail.

The opposite side of that coin is a required up-front install of every package that might ever be needed for every possible scenario... in which case people would complain (even more) about massive installs.

The internet exists, the industry has evolved, software has dependencies, and yes you have to download them (just like you had to download the SDK ISOs back in the day). But it's just one command, run it and get it over with, and after that up-front one-time pain you'll have a nice offline workflow.

You are welcome to the philosophy that says, “the internet exists. Adapt or perish.” It may serve you well.

For many, it is not so black and white. Internet connections are spotty, slow, or expensive. In GP’s case, there is no internet.

Like I said, you are welcome to ignore those users. But your ignorance (I don’t mean that in a derogatory way) doesn’t change their situation.

I'm not OP, so interpreting: I don't think OP is asking for an up-front install of every package under the sun that might ever be needed for any kind of development. He's just asking that, out of the box, the build tools can build software with no dependencies into an executable without having to hit the Internet. And, if he has particular dependencies he needs, allow him to download them (ONCE) onto that machine, and again, he can build software into an executable without having to hit the Internet again. This doesn't seem that unreasonable a request. Every other compiler I've ever used has had this feature. It wasn't even a feature. It's just the way software has always worked.

I should be able to take my computer to a remote cabin with no Internet, and use all the software on it. The only software I'd expect to not work is software whose purpose is to access data stored on the Internet, like web browsers. I don't think this is such a crazy user expectation.

> make a portable build of the software you are creating is such a basic feature

That is easily doable. However users often don't want a copy of a large runtime for each and every program they use, so it often makes sense to move common things (like DLLs, runtimes, your OS) to libraries that can be shared.

You can easily make dotnet apps in either flavor to your liking. And not every developer is going to make their apps to appeal the your needs.

There was a time when MS didn't understand the internet and none of their build tools depended on it.

We seem to have normalised the current situation as an industry, but that doesn't mean the situation is good.

In days gone by we used to have truly standard libraries and runtimes, in the sense that they came with your build tools out of the box and so were available everywhere. Host platforms similarly provided basic services universally. Documentation was often excellent and also available out of the box.

In that environment, writing "Hello, world!" meant writing one line that said do that, maybe with a little boilerplate around it depending on your language. Running a single simple command from a shell then either interpreted your program immediately or compiled it to a single self-contained executable file that you could run immediately. Introducing external dependencies was something you did carefully and rarely (by today's standards) when you had a specific need and the external resource was the best way to meet that need.

Some things about software development were better in those days. Having limited functionality in standard libraries and then relying on package managers and build tools where the norm is transitively installing numerous dependencies just to implement basic and widely useful functionality is not an improvement. The need for frameworks and scaffolding tools because otherwise you can spend several hours just writing the boilerplate and setting up your infrastructure is not an improvement.

Things were far more annoying in the past, in Win98 connecting a printer, or any other hardware required inserting the installation CD or having a folder containing the all the cab files on your system and drive space was far less abundant.

I don't know if it's the case anymore, but that's been the state of windows installers for a long time. Usually the easy-to-download one was tiny and just phoned home for the real bits. And that wasn't just Microsoft's own stuff, but even things like Java and whatever.

Usually you had to dig a bit and could find an "offline installer". Sometimes an "alternate downloads" link is on the initial download page, sometimes you have to good to find a deeper link on the vendor's site.

I always did that just to keep from needlessly reaching out to the internet X times when updating X machines.

And of course, make sure you're getting it from the vendor and not some sketchy download site.

The worst example I know of is Microsoft Office. When I run their installer/downloader, it installs the 32-bit version on my 64-bit machine—it doesn’t let you choose and by the time you realize, you’ve already wasted all that time and bandwith. I had to go to some janky website that hosts the links to the official ISOs and download that instead.

You can bundle the .NET runtime with your app. So the user doesn't need to download a runtime.

Indeed, that's why it's called a redistributable.

Yes, however, it will expand the runtime into C:\temp (or similar). What could go wrong? And then you find yourself in a MS induced yack shave because you want to run two different executables. Microsoft is a never ending source of accidental complexity.

In this particular scenario, my first thought was "shoulda used golang".

I hear tell that since then (1+ yrs ago) matters have improved in the realm of MS standalone apps (well, maybe just cmd line apps).

oh, and the exe is round about 65mb compared to a golang ~5 or 6mb

same with CI/CD pipeline. Most developers just choose to download the same runtime each time there is a build, which is not just very inefficient but not at all guaranteed to work for the next 10 years.

This is the reason I wrote "bash-drop-network-access" [0]. I use it as part of my package building system so that downloads are only done in the "download" phase of building where I validate and cache all objects. This means I can fully verify that I can build the whole thing air-gapped and far into the future with the set of files identified by the SHA256 in each package's buildinfo.

This is important because I support each release of the distribution for up to 10 years, and have some customers who may need to build it in an air-gapped environment.

[0] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...

Safari is reporting your TLS certificate has expired

Very interesting. First time I heard about loading bash "builtins" from a shared library. How does this compare to LD_PRELOAD?

Personally, I just run things in network namespaces with "ip netns exec offline|wireguard $COMMAND" to restrict net access.

Using LD_PRELOAD you only affect dynamically linked executables, where using kernel enforcement using syscall filtering, every process is affected. Also, things are allowed to unset LD_PRELOAD, but not remove filtering.

I thought about using a network namespace, but that would make things more complicated since I would need to re-call my shell script to pick-up where I left off (because it requires creating a new process). I initially tried to implement this using network namespaces, but you cannot "unshare" the current process, you must spawn a new process.

With dropnet I can do

      download()
      enable -f ./dropnet.so dropnet
      configure()
      build()
      install()

With "unshare" I would need to do more work to get to "configure()" in a new process.

Pytorch occasionally does this as well w/ model weights and it's a royal PITA

Off topic, but this really struck a chord. I arrive at the trailhead for an afternoon of mountain biking in the mountains. I can't record the ride route because my mountain bike specific trail/ride logging app can't get an internet connection to log me in. I don't want to be logged in. I just want to record GPS over time. No maps needed. No server access needed. I guess they never thought someone might want to mountain bike in the mountains! Sorry, but that is an idiotic design decision. Unfortunately, this approach to "personal" computing has become the norm rather than an exception. People are not allowed to exist on their own.

Did this happen with Strava? My usual morning MTB lap has no cell service at the trailhead and it’s never been an issue. But I’ve also never found myself logged out before.

The massive 5G infrastructure push should help deal with some of you “occasionally offline” dissidents

How so? I thought 5G is mostly coming to densely populated areas, that is, areas that already have decent connectivity. Also, at least currently, I thought 5G is a developed country thing. Lots of folks are still running off 3G.

Huh, almost seems like 5G is marketing bullshit? The primary goal of 5G being to goad and shame consumers into upgrading a perfectly capable older phone to a new phone that is “5G ready”

I'm very excited to have gigabit download speeds so I can hit my hidden "unlimited" undescribed quota within a minute while also permanently having hotspot throttled to 128kbps.

There still likely won't be towers in the mountains or backcountry.

I'm very excited to heqr the plan for locating 5G towers in the ocean, in remote wilderness sites, in underground facilities, the Antarctic, etc. People visit these sites and expect their tech to work fine as long as it doesnt obviously require a network connection. Of course I can't browse HN from those places, but my otherwise self contained apps should continue to run predictably.

The higher frequencies of 5G are even more easily blocked by outdoorsy things like trees and rain.

No, if anything it will be harder to connect rural areas with 5G. 4G’s coverage is measured in miles. 5G’s coverage is measured in feet.

https://www.verizon.com/about/news/how-far-does-5g-reach

> 5G Ultra Wideband network’s signal can reach up to 1,500 feet without obstructions

You're quoting something about “5G Ultra Wideband”, which seems to be a brand name for mmWave. Yes, mmWave has very short range. But 5G isn't just mmWave. It's in many ways an evolution of LTE/4G, supporting the same frequencies and offering the same range, i.e. multiple km/miles. But it's up to carriers how they allocate their frequencies. To quote Wikipedia:

> 5G can be implemented in low-band, mid-band or high-band millimeter-wave 24 GHz up to 54 GHz. Low-band 5G uses a similar frequency range to 4G cellphones, 600–900 MHz, giving download speeds a little higher than 4G: 30–250 megabits per second (Mbit/s). Low-band cell towers have a range and coverage area similar to 4G towers.

— https://en.wikipedia.org/wiki/5G#Overview

5G is _perfect_ for providing coverage in rural areas, except for the problem that 4G devices are incompatible with 5G networks. Starting 5G rollout in urban areas makes more sense because (a) 5G provides most benefit when clients are close together, and (b) because denser cells make it reasonably economical to maintain 4G coverage in parallel to 5G coverage.

That's a fair point -- that the tech is capable of supporting it. I could be wrong, but in the near term I don't recall any US carriers proposing to allocate any low-band spectrum that way.

Either way, if we're talking about "coverage" for low-bandwidth stuff like fitness trackers, it's the spectrum that matters more than anything. We can communicate thousands of miles on 1 or 2 watts of LF spectrum using technology that is nearly a century old. Don't need 5G for that, just need to use the right spectrum.

...then use a different app. There are myriad ways to record rides with no data service; I do it all the time. Most commonly I use Strava or a dedicated Garmin bike computer.

Syncing / uploading then happens once they have signal again. Or in the case of the Garmin I copy the FIT file off by hand when plugging it into my computer.

I think that by the time you're at the top of a mountain without cell service, you're already locked in to an app that won't let you record your position.

So your solution for a software problem is buying more hardware. Companies must love you.

I don't think that was the point at all, the point was that if your app doesn't let you record your track without internet connection, then it's on that specific app (and eventually it's on you if you stick with such an app).

There are many apps that let you track your run/hike/ride without internet connection.

You got it; the point is that it's a one-time problem after which a different app should be chosen. There's a ton of things out there which'll record rides offline.

Personally, I think a dedicated bike computer is best, because then the phone's battery is saved for emergency uses instead of recording a ride. For long rides (8-10 hour) phones won't have enough battery to record the whole ride.

Some people like the interface/extra features of an app. I tried going from google maps to open street maps, and came back in 5 minutes flat.

I don't know if companies love him but I know Strava is an android app.

An android app is software.

Not hardware.

What new hardware are you referring to?

Strava doesn't require an internet connection (at least on Apple watch). For maps, Trailforks supports offline mode.

Strava doesn't need a connection on Android either.

...and yet, we're hitting to the same wall again:

Hardware is cheap, network is reliable. Move fast and break things.

Neither of these assumptions are true, and we're going to have these issues by truckload, until we understand and change our mindset.

The PADI (suba diving) app barely works without constant internet connection, especially eLearning is useless with it once you are offline / have a shaky connection.

Scuba diving spots on the world are rarely well covered with internet and even if they are, still many people don't have the roaming/local SIM solution for it.

Guess where you want to use that damn app the most?

Yeh I hit that too! If it’s the same app their business model is to charge for offline use.

Not a great way to get new customers though as it requires missing out on logging a ride to become aware of a reason to buy.

I record GPX with OSMAnd+ running on my older and smaller Android phone. No SIM, no Bluetooth, only GPS. It goes on all day long. Then I send it to my new phone or to my computer over WiFi. If I were in the mountains I'd turn on hot spot mode on the phone to make the transfer work.

No log in, no external services.

It's exactly why I quit using fitbit 4 or 5 years ago when they made a similar change. There should be 0 reason for needing an internet connection to send data from a wristband 2 feet away to my phone using bluetooth in order to tell me how many feet I've traveled. That may have changed since then but I wouldn't know. They lost me as a customer.

Some great offline GPS (cell-free) map apps for Apple iOS are

- Sygic,

- Topo Map+,

- 2GIS

- Starwalk - Night Sky 2

- and my fav, Genius Map

all works without WiFi, cell coverage, nor NFC/bluetooth

Also maps.me

Maps.me started to implement some monetisation UI bloat a while ago. I swapped to organic maps. Can’t remember if it’s a fork or by one of the old maps.me developers but there was some connection.

Is it possible to migrate saved-places from MM to OM ?

You made the mistake of thinking an app's functionality is it's purpose. The functionality is just a thin veneer of an excuse the devs use to track your every moment. Why would you think otherwise?

Even if it cost money to install, you are just paying for the privilege of being tracked by those folks instead of others.

#appsnotevenonce

Any good FOSS exercise monitoring apps?

I use GPSLogger that saves my ride to a GPX file that can then be imported wherever you want.

Hamburg, Germany: the public transport services released a new app a few months ago which assumes that the request failed when the app has not finished receiving an answer to a route query after a given time span. The problem: It is normal to have a data cap that, when reached, limits the rate to 64 kbit/s. That is too slow for the answer to be fully transmitted in time...

At least the website works, even though it transmits the full site for every request...

For android users, Strava makes things easy, but OsmAnd has way more features and I like it a lot more.

You can’t add a password to Bitwarden while being offline.

Discovered this when I tried to add a WiFi password before connecting to it.

While I strongly sympathize, in this case it specifically addresses one of the OP's main objections: why did they have to download and install many GB of stuff that they'll never need. The three options I can think of are: (1) install everything (what they objected to), (2) ask the user what things to install (they probably already had this option but didn't know what they needed), or (3) install a minimal amount and download on demand. Although it doesn't work well for you, it seems it would work well for them.

Because OP is being disingenuous. 20GB is for the _full_ install of VS 2022. The required components for what he is doing is literally half that.

Is it clear to a novice which components they will or will not need ahead of time?

I would guess because the world doesn't revolve around you? You can download the full installers and bring them over on a USB, it's a trivial operation. You can also build on a networked computer and then bring over the final file(s) to your air-gapped system.

Man… the number of times I’ve had to debug a broken Steam game by installing the Nth .net runtime version…

For me it's zero.

My guitar tab program, which I pay for, refused to show me my library of tabs when I was supposed to play for some kids at a mountain campfire because it couldn't verify my membership because no internet connection. I'm not a good guitar player, and my memorized repertoire is... well, not of interest to 12 year olds. :)

I wouldn't say the campfire was ruined, by my goodwill toward this product certainly was.

> I wouldn't say the campfire was ruined, by my goodwill toward this product certainly was.

Your goodwill deterioration does not matter unless you switch a new a app[1], and a) Make sure that new app can function without internet, and b) Tell your current app developers why you are switching.

So, yeah, your goodwill is irrelevant is you're still giving them money or value. [1] I assume that it's a subscription - most things are nowadays.

What dev system allows you to build things without downloading required components first? None?

Like every other dev system, connect, either download offline installers for everything (they exist), or get your system running, then you can dev offline all you like.

You don't need to "be connected to the internet at all times for any reason whatsoever". You need it once.

Agreed. I was very happy when it was announced in 2019 that Cargo got offline support: https://www.ncameron.org/blog/cargo-offline/

You can even prefetch popular libraries: https://crates.io/crates/cargo-prefetch

You are missing the point. ...We have imaged Black Holes galaxies away, detected Gravitational waves from the other side of the Universe, landed on the Moon.

But to this day, nobody knows what data your system telemetries to Microsoft. Not the data they talk about in the 5-10 page license. Instead, the data mentioned in the 55 page doc about what you agree to send them, that they refer to from the MS Software License...

What is it that you are complaining about really? You need the latest runtime if you want to develop for the latest runtime. If that's your intention, download the latest runtime anyway you like, and then install it on your target machine. If it's not, don't download it and develop for the last runtime available on your machine.

its a split game, you can install everything at once, like 60gigs, and then you can happily work offline, but for most people, it is much easier to work from the on demand model, to pull what is needed when its needed.

Well, in .net 6 you have the ability to deploy self-contained application, in a single file manner and even compress the binary [1]

The end result is a Golang-like, single binary experience that runs on many platforms easily and rapidly.

Though I can master a lot of programming languages, I miss C# the most especially on async/await and LINQ. Rust is what I'm favourited in second places with a lot of similarities of C#.

[1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...

> If you want a single-file exe that's a bit more advanced and requires a few properties in the csproj.

This. This is what's wrong. Why is single-file exe "a bit more advanced". In early 2000s Delphi could build a single file exe in seconds, and that was the default behaviour.

What changed since early 2000s that having an exe is a) advanced and b) requires manually fiddling with some unspecified properties in the abomination that is a csproj file?

Embedding native assemblies inside another application is apparently very hard.

I'm not sure I know any frameworks that easily support arbitrary native .dll/.so inside the application executable.

The rest of the world refers to this as "static linking" and it is, in fact, trivial.

It's amazing that most people on this thread seems to take this nonsense as being completely normal and acceptable now. It really shows how much windows dev has devolved over the last decade.

Why does every linux app I download come as a self-extracting installer, run in a container, or download dependencies? Those aren't single-file executables.

The discussion was about Windows, which offers self contained apps and where the support matrix isn't the size of Asia.

Which dotnet supports with a single compile parameter, I'm not sure why people are making it out as if this is some very complicated feature.

> I'm not sure why people are making it out as if this is some very complicated feature.

OP asked how.

The answer was, quote "If you want a single-file exe (as in completely statically compiled without self-extraction) that's a bit more advanced and requires a few properties in the csproj to configure how to handle native assemblies that expect to exist on disk. If you want it to have no runtime dependencies, add `--self-contained`"

Somehow creating an exe is "more advanced", and requires changing of unspecified parameters in the project file. wat.

Huh? `dotnet run` created an .exe.

I'm talking about creating a single-file application, which is just an end-user nice-to-have if you aren't using an installer or deployment system.

Don't most applications have a bunch of ancillary files? I rarely see installed applications on any platform that are a single file.

> Somehow creating an exe is "more advanced"

.NET Core is cross platform, it was created with ASP.Net as the driver and web development is not about exe files. "dotnet run" runs your code, on any platform, that's one of the default intended ways to run code. If you want a platform-specific executable you've done more work and made the code less general. If you also want to package the entire .Net framework into one binary on any platform, why is it unbelievably impossible to understand that this is more effort and desired by fewer people, so isn't as easy to do?

It is trivial if you can embed most of the OS inside of your executable, if there can be only 1 version of the OS, if you do not use any libraries you cannot statically link and so on.

https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...

Strategic decision from Sun and Microsoft that has crippled software for 2 decades already.

> This. This is what's wrong. Why is single-file exe "a bit more advanced".

Because that's how it works for very every single interpreted and bytecode compiled language?

And the thing that changed in the early 2000s was a massive shift toward using interpreted and bytecode compiled languages.

If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place. On Windows, .NET *.exe files were still run by an outside runtime, it's just that, since Microsoft owned the whole platform, it was easy for them to hide all that behind a curtain, ensure .NET is preinstalled with Windows, etc. The design constraints changed when .NET became cross-platform. OS X and Linux require a bit more (or at least different) finagling in order to achieve good user experience.

Which is exactly why I dont use any of those. I will stick to Go, or Rust, or Zig. People expect to be able to produce a single EXE. Maybe not as the default, but it should be an option, and an easy option. Any language that cant do that is a failure in my opinion.

Also please dont lump interpreted languages with C#. At least with interpreted languages, once you have the runtime on your computer, you can have a single script file to work with. With C#, you STILL have to have the runtime on your computer, then after you "compile", youre left with a folder of one EXE and literally over 100 DLL.

> With C#, you STILL have to have the runtime on your computer, then after you "compile", youre left with a folder of one EXE and literally over 100 DLL.

No you don't. If you'd rather increase the download size for the user then you can turn on self-contained (include runtime) and single-file app.

That single-file app is a zip archive with exe and those dlls

With Python, if I publish my script with 100 dependencies, and someone `pip install`s it, they will also end up with 100 packages being copied to their computer.

The main difference is that Python installs them globally (or at least thinks it does, if you're using virtual environments), while .NET apps isolate themselves from each other.

Also, let's make a fair comparison. Is that hypothetical Rust application of yours depending on literally 100 crates? If so, what is the size of your binary?

Please don't use Python package management as a baseline. Aim higher.

I love Python, but I cringe whenever someone asks me why a Python program isn't running properly on their machine. Obligatory xkcd: https://xkcd.com/1987/

Funny how feelings change. https://xkcd.com/353/

Take PHP with composer: it works quite fine, but still you need all the dependencies downloaded from somewhere on Internet. Just a PHP script and the PHP interpreter works, but this is not how 99.9% of the software is written.

The php world invented the phar format [1] to deal with the single file tool/app distribution issue.

In fact, composer uses dependencies managed by itself in their sources. Then it gets packaged and distributed as a single file that includes all dependencies (composer.phar). That single file can be run by php as if it was any regular php file (including executing it directly and letting your system detect the required interpreter through the shebang).

https://www.php.net/manual/en/intro.phar.php

Self quote: this is not how most apps are written.

> At least with interpreted languages, once you have the runtime on your computer, you can have a single script file to work with.

The Python people stuck in venv hell would probably think otherwise.

If we're talking modern .NET ( 6 for example ) you have 4 options, let's assume a simple hello world without third party dependencies:

1. Build it runtime dependent: ( which requires the NET 6 runtime to be pre installed ) on your computer in order to be able to run: You get a single exe file.

2. Build it self contained: You get a directory with a bunch of dlls and one exe But no runtime needs to be installed on the target computer

3. Build it self contained + single exe: You a get a single exe that embeds all those dlls and unpacks them in memory ( since net 6, in net 5 it would copy them to a temp directory )

4. Build it using AOT Mode: You get a single, statically linked exe. This is probably the closest to a standard Rust (statically linked) build. However AOT mode is not yet official and requires some fiddling still, but should become stable for NET 7 next year. And you loose out on some features obviously like runtime code generation

> Because that's how it works for very every single interpreted and bytecode compiled language?

I went ahead and searched for C# executable around 2005-2006. Guess what, this wasn't even a question then. Because, apparently, building an .exe was also the default setting for C# projects in Visual Studio.

So. What changed?

> If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place.

It was always possible.

> On Windows, .NET .exe files were still run by an outside runtime

1. We're literally in the thread to a question about Windows apps. On Windows

2. If you've ever did anything on Windows such as played a game, you'd know that you almost always need something external to run: be it msvcrt (c++ runtime) or clr.

> The design constraints changed when .NET became cross-platform.

What you mean is: it's still perfectly fine to create a standalone executable, but for some reason it's now called a "more advanced operation". The thing that's changed is that now it's hidden behind a ton of inconsistently named parameters

But, per the last paragraph of my comment, those .exe files were not really executable files. At least not in the sense of, say, an AOT-compiled C++ application.

They were much more comparable to an "executable" Python or Perl script where the OS knows to look at the hash-bang line to figure out what interpreter to use to run it. If you try to execute one of those .NET .exes on a computer that doesn't have a suitable .NET run-time installed, you'll get more-or-less the same error as you'd get trying to run a Python script on a computer that doesn't have Python installed.

The part that was being criticized a few comments up was about how to create self-contained .NET apps with the runtime bundled in and everything. Specifically, these guys: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ... That kind of executable simply did not exist in the old Windows-only .NET Framework; it's a feature that was first introduced in .NET Core 3.0.

> If you try to execute one of those .NET .exes on a computer that doesn't have a suitable .NET run-time installed

Just as you would try to execute a program written in C++ (and not statically linked etc.) on a computer that doesn't have a msvcrt runtime installed.

This is not a new thing. Nor is it a "more advanced".

If you're happy with that error then you don't need this new feature.

It feels like you're getting too hung up on "exe". The important part is standalone vs. not standalone.

No application on a modern OS is standalone. They all rely on either having many components the need already installed, and then try to bring along others that may not be installed. As the commonly installed base changes, the included pieces also change.

I for one don't want every application to include 100's of MB of standard components that every other such app also brings (such as Electron style apps). I'd much rather have an app tell the OS to fetch missing pieces once, and once only, then future apps share.

And this also mitigates a significant source of security holes. Nothing like linking everything and the kitchen sink so your system is riddled with unknown, hidden vulnerabilities in binaries.

For example, I recent worked on tools to search for such things - they are EVERYWHERE. OpenSCAD, for example, includes a ssh engine, which has known vulnerabilites, but OpenSCAD does not list them. I found thousands and thousands of embedded binary libraries in applications with known and unpatched vulnerabilities.

Too bad all those didn't use a decent package manager, allowing systemwide updates to common functionality. I suspect the future is more components, not less, for these reasons.

"Oops, we couldn't find a shared library that this program depends on" is not exactly the same error as, "Oops, we couldn't find the interpreter / VM that you need to run any programs written in this non-AOT-compiled language."

In other words, compare missing msvcrt.dll more to missing libc.so than to not having a JVM or whatever installed. I guess from end user perspective the end result is the same - the program won't run - but what's actually going on under the hood is very different.

https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...

Short story: developer interests unfortunately don't always align with tool builder interests.

Do you know of any production GUI applications that are literally a single-file EXE and aren't like, small utilities? There's just no reason to try to pack everything into a single file, Go-style. The self-contained publish (which is literally a single flag) is a quite reasonable result - a directory of files that are completely sufficient to run your app on any Windows computer, without any dependencies to install.

> Do you know of any production GUI applications that are literally a single-file EXE and aren't like, small utilities?

The old Delphi-based version of Skype fell into that category. Thinking of that example, I can understand why some people think modern software is decadent.

Eg. Every .exe has an accompagning .config file.

It's really easy/simple to change an application to adjust for a different client this way.

The reason it's more complicated is to support reflection. C# allows you to create objects and call methods at runtime based on data not available at compile time, including classes and methods that don't get used by the normal (non-reflection) code.

That means that by default you can't do tree shaking, which means you would end up with enormous exes, which will probably annoy the type of people who want a single exe.

The bit more advanced is to tell the compiler which types you might want to reference by reflection so that it can shake the rest out of the tree.

And what. You’re going to run .exe files on Linux?? Lol.

This is my experience as well building and running .NET core stuff on Arch Linux all the time. You just have to know what you're doing, and the Microsoft documentation doesn't make it easy to take the minimalist route.

Microsoft could do a much better job onboarding new developers.

Microsoft wants to sell Visual Studio, this is why Visual Studio Code will never get a GUi Designer, or have easy compile options for C#.

Hell just recently they were trying to take away hot reload to keep that feature as a paid feature only part of VS

That's true.

I only really started liking .NET when I stopped using visual studio a few years ago.

Ah yes, VS' hot reload that insists on popping up a dialog every time a file changes. Garbage.

Visual Studio Code only needs to be good enough for a Cloud IDE kind of scenario for Azure workloads (it started that way as Monaco anyway), anything beyond that is a gift so to speak.

https://visualstudio.microsoft.com/vs/community/

I am aware of the community edition, which the most recent versions have a VERY restrictive license on the acceptable uses for the community edition

The fact this edition exists does not change my point, or really add anything of value to the conversation

Sometimes I feel like the Visual Studio team and the C# team don't talk to each other very much.

The C# team says "this is the new best practice" while VS still drives you to The Old Way all the time.

Your gut feeling is very correct.

https://news.ycombinator.com/item?id=28972431

There was a whole fiasco where the dotnet/C# team were forced to remove features from dotnet in order to sell more copies of Visual Studio. Later, Microsoft lied through their teeth and said it was some kind of sprint-planning scoping error, even though the development work was already done.

Worst part is that the person that made the decision to remove that feature was promoted. And now indirectly controls GitHub.

You have absolutely no idea what you are talking about.

Full disclosure: I know what I am talking about

It is quite easy, the ASP.NET folks on the C# team don't care about the remaining use cases, and they are the ones behind the initial .NET Core reboot.

Except, everyone else cares about everything else .NET Framework has been used for the last 20 years.

This was quite telling on the .NET 6 release with its minimal APIs to compete against Python and JavaScript "hello world" apps. As soon as one scales beyond that, it is back to the old MVC model.

This Is The Way. You don't typically need a single-file EXE, `--self-contained` is Fine.

This is probably the easiest way. The tragedy is that this explicitly rejects all the subsequent developments since WPF - UWP, WinUI3 - because they don't work nearly as well.

If you want an installer BTW, use "Wix".

If you are eligible for VS Community, do give it a go: https://visualstudio.microsoft.com/vs/community/ since that has the WPF designer in (the WinUI3 designer is inexcusably broken)

> the WinUI3 designer is inexcusably broken

I just tried VS2022, and the UI designer for WinUI3 is completely non-functional? What is the recommended approach to lay out the UI pages these days?

Realistically you have three options:

- ignore Winui3 and do it in WPF (fewer controls, deprecated, actually works)

- do it blind in XAML, possibly with the aid of a piece of paper. Or the "live view" in VS if that works. (Live View is the suggestion given on the github issue for "designer doesn't work", fwiw)

- do it in the UWP designer, then s/Windows/Microsoft/ in the control namespaces

holy shit

Exactly. And then people wonder why everything is electron nowadays. Native UI development on any platform is pure garbage compared to frameworks in Web frontend.

I hope SwiftUI and flutter will be able to make it at least a little bit better.

That's what i really love about the MS ecosystem. There are actually 3 ways to achieve a task, but none of it works fully end-to-end.

This, .net core is quite a pleasure..

This is the best response I've seen to the question: "What's the easiest way to get started developing a native Windows app". Better than anything Microsoft has put out.

Isn't WPF getting phased out tho?

dotnet is a stack for slow servers who love cold start

wpf is a stack for slow bloated apps (200mb for a hello world and 300 dlls)

even electron is lighter than this.. electron..

microsoft needs its swift + swiftui moment

Unpopular opinion: native GUI app development on most platforms is a shitshow. Huge toolkits, copious amounts of boilerplate, and a huge amount of dev effort thrown at the platform just to get it working.

Meanwhile, say what you will about the web ecosystem, I've given interns/jr devs tickets like: see if you can get this webapp running in electron, and maybe figure out how to do push notifications and save data locally. Two days later the project is done. A week later, the app is ready to install.

I think the real reason I quit doing meaningful amount of native GUI development a decade ago was velocity. The developer experience with iOS is probably about the best of the major GUI platforms, but even that is rife with tarpits of tribal knowledge and gets really complicated to release an app due to the whole App Store experience.

I second this. Further, the number of times I’ve tried to get into native development is about ten, and every time I’ve done it the APIs are completely different as the OSes have moved on to new ways of doing things. Meanwhile, the DOM APIs have been more or less the same since I learned them 15 years ago, with the oddball world-changing addition of querySelector or enhancements that people rarely use like Shadow DOM and filesystem API.

The APIs for cross-platform native GUI development haven't changed in any significant ways in 20 years or more.

If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?

Qt isn’t a native API. It’s true that there are stable libraries like GTK or WxWidgets which allow you to write native-looking apps (or for Linux, I spose that is native, and granted, Linux probably has the best native dev experience), and those exist in the form of React et. al. for the web world.

But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.

I use the term native to mean "an application that runs on the metal and has direct access to system calls, not in a VM of any kind, including a browser".

Qt is native in that sense, just as much as any other toolkit designed for the same purpose.

> every year I try to learn how to create an XCode basic app and it’s different.

https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time.

XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.

This is irrelevant in terms of developer experience. I’m sure it’s possible to maintain an existing app for years and years, but if every blog post in existence is written for a different version of the development environment (which are vastly different from each other) and the OS Vendor (Apple in this case) is deleting or never even producing documentation on these APIs, which definitely happens, the rot is too much to keep up with for people trying to learn the system.

One of the jobs of a software developer is to understand that companies that produce proprietary systems (such as Apple) have their own incentives that do not always align with the desires and needs of those creating software. Put simply, this means that you do not trust those companies to do the right thing for you, and instead you need to identify what level of their technological offerings seem most likely to represent the correct entry point for you/the project.

When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges.

Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.

I don’t disagree with anything you said. If anything, it just supports my point that native development is needlessly hard. Again, none of this has been true of the browser vendors. They have every incentive to get people to use their stack and make it nice.

By the way, a blog post on how to create Nibless apps would be invaluable.

Not sure about browser vendors and their stack. I almost never hear of anyone who develops on a browser vendor's stack, they use 3rd party tools in JS and CSS and webasm etc ... After Node wrapped up the DOM and put a bow on it, it seems that people move on (up? down? sideways?) from webdev at that level (except the people developing alternatives to Node).

I'm not sure if this is the source I used, because the date is a little late, but it seems very thorough and excellent:

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-...

Cocoa is quite stable, I can vouch for that. So much so that I was able to resurrect an open source Mac app originally written in the early 2000s over the course of a weekend. Some changes were required and there were a bunch of deprecation warnings, but it worked and could’ve been cleaned up pretty easily.

Yep. Getting started on the web platform is honestly still a marvel to me and unmatched after decades. Sure you can use babel/webpack/vite whatever, but you can also still create a text file called app.html, type your little program into it and then double click to run.

> see if you can get this webapp running in electron, and maybe figure out how to do push notifications and save data locally. Two days later the project is done. A week later, the app is ready to install.

So you had an app that was already written, ported it to electron (designed to make the port as painless as possible), and you note that this is easier than writing it from scratch with non-web APIs? This is not exactly suprising, is it?

So true. I don't think it's a surprise for anyone that developers experienced in web technology find it easier to make apps using the thing they're experienced with.

In a parallel universe, a junior dev who only learned Qt would have same amount lot of trouble making websites.

Maybe, but there a lot more web programmers than Qt programmers, so chances are you going to be dealing with someone who knows the web and not Qt.

> So you had an app that was already written, ported it to electron

True, and had we tried to port to native, that intern would have given up. Most of the business functionality was in a REST api, so porting to native was something that was doable, but the level of effort would have been extreme. Oh, and had we wanted native on Mac, Windows, Linux, Android and iOS... well... that's 5x jumbo right there.

As a general remark, I get confused and maybe even a little irritated when people conflate Android & iOS with macOS/linux/windows. I mean, a device that you interact with almost entirely via (multitouch) and generally has extremely limited display real-estate is fundamentally a totally different platform than a desktop computer. The interaction model, the display design... you're never going to want the same thing on both (unless what you want to do is extremely constrained).

You can sort of kind of pull this off with a relatively limited web app, where the interactions are limited to tapping (since there's generally touch interaction on the desktop) and the fluid layout possibilities of modern CSS give you some chance of coming up with a general design that can work sort of kind of OK across all browsers on all platforms.

But try this for a more complex app, the sort that has been traditionally desktop only, and I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms, regardless of the actual toolkits /technology you are willing to use.

> As a general remark, I get confused and maybe even a little irritated when people conflate Android & iOS with macOS/linux/windows.

Android and iOS represent the majority of devices your software can be run on. They are ubiquitous, and also very dependent on a native UI frameworks that are a somewhat better developer experience than their desktop counterparts, but only because the years of accumulated cruft are less. Incidentally, Android actually does have a desktop mode for it's GUI. That said, users rarely use the desktop Android GUI.

> You can sort of kind of pull this off with a relatively limited web app

I've had better luck with electron and PWAs on the desktop than non-native mobile tooling. This is largely because non-native mobile frameworks often don't have access to the same libraries - or the abstraction layer loses fidelity in trying to be cross platform. There's really no QT grade multiplatform tooling on mobile. There's some promising starts.

> I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms

It's hard to get a decent GUI on both Android and iOS that doesn't have a lot of rough edges with cross platform frameworks. They are coming along, but it's still just not quite there yet.

Not sure this is a very 'unpopular' opinion ...

I don't think I have ever witnessed a comment on Reddit, prefixed with "Unpopular opinion:", that did not actually contain a VERY popular opinion, and therefore rocket to the top of the thread thanks to reverse psychology upvotes.

It's depressing to watch this trope start to bleed over into HN.

Problems with the prefix aside (I'm not a fan either) Reddit does it's best to show you popular comments. If you go looking in the -10 through 10 range on relevant threads you'll have a decent chance of spotting them. Not "controversial", not "top" (or bottom of "top"), not "hot", just the 95% of comments that aren't driving engagement numbers.

After all it's neither going to be popular because it's a popular sentiment nor is it particularly likely to be something interesting/relevant to get upvotes on merit. It's just going to be an unpopular opinion that gets ignored.

https://en.wikipedia.org/wiki/Survivorship_bias

You are less likely to read the truly unpopular opinions but yes I agree, seems like a cheap way to gain popularity.

Well, it's at least a controversial opinion even if it also maintains popularity. People seem to rag on Electron apps all the time on HN due to their inefficient usage of computing resources. However, they are an optimal use of developer resources, which are far more constrained for the average project.

Also the phrase seems close to breaking the guideline against commenting about the voting on comments, and is a boring meta-comment that just adds noise. It seems like putting up a preemptive umbrella.

You're taking about wrapping a boilerplate ridden platform in another boilerplate ridden platform where someone else wrote either boilerplate. You're talking about a browser without window dressing. That's not making an app nor eliminating any boilerplate.

I'll also add that you lose most of the benefits of a native app and most of the benefits of a web app.

Well.. people around here love to hate on Electron so I can understand thinking it's an unpopular take.

But seriously Electron is so many times better than writing native apps .. or even trying to find the documentation for how to do _one single thing_ in a native app the way you want to.

I haven't touched GUI development for many years but 20 years ago I was able to learn Turbo Vision and create a simple TUI app having very little programming experience. A few years later I was using Java AWT and It didn't took too much time to learn it too. I cannot create a WebApp or even an Electron app of similar GUI complexity without spending much more time.

Native GUI is more cplicated nowadays too, but I don't expect it to change too much - controlling layout using CSS+HTML is harder than in most (if not all) native GUI frameworks.

Cannot agree more. I have used like 20 Native UI Toolkits ( MFC,WxWidgets,QT, WinForms, WPF, VCL, Android, Jetpack, SwiftUi, GTK, and the list goes on ) i have even written one myself ( for in game uis )

I still cannot comprehed how we ended up with the shitshow that is CSS/HTML. Even Javascript nowadays is a workable language ( or otherwise typescript ) WebAssembly is great... but the actual UI Layer with the DOM and CSS .... just a nightmare

Every time i have to work on something a bit more complex on the browser, i ponder of writing my own UI Toolkit based on Canvas/WebGL or WebGPU and just draw everything myself

Flutter for Web is doing exactly that. For some webapps, this might be a great way to go.

The performance of flutter on the web is unusable, I would be ashamed to ship an app using it.

What other framework doesn't maintain 60 fps in its hello world?!

Flutter works great on mobile and desktop though, I shipped multiple apps using it and currently writing a desktop app.

I am not sure, Flutter is still using DART ? That's a pretty big no go, last time i looked DART was a haphazard clone of Java/C#/Kotlin with no discerning features of any value.... I rememember when it was supposed to be the new Javascript (transpiling and big dreams of landing a native Dart VM in browsers )

For me its a no go to have a language that's bascially a dead end outside of one specific ui framework.. Seems like a solution in search of a problem.

I don’t have the patience or interest in messing with GUI frameworks anymore.

Any desktop app I make that needs a GUI gets written in Java. Swing is antiquated but doesn’t change every year like everything else keeps doing. I use an XML UI definition language (Swixml) to make it RAD. With a modern look-and-feel package it looks great, runs fast on modern hardware, works the same on Windows/Mac, is easy to deploy, and most importantly: I know it will work basically forever.

Getting started in the web ecosystem involves a lot of similarly impenetrable "magic". There just isn't a community built around creating project templates and creation scripts and such for lower-level programming.

I'd say you're right about the GUI shitshow, and the web ecosystem is just a slightly different kind of shitshow.

Absolutely.

There's a huge amount of tiny chores with web development, that if you hadn't learnt how to do them in 1.5 seconds 5 years ago, would take you 2-3 days to figure out.

There are a hundred small chores that must be done to build and launch software on the web that you have to learn before you get it going.

I strongly doubt desktop doesn't have the exact same volume of inane things as webdev.

Have you tried the Mac?

The size of node_modules and the compile times beg to differ.

I'll concede that native GUI development is tedious on pretty much every platform in existence. However, there was a golden age of Linux GUI programming that spanned from the mid 2000s to 2019, where you could spin up fantastic GTK interfaces in the span of a weekend afternoon. I still use GTK3 to make simple forms and utilities, and I reckon I will for quite a few more years; the workflow is flexible and straightforward, there's a ton of fantastic desktop widgets that work as well as they do on a touchscreen as they do with a mouse, and it was surprisingly extensible too. GTK4 has seemingly put that behind them to focus on a "write your app in this specific way or don't write it at all" ethos, but frankly I'm happy to stick with the prior toolkits. Maybe it sounds cheesy, but it really was my "ideal" GUI library for a while.

I recently switched to Fedora and discovered that it's straightforward to create native GUI apps for Linux these days: just use GTK+ with your choice of official binding (C, JavaScript, or Rust) and you're done. Things are well documented and generally easy to set up, at least in my limited experience.

Flatpaks make distribution a non-issue too.

There's a lot to untangle here.

Point 1 is largely true, Microsoft builds too many competing UI toolkits.

Point 3: You can slim down Visual Studio's install a lot if you're more selective during installation. For example if I only wanted to do .Net desktop application development it is closer to 4 GB and under 10 GB on disk.

Point 4: Is actually the end of the original synopsis on the topic and after it veers off. You successfully built the application.

Now it goes a little off the rails:

Point 5: "The app is extremely resource heavy and way too over-featured." Ok? You didn't say which toolkit, guide, or similar you used nor what you define as resource heavy or in what way it was "over-featured." This is too vague to discuss meaningfully (e.g. Win32 applications built in C++ definitely aren't resource heavy or over-featured for example, and since you didn't clarify even what tech stack was used let alone guide/template this isn't constructive at all).

Point 6: I've read this sentence several times but seemingly you opened an executable in a text editor and that somehow broke your build process? Or something? Was it write-locked by the editor?

Point 7-10: You had a working build pipeline, you broke the pipeline, then decided to start again from scratch in an editor that doesn't have native desktop development support on Windows (because the old editor was "bloated"). You found this process problematic.

So in answer to:

> Why is building Windows apps so complicated

You made it complicated by using unsupported workflows and introducing arbitrary limitations on what was a successful outcome. There's a lot you can legitimately criticize Windows and even its desktop application development workflow for, but this isn't that.

btw I used this guide: https://docs.microsoft.com/en-us/windows/apps/winui/winui3/c....

5. I wanted to build a Hello World App remember, to develop windows apps, they told me to download Visual Studio with the following features selected: workflows: Universal Windows Platform development, .NET Desktop Development, Desktop development with C++. Individual components: Windows 10 SDK (10.0.19041.0) and C++ (v142) Universal Windows Platform tools. I found all that unnecessary for Hello World but I was following a guide: https://docs.microsoft.com/en-us/windows/apps/windows-app-sd...

6-. Visual Studio was too heavy for my 7th gen Intel laptop so I switched to Sublime Text to work over there because I thought all build tools was installed. I tried to run "dotnet build" but it didn't work. "msbuild" worked but i don't know to run the built app.

Developing .NET applications using simple text editors isn't really practical.

Everyone uses VS, Rider or VS Code.

I used VS Code but I still can not run my app. I can only use VS.

VSCode has issues with MSBuild for all but the easiest (read: Recent .NET version, targeting the web) to build projects. It'll be difficult to get by without VS unless you're a wizard, in which case you're probably stockholm syndromed into VS anyway.

VS has a debugger, which I find useful during development. Not sure if VSCode does.

Edit: looks like there is an extension for C# and C++

VSCode can debug and build apps if you have the extensions and tooling installed.

Even C/C++ apps. It's actually a pretty great visual debugger on Linux for that reason.

Sublime Text is on par with VSCode. I wouldn't call it a simple text editor unless VS Code also fell into that category.

Does Sublime have a .NET plugin that offers intelligent, symbol based autocompletions (i.e. intellisense)?

> I used this guide: https://docs.microsoft.com/en-us/windows/apps/winui/winui3

Your experience is expected for the framework. That thing is brand new, has questionable architecture, and I'm not sure MS will be able to fix.

The old and stable stuff is WPF (GPU-based on top of Direct3D 9) and Windows Forms (a C# wrapper around Win32, easier to use when you don't have a professionally-made GUI design).

> Visual Studio was too heavy for my 7th gen Intel laptop

VS2017 runs great on my old laptop with Core-i3 CPU from 2016. It's not the CPU. Ensure you have enough RAM, the system drive is a fast SSD with enough free space, and it's not a software issue like malware or an equivalent.

"Ensure you have enough RAM"? If a normal recent laptop might not have enough then the blame definitely goes to VS.

> Your experience is expected for the framework.

This is worded like a defense? But agreeing with OP that the situation is awful?

> If a normal recent laptop

Apparently, 80% of recent laptops are engineered for web browsing and very light office workloads, even regardless on their price. Despite the CPUs are generally good, they don’t usually install enough RAM in them. It started to change recently, half of the new ones have 16GB RAM which is good for development at the moment. But that wasn’t the case in 2016 when Intel released Kaby Lake CPUs the OP has.

> agreeing with OP that the situation is awful?

I looked at WinUI3 not long ago, and didn’t like it too much. I wouldn’t call the situation “awful”, but it’s not good either, neither for OP nor Microsoft.

The Windows GUI software I develop for living is often based on WPF. I think it’s superior despite much older: amount of bugs, quality of tools, binary size, etc. Fortunately for the OP, WPF is still supported in latest versions of .NET and Visual Studio, and is very likely to stay that way.

I guess I could use WPF but I want to build a shiny Windows 11 app using the new controls

Neither WPF nor WinUI are using OS controls for most of their GUI. Their GUI is defined by styles and templates in various XAML files. You can make controls look however you like. Microsoft did a great job back then re-implementing UX of WinXP and Win7 on top of WPF, but unfortunately not the newer Windows versions.

Here’s a third-party project with styles and templates implementing GUI similar to Win10: https://github.com/Kinnara/ModernWpf Their approach seems correct, and the screenshots looking nice. I never needed that library BTW, my clients who need good GUI usually provide professionally-made design which is unrelated to Windows controls.

Also, here’s a relevant GitHub issue https://github.com/dotnet/wpf/issues/5793 which currently says “.NET 7.0 milestone”, however the 7.0 is scheduled for November 2022, i.e. in about 1 year, and they may or may not deliver by then.

> VS2017 runs great on my old laptop with Core-i3 CPU from 2016.

For the last 1 or probably 2 years now I've been using VS2019 quite successfully on a 10 year old laptop with an i7-3520M (+ 16gb RAM & SSD).

Yes, its way heavier and clunkier than something like Eclipse for example and I do whinge a lot about how it loves to chew a lot of CPU and get a bit laggy when I'm typing code (why does Roslyn need 50%++ while I'm typing a comment? Is it really that interesting?)

But it is still useable nonetheless. The main issue I have with it is that touchpad scrolling in the code window really sucks and VS is really buggy in general needing restarts several times a day or things start getting 'weird'.

> Point 6: I've read this sentence several times but seemingly you opened an executable in a text editor and that somehow broke your build process? Or something? Was it write-locked by the editor?

I can't imagine how you got to that interpretation.

Obviously what OP meant was that they wanted to get out of VS and try developing in Sublime..

And in doing so expected Sublime to be an IDE and not a text editor, which means they don’t really understand what. text editor is, what’s in scope, or how it functions.

No, in doing so they expected the IDE to continue to function as a build tool even if the programmer is using a text editor that works for them.

I needed to install Android Studio to get the relevant android build tools, when I was done, I didn't touch android studio, I wrote all my code in Sublime and run a command that uses Android Studio's tools without opening the app. Heck, I could even run an emulator without opening the Android Studio GUI which is comparable to VS. It seems like Windows devs are locked to Visual Studio.

Speaking as somebody who spent years developing Windows desktop apps professionally, yes this pretty much. Visual Studio is admittedly a bit bloated and can be slow, but it's pretty much the only game in town when it comes to building Windows desktop apps. Jetbrains Rider might be okay, never tried it. Don't even bother trying to use any alternate text editors or you'll be in a world of pain.

People used to doing development for Unixy CLI apps or web stuff tend to try to use their familiar tools when trying to do Windows desktop app development, and run into a ton of problems. The solution is, don't do that. Use Visual Studio the way it was meant to be used.

Also, in the web world, it may be less of a pain to always use the newest hottest thing. Microsoft does have a tendency to produce half-baked new UI frameworks and over-hype them before abandoning them, so people used to the web world way of figuring out what to use tend to get sucked into them and then get frustrated. IMO, stick to C# WinForms to get going, and use it until you know you need something it doesn't do well.

>IMO, stick to C# WinForms to get going, and use it until you know you need something it doesn't do well.

Heh, as per the discussion above, this really should be prefixed with "unpopular opinion:", since you really don't see a lot of recommendations that people use WinForms for anything these days.

WinForms is actually super nice, and given how many toolkits MS released after that, latest one even without working GUI designer, I'd say WinForms is one of the best options available.

I agree, it's unfairly maligned and very useful.

I read the sentence as “I opened the source code in a different IDE and it fucked with IDE files of the first one”. I don’t use any of the mentioned IDEs so I’m not sure if that’s true or not, but I have ran into it before. I just delete all the files that I wouldn’t check into scm and reimport into my IDE of choice

I don't understand why the text editor is coupled to the build process. Visual Studio has, in my opinion, a text editor that leaves a lot to be desired. Multiple cursor support is especially bad, even more so when compared to VS Code multi cursors. Sadly I'm stuck with VS since I'm working on a Xamarin app and I couldn't figure out how to build and run with MS build :(

Even though I personally much prefer Unix environments, I've done a lot of work in Microsoft's tech stacks and WPF in particular.

WPF is nice, but it's not developed much anymore and lacks basic features that people have come to accept (great touch support, smooth scrolling). And the successor technologies are all a mess, driven by Microsoft's internal politics more than by any coherent strategy. I tuned into a few streams of Microsoft's developer conference last year, and no fewer than three different UI libraries, developed by three competing divisions, where announced as "the future of app development on Windows". I can guarantee that only 0-1 of those will survive, so good luck betting on the right one.

The only real recommendation I can give is to do as Microsoft does, not as they say. So while they tell everyone to use UWP, WinUI, MAUI or whatever, all of their own new apps are written in Electron. Decide what that means for yourself.

I am a long time Windows desktop developer. Since around Windows 8 MS has lost any sense of direction and just keeps cranking out new frameworks only to drop them soon after. All frameworks available are either outdated or incomplete. It’s very frustrating.

When you look at Teams or Outlook it seems even MS themselves doesn’t know anymore how to develop solid and reliable desktop apps.

My advise is to go either qt, electron or web. Preferrably web IMO because there is a clear path to the future.

I just went back to Java Swing and stopped being frustrated.

It says a lot if Swing is the least frustrating framework.

At least it’s stable and doesn’t change all the time.

Exactly, do what Microsoft does and avoid Microsoft frameworks.

That's because MS effectively abandoned Windows as a revenue generator, in order to become a cloud vendor. Windows exists just to give you a way to consume or develop web-apps that run in Azure. Office exists to get you to use Office365, again generating cloud-based revenue.

Commercially, it works. Unfortunately, it's slowly killing the desktop computing experience. Unlike Apple, they don't even have a real interest in shifting hardware, so they can happily treat the desktop market like dirt.

It's weird, seeing MS effectively strangling their own baby, but I guess Wall Street is happy.

Exactly. Your post answers OP's question.

The root cause of the SDK fragmentation is because Microsoft sees diminishing returns for Windows.

After Silverlight failed to gain adoption, they started losing interest in the desktop. When Windows Phone was killed, there was even less interest in UWP.

It's a shame because .NET is quite nice.

> just keeps cranking out new frameworks only to drop them soon after

I agree with the first part, but IMO the situation would be better if they actually dropped frameworks instead of having them all in a limbo state.

And provide an upgrade path.

I think the main culprit for the whole situation - that is, the fact that building anything on Windows is a byzantine and convoluted process - is the fact the whole OS was designed with CLI as an afterthought. On UNIX the CLI is always forefront and center - you don't really have "GUI" apps, all apps are console apps and they may connect to some sort of Window server and draw windows.

Meanwhile on Windows there was close to zero effort on making the system usable from a CLI before half a decade ago. There are still lots of tasks that require you to log in on a GUI, for instance. Applications started in GUI mode have no console attached, so you have zero diagnostic messages when started in a CMD. The entire command line tool situation is a complete mess, and it's clearly meant that msbuild and friends are actually meant to be invoked by Visual Studio instead of being used from a CLI.

Until a few released ago there still was no non-hacky way to get a development PowerShell, because all the various `vcvars` scripts were only batch files.

The complexity of using XML files in project descriptions just complicates things, and ironically I've seen several occasions in which msbuild just tells you to change a settings using Visual Studio (instead of telling which CLI toggle you are supposed to use).

My two cents is that IDEs and GUI told may be convenient but they should never be the default way to do anything, especially with development tools.

I completely disagree with this take.

The process of making GUI programs used to be very straightforward. If anything, in the last 10 years, Microsoft has improved the CLI experience by leaps and bounds, while at the same time it made making GUI software significantly worse.

Making CLI programs on Windows was never a big problem. There was always a way depending on which language you chose, and even if you wanted to POSIX you could with Cygwin. Sure, it wasn't Linux but that was the nature of the system. Now you don't even need hacks.

Making GUI software, however, is currently very... weird. Making GUI software, especially on Windows, was historically very simple and never required any CLI, let alone a good one.

I also disagree that making GUI apps in Windows is a "byzantine and convoluted process". It is not, and it never was. You can create a simple GUI app with a single .cpp file and compiler command. If you want to use Winforms you could draw the windows. VB6 before as well. WPF on Visual Studio was also very simple.

The only part that I agree is still unfinished is the .NET CLI-only experience, which the OP complained about. But that part also kinda sucks on Linux and Mac. If you use Visual Studio it works well.

The whole issue with native GUI apps in Windows currently is that nobody, not even Microsoft, knows the way forward for apps. Apple knows: it's Swift and Cocoa for Mac. The Linux world seems to be moving towards Wayland (I know I'll get some smart-ass responses on that). iOS and Android also have a happy path.

On Windows? There are 6 or 7 different APIs and 20 different ways to start an App, and none of them super maintained, well documented or even officially favoured by MS. Sure, Win32 might not be going away, but some things are better in WPF. Wait oh no WPF was replaced by WinUI. But what's that WinForms thing? And this MFC thing that got recent updates?

I think you've got this all wrong. Building Windows apps on Windows is really simple as long as you do it the Windows way instead of trying to cobble together a way to make it as much like the Unix way as you can. Abandon all thoughts of using a CLI for any part of the build process, install Visual Studio, and build with it using the default starter projects. It will just work.

You're right that the CLI is an afterthought. So stop using it. If you want to build Windows apps, you've got to do it the Windows way, or it'll be a world of pain.

You do need a CLI to do CI, which is necessarily headless. The toolset you need for this is the "Visual Studio (year) Build Tools". https://community.chocolatey.org/packages/visualstudio2019bu...

MSBuild isn't _that_ bad once you learn its terminology. Get the msbinlog viewer, an absolute hidden gem of a diagnostic tool. https://msbuildlog.com/

>Because Visual Studio is so bloated

It's definitely huge tool, but it allows you to do a lot of kind of developments.

I think it's very decent tool if you want to do C# development, especially when you want to have reliable intellisense and strong debugging tooling

(expression evaluation at fly, changing code at fly, moving to different lines during debugging, conditional breakpoints)

It's bloated for Hello World

Yeah but nobody develops hello worlds for a living.

I'll throw some shade on the instructors at Coding Camps

Most of this is either inaccurate or downright false.

The most valid point is that Microsoft keeps churning out new UI frameworks that all seem to die quickly, with some still staying alive.

Running compilers in the command line on Windows has always been possible and it is trivial these days.

That goes for both (MS) C++ or .Net.

Hitting F5 "build" is easier than using the command line. That does not mean the command line in not well supported.

Visual Studio will generate a script you can use to build the projects from the command line for your projects

Here is an example of a minimal Win32 app written in C https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo...

It is tiny and uses nearly no resources. The code is about the same as it was 10 years ago.

Using Winforms with C# it is trivial to create a minimal Windows application that is small and uses nearly no resources. (just but a button on the canvas, hit F5).

Any decent code editor can be easily adapted to work with the C# or C++ Microsoft compilers for builds.

Visual Code offers deep support for C# https://code.visualstudio.com/docs/languages/csharp

This article seems to outline how to get C# support in Sublime (I am not a Sublime user so I dont know how well this works) https://www.quora.com/How-do-use-sublime-text-editor-for-cod...

You don't really understand this. You're using a shiny new computer so running Visual Studio is not a big deal to you. You wouldn't say so if you were say living in Africa and having a really shitty connection. Sublime already allows me to build and run Android apps on an emulator by clicking Ctrl+B and takes 30s for a cold start (the app is very complex). VS took minutes (for Hello World).

I want to build a WinUI3 app, and that seems to require 56mb and a hundred of mbs of dependencies just to show a button with "Click Me" on it.

So your complaint is that developing for the latest and shiniest tech requires a relatively recent computer? Looking at this thread my only opinion is that you’re not understanding the things you’re complaining about.

Is it really an unreasonable expectation that you should be able to use the editor of your choice to build an app?

Perhaps you're right that this is the case for niche platforms like macos, windows, certain embedded systems, etc, but for general programming a text editor + compiler/interpreter is the default expectation.

In fairness,

I did include instructions for configuring both Visual Code and Sublime in my comment.

How to create a simple and minimal WinUI app here: https://docs.microsoft.com/en-us/windows/apps/winui/winui3/c...

We have a Windows POS app for mines, quarries, sand and gravel, etc.

When we broke ground on this version Microsoft was hardcore pushing UWP. We were building for the future so we built our app within the constraints of UWP with the expectation that it would grow with Microsoft’s vision…

Fool me once, as they say. UWP is dead.

We are currently redeveloping the entire thing with a series of Win32 base classes and intend to layer on a WPF front end for now. WinUI is early and promising. But so was UWP.

Long term we’re exploring outside the box UI options like running a local server and popping a browser. C# and .NET are very powerful. But the fractured landscape for desktop development gives little hope for the future.

If your goal is to build a rich UI, then you may have to suffer through learning whichever flavor of XAML you decide to go for. But if your goal is to interact with local hardware functionality I’d probably steer clear and use WinForms, a browser interface, or a console interface.

> Long term we’re exploring outside the box UI options like running a local server and popping a browser.

So... basically Electron?

Sort of. But not an embedded browser. And .NET instead of JS.

There are some promising developments with Blazor and .NET MAUI. But it all seems too speculative to build on at this point.

> .NET instead of JS

If you don't use JS, wouldn't that mean reloading the whole page for every action? Or do you still use some minimal JS to improve the experience?

I'm mainly on WPF, so I might say something wrong, but I think adjusting your UWP app for WinUI would be a breeze compared to redeveloping everything with Win32.

Only up to WinUI 2 apparently, WinUI 3 doesn't support UWP anymore:

https://microsoft.github.io/microsoft-ui-xaml/about.html

Some of MS own apps are written on Electron. Think about that when considering their awesome native UI frameworks

Which ones?

VS Code and Skype are the two I know about.

Teams and Azure Data Studio.

Also their entire office suite is migrating to an webapp. I use it at work and it's quite impressive even though it has issues and is inferior to native. But hey, it's only the beginning and can be used on every platform without the need to install. Web tech is awesome.

> UWP is dead.

Why do you think UWP is dead? Please post links.

If UWP would be alive, Microsoft wouldn't advice on how to migrate away from it:

https://visualstudiomagazine.com/articles/2021/10/19/uwp-mig...

Also apparently WinUI3 won't get UWP support at all:

https://www.theregister.com/2021/07/02/uwp_microsoft_winui3/

Nobody at Microsoft is going to come out and admit that UWP is dead, but it's easy to read between the lines.

It is quite complicated but at least it feels like it’s finally heading in the right direction. I recently did a deep dive into WinUI3 and the Windows App SDK and finally they are separating these tools from the OS and making them available to packaged and unpackaged apps. I wouldn’t bother with any of the older approaches unless you have a reason to, as this is clearly the future.

Speaking of which, the reason your exe doesn’t open is because you’re likely building a packaged app. You can think of that like building and iOS/Android app where it comes with a bunch of extra metadata and hooks into the OS, but that means you can’t just launch the exe and it has to be installed using the new .msix installer format. Thankfully the Windows App SDK just added the ability to build unpackaged (I.e. classic win32 exe apps): https://docs.microsoft.com/en-us/windows/apps/windows-app-sd...

I have built and tested both approaches and they work well, though unpackaged apps aren’t able to use certain APIs that expect “package identity” (I.e that special metadata I mentioned above)

I built a packaged app. The build outputs a .exe file in the build dir but when I click it, nothing happens. When I build using VS, VS automatically install the app for me and I can run it from the start menu.

Yes you can’t run a packaged app just by double clicking the exe, as I mentioned above. But you can build unpackaged apps with the windows app sdk now.

WinUI3 unpackaged apps? In C++? I would be interested in learning more.

In C++ or .NET (C#)/etc. I shared a link above

Until they change direction again. I was a complete .net acolyte until wasting years building projects on incomplete, politically hobbled, cool-chasing bullshit frameworks that were supposed to be finished but never were.

Most of us are building businesses apps. We just want a god damned form builder where you can double click a control and fill in the action performed code. Instead we have web tech (heaping trash fire) and several abandoned XML-based UI nightmares.

Oh, but the next XML nightmare is where it's at! ...and it will be done next year!

Web tech is awesome. Electron and WebView2 are great platforms for building desktop apps, hence why the former is so popular and why the latter is starting to see huge adoption. And WebView2 makes interopting with .NET a lot easier so it’s not either or.

What they meant by saying they decoupled it from Windows SDK is that it is now only found in the Windows App SDK which in turn STRICTLY REQUIRES the Windows 10/11 SDK which also requires on other tool chains and eventually Visual Studio.

I tried to build an unpackaged app but it didn't work (after I click run, the app closes immediately and some errors are spewed into the console. I can't understand the error and so can't Google)

This is bit extreme and if you are ok with the c language: 1. download tcc for windows(tiny c compiler from Fabrice Bellard). 2. compile the examples in the examples folder. Here you will find the 'hello world' program for both command line and win32 gui.

The download size of tcc is a few megabytes and the compilation times are for practical purposes instantaneous. You will have to bring your own IDE or text editor.

yeah but I wanna build WinUI3 apps not Win32. And that requires Windows App SDK and C++ tools which in turn require Dot net and the Windows 10/11 SDK which in turn require Visual Studio which makes it 20GB storage and 10GB ram.

Does qmake/Qt work sensibly in Windows? I've never tried it, but on *nix it's very, very easy to make a simple gui app with Qt, no real ide required. (0)

0: https://www.wikihow.com/Create-Your-First-Qt-Program-on-Ubun...

I know. This is what windows need to learn from *nix.

Yes, that's what we use. We initially planned it as a multiplatform approach, but on Mac we went native. We routinely get complaints about the app being old school and "ugly", but on the flip side, we didn't have to learn C#.

qmake and QtCreator work great on Windows and Mac. QtCreator calls the command line version of Visual Studio on Windows. The QtCreator debugger works seemlessly. (NB/ I'm still on Qt 5)

Yes, as long as you have visual studio installed it is quite seamless. I have taken huge GUI apps targeting Linux and had them “just work” on windows. On that note, I’ve taken GUI apps targeting Linux and cross compiled them to android and it “just works.”

Edit: wasm as well. I just started messing around with emscripten and it blows my mind that I can run a qt GUI app in my browser.

I agree that MS has done a terrible job at making their tools simple. I started programming using VB6 in 2002 and it was the easiest thing around. This simplicity still exists if you're trying to do winforms, but is gone if you try to do anything else.

If you're just starting out I'd recommend Win Forms + C#. WPF and all of the other gui options are insanely difficult for reasons I still haven't understood.

I made a quick video to show you how to create the app and get a simple hello world together. The drag and drop interface is great. Unfortunately virtualbox didn't record the mouse cursor (I am on OSX) so it's not as clear to follow as I had hoped.

https://wxp.io/visual_studio_winforms.webm

exactly. we learnt VB6 in school and developing apps was a breeze, even on school computers. But now, what a shitshow.

thanks for the video BTW.

As many have noted, there exist development systems that seem to want to involve wartime industrial efforts to craft even toothpicks (presumably also because they were born to develop the Unimaginable in a distributed international team of uncountables), and there are "measured" tools that do their job directly and effectively.

Many have suggested a number of effective lean tools. I suggest you also try PureBasic. You can build GUI applications in seconds (reasonably, depending on the functions to implement), even when just programmatically if you so wish. The executable will be compiled, small and fast. The language remains relatively very powerful (it does quite a lot on its own, and can hook to third party libraries when needed.

As a personal compact and effective swiss army knife, it's unvaluable. You seem to be oriented towards "manageable" development systems. There could be systems that are more instrumental to your curriculum vitae, but. Some of today's development systems are very high level, and I still believe that having a good grasp of the low-level, of the actual internal workings, is duly - the intermediate output of PureBasic is Assembly, and this should give the idea of the "faithfulness to low-level".

There’s no guide because nobody wants to learn Windows Desktop programming anymore.

The Web has taken over everything, even use cases where it shouldn’t, because it’s a career dead-end.

The IDE is complicated because it’s an evolution of 30 years.

As for the UI: - Win32: This is the C library for creating and manipulating Windows. This library is foundational.

- WinForms: .NET abstraction around Win32. Event-driven design. Every UI component is effectively a Window.

Very rich and complete; hard to write unit tests for; easy to peel away the abstraction.

Never going away.

- WPF: Reimagined UI library. Addresses the many limitations of WinForms. Inspired by HTML; steeper learning curve; designed to separate display from display logic, making unit testing a very possible.

Every year, someone asks if WPF is dead.

A big part of the problem, I think, is that tools that make it easy have been deemed uncool and as a result are half-heartedly supported by Microsoft, such as Visual Basic and MS-Access. Lack of vendor support has killed or hampered other easy-to-use development software that might otherwise find widespread use, including BASIC (classic and VBA; Microsoft, Apple), HyperCard (Apple), and AppInventor (Google). My two cents. :-)

Microsoft Plots the End of Visual Basic https://www.thurrott.com/dev/232268/microsoft-plots-the-end-...

Microsoft Access: The Database Software That Won’t Die https://medium.com/young-coder/microsoft-access-the-zombie-d...

Joel Spolsky did a pretty good job describing these problems back in 2004: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

Does Borland Delphi 6/7 exe files run on Windows 11?

I seldom use Windows nowadays but I did try running the Delphi Ide a while back and it created a 100kb exe file and it was running just fine on Windows 10 with almost everything working including the embedded internet explorer and firefox.

Not sure if this helps your case but it can certainly be done if Delphi can still create exe files that run just fine.

Lazarus would be a better choice for current systems.

https://www.lazarus-ide.org/

Embercado still maintain Delphi, so it still an option, but I believe their IDE is pretty expensive.

> Embercado still maintain Delphi, so it still an option

They appear to have a hobby edition:

https://www.embarcadero.com/products/delphi/product-editions

> Delphi® - Community Edition

> Our free Delphi Community Edition is designed for freelance developers, startups and nonprofits with revenues under $5000 USD and it allows them to easily design, code, debug, and deploy applications for iOS, Android, Windows and macOS from a single codebase with professional and integrated tools.

That said, I would probably recommend Lazarus:

https://www.lazarus-ide.org/

I run several of my D5 programs in windows 11 and they work great. Single .exe, just copy it and run it.

Never thought I'd say this but the Windows developer experience from Microsoft peaked with VB6. Later tools got more powerful but never quite reached the same sweet spot of productivity and intuitiveness.

Working on a small C# WinForms app right now, and saddened that Edit-and-Continue still doesn't really work, build times are 10x what they should be, and even hit bugs in the native control wrappers.

Microsoft used to have very smart people who understood their tech stack from the ground up. I'm sure they still do, but their business decisions make it seem like instead of stripping the paint and re-priming they simply keep painting over the old mess with yet-another-layer.

(Not saying they need to break backward compatibility, but do wish they'd update old paradigms rather than abandoning them to rot).

I've never programmed as a job; it's a hobby at most. But I could make simple VB6 programs when I was in upper elementary school. In high school I mostly used HTML/JS (partly because of portability, partly because I lost easy access to VB6).

I've looked at other things a bit (admittedly not a ton), but I've never found anything I could easily make a native UI with since VB6. About the closest I've been able to get is hardcoding whatever I want into a python file and tweaking as needed for personal use.

I’ve been building a C# WinUI 3 app as a hobby project, since the app in question only makes sense as a Windows app (making cross platform capabilities pointless) and because I don’t care a shred for the convolutions of front end web dev that come along with an Electron project of any significant complexity.

Getting started was annoying — certainly more so than developing a native Mac app with Xcode, which presents something closer to a “happy path” that gets you writing code with little to no boilerplate — but I finally got the ball rolling and have been fairly productive. There are some oddities though, like the collection type relied upon by list views not supporting sorting, requiring one to either wastefully allocate a new list, sort that, and assign that to the collection or implement sorting in a class extension. Very very strange stuff when you’re used to the base collection types in the language you’re working with supporting both observation and sorting.

I’ve read that picking up the latest Windows UI framework is foolhardy, but I really didn’t care to theme WPF so it’s a closer match to current windows design and isn’t glaringly bright when using dark mode. And as noted, this is a hobby project, so whatever. If a rewrite becomes necessary it’s not the end of the world.

"I don’t care a shred for the convolutions of front end web dev that come along with an Electron project of any significant complexity"

Already caught some of that action. Dumpster fire.

I find it very amusing that the current answers suggest:

- WPF with NET 6

- Electron

- WinUI

- Flutter

- That GUI programming is complicated

I mean tell me how to make a UI on Linux? Mac has it somewhat more streamlined oddly enough.

Hello World in GTK[0] and Qt[1] is simpler than the OP's experience.

Gnome includes Gnome Builder[2] in most distributions, which makes it incredibly easy to start making Gnome/GTK apps. Developers can also leverage Flatpak and Flathub for near-universal distribution.

0. https://www.gtk.org/docs/getting-started/hello-world

1. https://doc.qt.io/archives/3.3/tutorial1-01.html

2. https://wiki.gnome.org/Apps/Builder

Depends on the distro, but typically it’s GTK if you need something native, Electron otherwise.

> I mean tell me how to make a UI on Linux?

You copy paste a ten lines gtk or qt hello world, install a few packages (certainly not 20 GB), in a terminal go in the right dir, and type something like 'make'.

You certainly don't need 20GB to start with a simple Windows app. OP probably got confused because of the documentation and downloaded extra stuff.

Show me agood guide and I'll follow it instead.

The one I used was from Microsoft.

I have no idea man. Like I said in another comment, I feel you on the documentation part. They are...not helpful.

You can do the same thing on Windows. Don't be ridiculous.

The mac is trying it‘s best to catch up. Should you build your app with AppKit, SwiftUI or UIKit+Catalyst "Optimized for macOS"? I can‘t tell you.

Thankfully It‘s still a relatively straightforward process to create and compile an app with Xcode, which is the only option anyway. It‘s also a 30 GB download, but at least it‘s free.

VS Community Edition and VS Code are also free, and are certainly sufficient if you want to build a desktop app

Apple is pretty clearly gearing Catalyst as a vehicle for existing iOS devs to get their stuff running on macOS quickly. The canonical way to make a Mac app is still AppKit, or if your use case is simple enough SwiftUI (which is still AppKit under the hood). AppKit is still maintained and isn’t going anywhere any time soon.

The question mostly arises when you want to build a greenfield cross platform app. I chose SwiftUI, but feel like I might regret not going Catalyst.

I think Apple doesn't usually blunder around like Microsoft with these things, but actually pulls through long term strategies. We are in an awkward transition imho. AppKit/UIKit are super mature technologies, SwiftUI is the future but kinda lacking and Catalyst is either a shortcut to speed up Mac/iOS convergence or a backwards attempt to get more advanced iPad apps. It's all fine as long as SwiftUI is actually the future. If any of the others are relevant in 10 years, more than Obj-C is now vs Swift, I'll be disappointed.

I don't believe SwiftUI is technically 100% AppKit under the hood, but effectively is, for now.

Fire up netbeans, create a new swing project, and hit run.

One setting and you can make a fat jar. Double-click to run--everywhere.

One line of code and you can apply a modern UI theme that just works.

You are basically holding it wrong.

Visual Studio + Forms/WPF, done.

If you are more in the C++ camp, go with either Forms/WPF + C++/CLI, or MFC (yes really MFC).

Everything else on MS stack are just distractions, and VSCode is not for Windows development.

I found this to be useful, make a Win32 GUI in the old-school 90s way using MingW so you don't even have to use any Microsoft tools. It has the advantage that nothing has to be installed on the target PC except your application.

https://www.transmissionzero.co.uk/computing/win32-apps-with...

I used it to make an application that downloads files over a serial port from an OptiCon bar-code scanner:

https://github.com/jhallen/cartscan

Coming from UNIX, the biggest annoyance was Microsoft's use of wide character strings.

Everyone here sugesting electron or wpf but really… Just look up Avalonia and be done with it. Not everything has to be browser based or made by Microsoft.

https://avaloniaui.net/

Or even better, commit to MVVM and then you can swap between WPF, Avalonia or w/e Microsoft next comes up without having to rewrite everything.

This is part of the reason why electron is so popular these days.

Is it still that popular? Felt like it peaked but not the type of software I do so I might be out of the loop.

I would say it did peak but it hasn't quite let up yet in my experience. So many companies, especially startups, fall into electron as a defacto desktop application framework because of it's cross platform promises.

having worked at a company that's gone down that road, I think the jury is out whether that was a great move.

Pretty much all "desktop" apps that I see people using these days are built on Electron so yeah it is quite popular. Slack, Discord, Teams, Spotify, VSCode, the list is too long, unfortunately.

I saw this with the draw.io desktop app which turned out to just be a big bloated Electron package by looks of it. I have a browser for that already.

Not saying this is on the same level but I find it interesting that apps at that scale can run on Electron but Facebook's old non-native mobile apps performance was awful.

Their performance is awful too.

That was a decade ago.

Electron is huge. Wouldn't use anything else anymore these days, unless it absolutely needs to be native. JavaScript in 2021 also somehow turns out to be surprisingly usable. The ecosystem has really matured and people aren't chasing the latest hot new thing every 2 weeks anymore, but things kinda settled a bit.

I'm curious what you mean by "surprisingly usable" specifically.

This is just my subjective experience, but when I was first getting into node 6 years or so ago, it was pretty wild. Libraries would constantly make breaking changes, you couldn't count on things working for more then a month. JS is very expressive, and people happily did crazy things with it, like write entire frameworks based around generator functions. TypeScript promised some sanity, but usually led to even more headaches, due to lack standardized tooling, ecosystem support, random errors and so on. Sooner or later every codebase seemed to be doomed to become an unmaintainable mess.

But now it's a lot better. There's more consensus on what should be used, and most frameworks seem somewhat stable. Tooling is straightforward, in part thanks to VSCode I guess. Things like ESLint, JSHint are now standard. Altogether it feels more robust.

> Libraries would constantly make breaking changes, you couldn't count on things working for more then a month

This hasn't changed.

I hope not as I saw Electron apps are like JAVA apps. No. Nope. No way. I can do without.

Not sure why you would think this. It's not even close to comparable.

Yeah, Electron is much worse than Java.

The problem is that all of these components are named by people on the marketing team. And beyond asinine naming, marketing also seems set on obfuscating the technological relationship between different components.

Right, like Visual Studio and VS Code, which are completely separate products with vastly different use cases; named as if they were different versions of one thing, and in probably the most confusing way possible (Code? Isn't that what all IDEs are about?).

Not to mention the whole "Windows Forms, WinUI3, Win32 and WPF" mess.

Azure and Azure DevOps falls into the same category. Straight from the Idiot department at Microsoft.

Almost certain I’m doing it wrong (hobbyist), but most versions of vs studio have some kind of cli interface for installing workloads. I’ll fight with that until I figure out which includes the cli compiler tools. Write a script to automate install. Afterwards I’ll use a build system that calls vcvarsall.bat and perform the build from the cli.

I agree, it feels clunky and bloated compared to what I’m used to (especially if multiple vs studio versions required) but it gets the job done.

I’m very curious what workflows look like for people that know what they’re doing when building c/cpp on windows.

I'm also curious for workflows. I saw none that works with Sublime Text. Moreover I couldn't even find a simple build script.

After you create an app in Visual Studio you can build it by running msbuild. You don't need an additional build script.

Thank you!

But how do I run the built app?? msrun? msbuild run?? dotnet can "dotnet run" but msbuild??

This is Windows dev: while command line is available, everything has been thought for the GUI. Use Visual Studio, it will provide a much better experience. There's a button for what you want to do on VS (green arrow, at the top, the hint text is "run" I think).

For a packaged app, this may be relevant:

https://docs.microsoft.com/en-us/windows/msix/desktop/deskto...

There is a way to launch packaged apps from the command line once you have registered them:

https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/autom...

Everything with packaged apps is harder, so I try to avoid it.

The author is nuts, and so are many commenters here echoing their viewpoint.

The steps are

1. Download and install Visual Studio (author says C# - that's one checkbox to set in the installer)

2. Launch it and click make new -> desktop application

3. Hit F5

The rest is a self inflicted wound.

20GB for arguably the best IDE of the last decade may be a problem for a high schooler in a very poor country, but everyone else here, all supporters of this post included, should have no issue with it (unless also self-inflicted).

1 min build is basically a lie for launching a hello world app with F5. I doubt it will take more than 5 seconds on any machine.

WPF hello world app gonna build in couple seconds on any machine.

WinUI3 is a mess. I have a fast desktop PC, first time it took longer than 1 minute. BTW, the installation package size for “Hello world” app made from the default template is 92.6 MB without dependencies, and 139MB with a few dependent libraries.

So I would guess the problem is WinUI3? I develop Windows GUI apps for fun in my spare time -- I've built some pretty big and complicated ones using WPF/C# and the issues described by the OP don't seem real. My machine is old as hell and my build times are mostly unnoticeable, for example.

> So I would guess the problem is WinUI3?

I think the worst offender is the new packaging system used by WinUI3. The default project template creates a solution with 2 projects, the windows app itself, and the package. They including .NET runtime into packages, but for some reason VC++ runtime, and WinUI3 libraries, are shipped separately as OS-wide redistributables. Despite .NET compile sources into CPU-agnostic MSIL bytecode, the final result, the *.msixbundle file, contains an independent package for each CPU architecture. Unless touching checkboxes in VS during publish, gonna be two of them, Win32 and Win64.

> I've built some pretty big and complicated ones using WPF/C#

I do that too for living, WPF is awesome in comparison.

The steps are simpler because you know what you're doing, The guide from Microsoft told me to download 5 different products and download the Windows App SDK as an independent component. That was 20GB plus other MBs for the SDK. When I hit F5, it downloaded so many dependencies. It took minutes and the App was using a constant 56mb of memory while doing absolutely nothing (no events, no background threads nada) might as well use Electron.

It is important to note that I was trying to create a WinUI3 app.

Complain about the guide then. Instead you choose to make a clickbait title, and certain type of people followed along.

Also, distribution: Windows Defender requires code signing with an extended validation certificate, or going through the Windows Store. Otherwise users see a scary warning after installation how your app is probably a virus.

But using an EV cert means you cannot build on a CD service (it comes on a dongl). And users hate the Windows Store.

What am I missing as a mac person? I hear that most apps aren’t on the Windows Store. Is it normal to just have a virus warning and people ignore it anyway? Or can you just not distribute through a CD service?

If your executable isn't signed not only users will get a warning but browsers such as Chrome won't let you download it.

Oddly enough malware distributors have no problem bypassing all this

> Or can you just not distribute through a CD service?

You build on the CI, but then do the signing yourself on the machine which has the HSM... and then upload that as the release build...

I recently had to develop a small application for the MS ecosystem (An Office add-in) and as I use Pop OS as my daily driver, I had to switch to my Windows partition. While this was considerably simpler than what you describe, it was a very bad experience developing on Windows for the MS ecosystem. Bad and bloated documentation and boiler plate code of very low quality. It seems like MS responds to the competition with quantity instead of actually building some quality packages and frameworks.

> It seems like MS responds to the competition with quantity instead of actually building some quality packages and frameworks.

This! 100%! For many many years now. It's painful for all people involved (including the .NET community). Microsoft doesn't mind though, they love developing a shitload of competing frameworks, because once a framework hits version 3 or 4 where it starts to feel slightly mature then the internal incentives require the teams to dump the project and "invent" something new to stay relevant internally.

Yeah, developing Office add-ins is a nightmare and the Office team has totally screwed up Office extensibility.

FWIW they march to their own drum, they are largely independent of Windows and Developer Division. I would not tar all of Microsoft’s efforts with the same brush.

If you just want „hello world“, try tcl/tk. It’s the same as 20 years ago and a very simple language.

I build some simple GUIs for myself (ok, for Linux) and it was a perfect choice for that. Very stable language, relatively small, easy.

Python tkinter still went through the python2 to python3 storm and the unicode plague. So i hesitate to recommend that.

https://www.tcl.tk/software/tcltk/

Tk+tcl worked quite well for my very limited use and could be compiled into a single static exe.

But I mainly used it for creating simple register value calculator tools for helping with embedded dev.

all of what you describe happens when you try to build a modern web app using any of the hip languages or frameworks too.

what kind of app do you want to build? that is the first question to ask. then, you choose the right framework for it and the right project type in VS. with windows software, just like with mac osx, you need to read the docs first and think about what frameworks to use and what application type. preparation will help a lot down the line.

Listen to the .Net community and pick WPF.

Don't listen to whatever the Microsoft marketing department is hyping.

I would not recommend this for serious use but Flutter on desktop is taking a good shape. If you have tried Flutter for Android then developing for desktop is pretty easy. Although they are still ironing out some core functionalities it's something you can try and use for application development for both Linux/Windows.

I want to build using the native stacks as it's verrrrrrry fast.

>so complicated

Compared to what? GUI programming has always been hard on all platforms I tried.

MacOS is simple, open xcode, new project, choose the app and press run.

Well, so just like on Windows :P

Open VS -> New Project -> Winform/WPF -> Run

to elabolate:

1. Open VS, wait a minute. 2. New Project 3. Run, wait 10 minutes for dependencies to download. 4. Want to use Sublime Text or VS Code, haha lol.

>3. Run, wait 10 minutes for dependencies to download.

Why would you need 10 minutes?

>dotnet new winforms

>dotnet run

>app appears

takes a few secs

even on old .NET there was no such a thing like 10 min wait for dependencies to load

You didn't ask about their internet quality, computer specs, etc.

If you're used to developing on Linux where you can self-host entire repos, it's incredible how fragile and ephemeral the MS stack must feel.

What do you mean?

>If you're used to developing on Linux where you can self-host entire repos, it's incredible how fragile and ephemeral the MS stack must feel.

I guess he's talking about restoring nuget packages, so of course you don't want to have all existing nugets in all versions on your disk.

#3 is a one-time cost, #4 is you are doing it wrong

> 1. Open VS, wait a minute. 2. New Project 3. Run, wait 10 minutes for dependencies to download. 4. Want to use Sublime Text or VS Code, haha lol.

You're playing on hard mode; try using Visual Studio for everything.

Exactly. There's really not a way to make it easy. Web is the best UI dev method, that's why electron became popular.

Best is a strong word. Just because something is popular does not mean it is the best. It is the cheapest/easiest (for developers), I have to agree.

I found VB6 really easy. Draw buttons on a form, double click, write code behind. There was also a huge ecosystem of components you could use. Delphi was similar in spirit.

I've also found Python + Gtk (in the Python 2 and Gtk 2 days) very simple and productive.

There are a ton of problems that you have in webdev that don't neccessarily exist in a local app. Mostly from the fact that you have state everywhere, in the client, on the server, and in the database, and you have to manage it asyncronously. React helps with it a bit, but in principle a desktop app can be "100% frontend" (I mean you still have something like MVC, but you don't have a separate server or a sandbox for window js where you have to communicate).

> Draw buttons on a form, double click, write code behind

If my memory serves, this is also how WinForms worked.

Lazarus does that too.

One problem with VB is you still have to know C/C++ to extend it

Some tools made building GUIs easy (and fun). I can think of Visual Basic, HyperCard, Borland’s TurboPascal, FrameMakerPro, etc.

In today’s era, the easiest GUI tools are probably game engines, iOS and web browsers.

With Delphi, GUI programming was super easy!

Still is

Tk has generally been easy.

>Why so complicated?

It's because Borland isn't around any more to keep them honest, and focused.

Note: This is about building a program for Windows, not something to be sold in their "App Store", which is a whole different nightmare. The difference is important!

If you use Lazarus, building an app (I just did one) took less than 2 minutes from reading your question, to having an EXE (under 3 megabytes) that shows a form with a button, and when you click the button, says "Hello, World"

Command line programs in free pascal turn out even smaller. The exe files for this years advent of code for me are about 300-700k.

Lazarus also runs on my Raspberry Pi Zero W (the old one), which only has 512mb of RAM and a 16GB sd Card.

Bugger all that codswallop. Just build a Windows form app using .NET C# or Visual Basic in Visual Studio. I have done it many times.

Here is a very good tutorial series for WPF: https://www.youtube.com/watch?v=fZxZswmC_BY&list=PLA8ZIAm2I0...

Source is: https://github.com/SingletonSean/reservoom

It walks you through the whole process of creating an MVVM app including publishing. I saw and read many tutorials but this one was just AWESOME.

Handmade Hero is pretty much the perfect project for this. The first few videos go over basic C/C++, but I think in one video you build a Hello World GUI app without using Visual Studio to set up anything, you just call the compiler in a script (initially, Casey used VS as a debugger, which you can do by just asking it to "open" the .exe, but nowadays he uses RemedyBG which is pretty much as useful, and is lightning fast -- costs like 20 bucks).

Look at https://handmadehero.org/ and Previous Episodes, Day 001 and 002. He's creating a game, not a GUI with textboxes and buttons, but much of it is applicable, and there is very purposely no impenetrable "magic" operating behind the scenes.

As for "why is it so complicated?", well... none of the popular 3 OSes or ecosystems are really covering themselves in honor there. I think MS is unique in just how fond of "magic" they are, and there is a lot of boom and bust in their tech stacks, which seems to be mostly driven by their internal structure rather than any kind of rationale. Linux is fond of competition between mutually incomplete alternatives, and constant change even within alternatives. macOS is arguably the most sensible and stable, but it has been about 10 years since I wrote an OS X or iPhone app (weren't called macOS or even iOS back then).

I also hate complexity and I'm not a C/C++ professional creating apps for billions of people so when I need a tool or a program I just use microsoft build tools from visual studio 2019 in a batch script to compile/run from a single source file:

    @echo off
    call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
    :loop
    cl /nologo /Ob0 /O2 ./main.c /Fe"main.exe" && "./main.exe"
    echo.
    pause
    goto loop

This calls the environment-setting script and uses cl.exe from that env, then compiles and if successfull executes the program on the terminal.

Visual Studio current state is disgusting. vscode is an attempt to fix that but it is very slowly going the same route.

Edit: I try to depend heavily on win32, because they invested a ton of time creating the documentation, and stopped changing things every month (which is literally the ONLY thing software seems to be UNABLE to do, ffs), and win32 functions work most of the time with simple setup, and usually return a code if it succeeded or not, instead of sending some obscure event to god-knows-where that has to be handled with signals, or messaging or dark rituals! And there's an example for pretty much every function call, what more does a mortal need?

Everything that came after win32 is a hit-or-miss, undocumented, no examples, or just chaotic interfaces.

About the humungous Visual Studio download - that's annoyed me as well. I recently asked:

"How do I obtain Microsoft's C++ compiler and standard library (and just that)?"

https://stackoverflow.com/q/69274364/1593077

and the answer was either "You can't" or "It's complicated". I gave up and used the MSVS installer. And you _still_ need to invoke a complex script to get your environment in order.

I'm not sure what you mean with "just that", but eg the scoop package manager has visualc package:

  scoop bucket add extras
  scoop info visualc

  > (...)
  > The command-line compiler
  > functions of VS 2010 C++

  scoop install visualc

https://scoop.sh

https://github.com/ScoopInstaller/Extras/blob/master/bucket/...

Might be something via chocolaty/winget too?

I had not found a simple chocolatey-based option. But - can you explain whether scoop is a chocolatey alternative or something else?

Scoop is a bit like a user focused apt/homebrew. It's mostly for installing programs, not development dependencies.

https://github.com/ScoopInstaller/Scoop/wiki/Chocolatey-Comp...

These days, for enterprise application, ElectronJS is enough for most of use cases. You don't need a PHD in Computer Science to do that. Just learn basics of JS, HTML, CSS is enough.

I think the web is not the answer to all. All I wanted to build was a native windows app. Not to mention that Electron apps (or zombie apps as some call them) are very resource intensive and bloated. It's basically running the entirety of Chrome to show a few HTML files.

Get out of the comfort zone and use an older computer and try run an Electron app.

> All I wanted to build was a native windows app.

You can't have it both ways. As you found out, building native apps is very complicated and slow. Young devs don't have the pain tolerance of old school devs which had no alternative but to suck it up, endure the pain and march on.

But today you have a choice - be immoral and productive with Electron, or moral, slow and out-of-the-comfort-zone with the native toolkit.

The answers to all of the problems you listed are in the Microsoft online docs, but it does requires hours of reading to learn how all the pieces fit together. Native app development in C++/C# is not like "build a to-do web app in 10 minutes". Which is why very few build native apps anymore, because devs want instant gratification and native development is anything but.

> You can't have it both ways. As you found out, building native apps is very complicated and slow.

You certainly can; Visual Basic and Delphi send their regards. If "modern" tools have regressed then they're deficient.

Modern non-web tooling has regressed. For example, in 2018 you could download and install Qt and pyqt, make a UI in Qt Designer, run it through pyuic and have a working UI. I'm not sure when it changed but now once you find the installer, get through the Qt account requirement, and actually install, Qt Designer is nowhere to be seen. It may be hidden away in their IDE somewhere now, but I couldn't find it.

As some others mentioned, use Lazarus[0], it'd be the easiest way and you get a single exe file with no external dependencies.

It has been a long time since i made this video, but here is one[1] where i make a 2D tilemap editor in Lazarus from scratch - it starts with installing Lazarus (note that the video is old and some things have changed but 99% of it would be the same anyway).

Lazarus is crossplatform so here is another one where i make a small puzzle game under Linux/XFCE. Also starts with installing (which is a tiny bit more complicated because i need to build it from source - still a minute or so and strictly speaking you can get it running from your repository but chances are it will be broken and you avoid several potential issues if you build it from source on Linux).

I might make a new video at some point though as i'm back on Linux as my main OS nowadays and Window Maker as my window manager, it'd be the farthest from how things would look on Windows :-P. Though i might capture it in a VM if possible (the two videos i linked at were from a VM).

[0] https://www.lazarus-ide.org/

[1] https://www.youtube.com/watch?v=_3JgeIUo1X0

[2] https://www.youtube.com/watch?v=s_01Xhd2EJM

Really disagree with the OP.

Google "Windows desktop development" -> https://docs.microsoft.com/en-us/windows/apps/desktop/

Click the first chapter -> "Overview of app development options". It explains the options and their differences at a high level. Admittedly if you choose WinUI3 I haven't much experience, but if you chose WPF...

Google "Microsoft WPF" and click the 1st result:

https://docs.microsoft.com/en-us/dotnet/desktop/wpf/?view=ne...

Click the link "Create a WPF application". You get a lovely guide that was updated within the last month or so.

https://docs.microsoft.com/en-us/dotnet/desktop/wpf/get-star...

You can't really complain if you are a newbie, don't follow the tutorial, and find things confusing.

Dayshine's post (https://news.ycombinator.com/item?id=29529535)shows the easiest way to do things from the command line.

Microsoft is ousing WinUI3 so why would I go for WPF instead? Remember I'm new to windows development.

This matches my experience. Ages ago I was successful with the Borland tools to produce anything non-trivial. Eventually I worked a few months on a project with C# which included an installer. Somehow this seems very standardized but I was surprised to see that you had to register every single file in an xml file. On the upside, this would result in a really clean uninstall. So maybe part of this is also to prevent brittle software like in the past.

Assuming you're on Windows, as a beginner you should do everything with Visual Studio (not Code), it's the easiest way.

Create a new WinUI project (choose an UWP one), once you're on the hello world page, just look at the green arrow at the top of Visual Studio, press it and voilà it will run your app.

But to develop a visual app for Windows you will need to learn a few things before you can be at ease. There's one WinUI book for sure, and there should be courses too.

Keep it on!

1. If you wish to work with C++, then WinUI 3 is the latest and greatest, and the way to go.

2. WinUI 3 is the controls in UWP repackaged under a new name, but without the restrictions of UWP. The only substantial difference is a change of the root namespace from Windows to Microsoft

3 & 5. This is a sad reality of modern IDEs, it is a one off cost though, once downloaded and built for the first time it is smoother. Also, you can opt in on a component by component basis, so if you don't want them, don't download them.

6-10. If it works with Visual Studio, stick with that, don't waste your time and effort unnecessarily trying to run a complex build process in an esoteric way. If you want to use Sublime Text, then edit in that, and alt-tab back to Visual Studio to run it.

I don't think you have made life easy for yourself, but there is an overwhelming choice of frameworks when starting. Rather than evolve a single framework, they seem to create a new one every 3/4 years and deprecate the predecessor. That limits the work you need to do keeping up with backwards incompatible changes in the longterm, but it makes for an miserable start to Windows app development.

> WinUI 3 is the latest and greatest, and the way to go.

It's also brand new, hit 1.0 a couple of weeks ago, and therefore probably buggy (I hit a bug in -preview3). And it's about 100MB per app + 100MB of dependencies.

> but there is an overwhelming choice of frameworks when starting. Rather than evolve a single framework, they seem to create a new one every 3/4 years and deprecate the predecessor

They _don't_ deprecate the predecessor! That's the Apple approach, forcing everyone along. The predecessors are all kinda still supported with no "this will stop working" date, and you can still see WinForms controls in Win10 system tools.

> They _don't_ deprecate the predecessor!

Sorry, I mistyped, yes, they move to maintenance mode and you can keep using it.

> And it's about 100MB per app + 100MB of dependencies.

As I understand it, this is because it links the entire GUI toolkit in there, so you get a consistent experience regardless of what version of Windows it runs on. 200MB is quite a lot, but its not extreme, and if it reduces the longterm maintenance cost, it could well be worth it.

I found that using CMake with C++ was a pretty okay process on windows, despite not having much experience with windows. I have to run cmake and then msbuild and I don't really know the details, but I got a simple GUI application running with wxWidgets on windows, and I don't need to use the Microsoft IDE. I'm happy to share more details if anyone is interested.

It was a nightmare to figure out how to do it, though.

It's been years since I fooled around with .NET but the book I used (Microsoft .Net for Programmers by Grimes) started out with writing C# code in Notepad (or other editor of choice) and compiling with csc.exe on the command line. It would be sad if that sort of very simple use case is no longer supported, as it's always been the best way for me to learn and understand what is happening.

> I wanted to build Windows 11 apps and I had to choose between Windows Forms, WinUI3, Win32 and WPF I think. I don't really know the difference between the 3 and no one really explains that (unless Win32 which is obvious).

This is microsoft still makes it pretty simple to create apps that use 30 year libs and frameworks,

WinUI3 Honestly, this is a trash fire that microsoft tried to make developers work in a walled garden, restrict their ability to distribute to other platforms, and make it very difficult to distribute to anything but their app store. They have been handed their hat for several years now, and they have chipped away at their restrictions, such as allowing sideloading by default, and allowing win32 games to be deployed on the app store. These apps only support win10 an later, and require directx11. To me, this is a failed experiement, and that has damaged the windows development ecosystem a lot.

WPF is a vector based more modern UI that works well with modern MVVM techniques. But microsoft never gave it the attention it should, and it never reached the level of design and drag and drop UI development winForm did.

Winform, is the most mature, but honestly dead for realistic production applications, it doesn't support UI scaling. But it's much faster to develop in, has much more components available, and doesn't fight you nearly as much if you want to do Pinvoke stuff an the like.

At this point, you'd do best to just write your services in C# and do you UI in a web framework, or make use of https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

It's not any better on the Mac. I started trying out Playgrounds on an iPad and wondered why none of the suggestions and blogs on the web worked, only to find out there's a MAcOS version of Playgrounds and thy don't work quite the same. Then I find out there's a Playgrounds feature in Xcode and actually a lot of the guides and Stack Overflow answers are actually for that, although most such resources don't say which one they're for.

I finally settle on using the XCode one as most resources seems to be fort that, but after a whole afternoon failing to get a Playground to load a single package from Github I just flat out gave up. Pretty much nothing I could find about any of this ever actually worked.

My heart goes out to anyone trying out coding with playgrounds for the first time on an iPad and trying to find out anything useful, not realising almost all of the info they find is for the wrong Playgrounds. Compared to the built-in guides and helpful info for Pythonista and Codea it's an embarrassment.

To be fair, Playgrounds for iPad is brand new while Xcode has had playgrounds since Swift was released. Additionally, the Xcode feature has seen quite a lot of change in the last release or two of Xcode in effort to make it more capable.

The biggest issue here is really just lack of up to date tutorials from Apple.

If you can figure out how to wire up objects in the current version of Xcode and know whichever method of garbage collection they last settled on, you can still write a Mac app like it's 2003

I understand the disappointment, but this is a case of a bad template as opposed to building Windows apps being natively complicated. UWP is amazing - I haven't had the chance or bother to use it for anything particular, but if I was going to do anything for Windows that required a UI I'd definitely use UWP.

If anyone remembers the VS2012+ (I might have the time period wrong there) WIN32 default UI application, it's gigantic and the first few things you see are horrible practise. Global variable that has the root window's title, weird `InitInstance` function, use of the ATOM type (not actually used but present in the first few lines - why??? You didn't need to return anything from RegisterClassExW...).

Microsoft, or at least whoever they choose to make the example work for any SDK/API that they put out, is completely incompetent when it comes to understanding where someone who doesn't know what's going on is coming from.

UI is complicated and always has been. You have to be patient with it and give yourself time to absorb it.

Based on how you described things, you're just starting out with Windows UI and Visual Studio. That's OK, there's nothing wrong with that. Welcome.

The landscape is confusing for multiple reasons. Partly because now multiple platforms are now targetable. Partly because Microsoft bends over backward to support legacy codebases (yes, there are people still maintaining winforms apps). Partly because UI is just hard.

What you'll want to do is to find a stable but relatively modern UI library. You'll want something XAML-based, so that means WPF or WinUI. WPF is "done", terminally stable and there's a lot of resources (tools, tutorials, books) available for it and it works on Win 11. If you learn it, transitioning to the more modern WinUI is not a big deal.

Recommend you limit yourself to WPF or WinUI and Visual Studio. It should not take "a minute" to build an example application on a normal machine.

The initial confusion with xaml-based UI wears-off quickly. You will be able to make simple one-off UI's with ease. The hard part is building non-trivial applications with it because you will quickly find that you need to use libraries for MVVM and Dependency-Injection. I use the Prism library, it's a hot mess, but it's my preferred way of making UI apps.

The next major hurdle, for me at least, was customizing the UI controls. You can compose your own from the "built-in" controls and style them so they look pretty good (that's called a "User Control"). Anything more elaborate means buying UI controls from a vendor like Infragistics. You theoretically can create your own controls and package them in libraries, that's called "Custom Controls" and it's nightmarish in complexity if your end-goal is just creating applications.

WinForms is "legacy", WPF is the way to go.

3. I installed Visual Studio overnight (it comes with all the tools that building apps need). It downloaded 6GB of data and used 20GB of storage. All i want to build is a hello world app.

Bad choice not cherrypicking what you need and installing a whole lot of packages you don't.

Nah, a basic "hello world" WinForms program is minuscule. A WPF one might have a bit more dependencies, say a MVVM framework, but for a one-window program that's it.

6. I open the newly created app in Sublime Text (my editor) and I can't find a way to build the app anymore.

Not clear what you were trying to do here.

7. Because Visual Studio is so bloated, I download Visual Studio Code, which is far more simple but I can still not figure out how to build my app even with the various extensions VS code boasts.

It's bloated because of your choices. VS Code still compiles and runs .exe with attached .pdbs.

8. After hours of googling, I formulate a script that can build the app from the command-line.

You don't need to google for hours and formulate any script. I can run a basic program from VS Coe just fine.

9. But I stil don't know how to build the app as the .exe file created does not execute.

It's 100% on you.

10. I'm very disappointed.

It's 100% on you.

The reason I installed all those packages is because that's what the guide sid.

Visual Studio literally cripples my laptop and so I switched to subl to write my code there.

Btw how do I run the build results after "msbuild" builds.

"It's 100% on you."

No it's not. Microsoft's job here is to create tools, documentation and guides such that someone who wants to invest their time in learning their platform can get to "Hello world" quickly and in the right way.

Clearly they haven't done that here. OP was motivated to build something, and put their best effort into figuring out how to do so.

This is a usability thing: if someone makes a bunch of mistakes when using my software, it means I have failed to make my software usable enough for their purposes.

MS has the largest documentation on the internet. Look it up. It's OP's fault for being in a hurry.

> WinForms is "legacy", WPF is the way to go.

It’s not that simple. WPF has been mostly abandoned by the Windows team, while WinForms is owned by the .NET team and much better maintained. WPF will probably never be compatible with trimming and AOT compilation, WinForms will.

WinForms has its own issues, but there’s a reason why Scott Hunter recommended it over WPF at last year’s .NET Conf.

> WPF is the way to go.

Where is .NET MAUI in this conversation? I thought that was the GUI framework Microsoft was settling on / pushing most recently?

> Bad choice not cherrypicking what you need and installing a whole lot of packages you don't.

Another comment quoted a minimal .net building install at about half the size, which is still enormous.

Another option is to use an Electron boilerplate and then start learning a web framework of your choice. Electron development is incredibly rich. The UI is web tech, but that’s just the tip of the iceberg. There’s RPC back to a node process. You can call into native code on any platform. There are tons of NPM modules for both the browser and Node. There are bindings for whatever languages you want to use, and if you find yourself SOL (outta luck) you can even package “one file” python projects into a command line callable (via electron’s child exec) to work magic. It’s almost a limitless environment to build - I’m absolutely addicted because the puzzle solving is immensely gratifying.

For example, my electron app is used to design and print labels, and it integrates with excel and CSV. Mac users of Apple’s Numbers app have been SOL because the only way to export CSV data is using the UI (either manually or pseudo manually with AppleScript). When I wrote the app 3 years ago nothing existed to read .numbers files, let alone convert to CSV. Every holiday I get a flurry of emails from sad Numbers users because manually exporting is high friction. This morning I woke at 4am and thought I’d look again and huzzah! Someone published a Python project this year to read .numbers files. Awesome.

It took me about an hour to write a python script that accepted two arguments: the .numbers file and a destination .csv file. Then I spent 4 hours trying to package it up because damn if apple’s code signing isn’t a nightmare. But I digress.

I built a beta and now my poor users (wife included) can finally hit save in Numbers and boom, their labels immediately update with data. Very happy!

I know electron isn’t for everybody. I was (and still am) a mobile app dev writing native swift/kotlin. But I’m absolutely in love with JS/TS, warts and all!

My app is https://label.live and I’m always looking for interesting cross-platform app ideas, partners, etc.

Whatever you say about Microsoft and the amount of overlapping technologies they have, their documentation is best in class.

There's a barely supported, legacy API from Windows 2000 that is still used by some legacy screen readers to actually access whatever is on the screen. It's meticulously documented and the documentation seems maintained and up to date.

Apple is the exact opposite, the API that screen readers use to communicate with web browsers isn't even mentioned anywhere. If you ever need to learn about it, the usual answer is "go Read the Safari source code and figure things out from there." It's gotten so bad that the documentation for Dotnet bindings of some Swift methods has apparently gotten better than the documentation of those methods themselves.

> There's a barely supported, legacy API from Windows 2000 that is still used by some legacy screen readers to actually access whatever is on the screen.

Which API is that? I've been working on screen readers since Windows XP and am not sure I know which API you're talking about.

This one

https://docs.microsoft.com/en-us/windows-hardware/drivers/di...

You're not wrong. This is one of the reasons I've stayed far away from building Windows apps.

Right now I'm really into Golang, and I'm wondering if it's possible to build a Windows UI app using Go. I've always wanted to try QT, so maybe QT is an option?

I'll tell you one thing, building software that isn't trivial isn't easy. You are expecting it to be a turnkey solution on your first try. Honestly there are some turnkey solutions out there but you have to do your research and quit being so negative. You might as well accept that 95% of most modern software is "heavy" unless you are writing a C based command line app. About the lightest software (but hard to write) on Windows will be Win32 if you're looking to write Windows apps that are light on memory. Personally I think C# is probably the best all around place to get started on Windows for GUI coding. Python is probably the easiest for command line stuff.

Use PureBasic and build small, fast native GUI programs with no dependencies quickly. There is no dependency - it uses Win32 UI.

As an added bonus, you can compile your programs to run on Mac, x64 Linux, x86 Linux as well as Raspberry Pi.

The program is stable, and has a good community.

Interesting how nobody seems to have mentioned React Native here. Its Windows support is still rough round the edges in some situations (e.g. third-party library comparability) but the experience I’ve had so far using it to build a cross-platform app has been great. I’d imagine if you need to do more system-specific things e.g. the Windows task tray icon, you may still need to reach into the skeleton project and write some OS-specific code in C++, but the majority of the app I’m just writing in React, and there’s even a tailwind port for RN that worked out of the box. I also heard that Flutter upped their support for desktop a lot as well.

And by the way, I just realized that Windows 11 is going to support running Android apps https://blogs.windows.com/windows-insider/2021/10/20/introdu.... Of course it's not gonna suit every app (seems that OP requires a lot of performance in the app), but I'd imagine it would help ease development efforts a lot for a lot of apps that are not so demanding. Even if the phone layout will not be suitable, the tablet layout should be good enough in most use cases.

With Delphi (it has free hobby edition) and / or Lazarus one can build simple hello world literally in seconds. Same with QT (I do not use it as I am not fond of their licensing shenanigans). The rest of the discussion looks like people are trying to find the best way to hurt themselves.

One can easily build windows GUI "hello world" using notepad and mingw but anything more serious would throw one in a world of hurt. Win32 was designed to be wrapped into something more manageable, not used directly for large GUI apps.

I think that this might not be the comment that you are looking for but have you tried Visual Basic.net. C# has grown into a multi platform , multi runtime language that can be used to build apps on all version of Windows from 7 to 11, Linux and Mac OS. But if you still want to make apps that only run on Windows machines and uses still supported Windows Forms- then VB.Net might be just what you are looking for. It still ships with Visual Studio and let’s you build multi windows, database centric applications.

Use WinUI. The end.

That's what I tried.

>Why is building Windows apps so complicated

I suspect mostly because of their strong respect for backwards compatibility and interop between new stuff and old stuff.

Means there's always 10 ways to do the same thing.

Do yourself a favour and install Qt (it's free if you choose the LGPL version) and start building apps with QML / Qt Quick, which is Qt's language for UIs. As a Bonus: your app can also work on Android and iOS.

If you're more of the web developer type, just use Electron (your Hello world app will probably need several 100s of MBs of memory just to show a window but hey, that's what you get).

I feel you on the documentation point. WPF is great, but the documentations are scary. Microsoft's documentations are rich, but don't help in most cases. I'd been a professional WPF developer for a few years, but still couldn't get a lot of things.

Nowadays if I want to build a simple Windows compatible app for side projects, I use cross platform frameworks like Flutter.

Deepest reason — there is no incentive to make it simple, nobody is going to pay for that.

Even the opposite is true — the more complicated technology is — the more services around it you can sell.

K8s is another example of this pattern (i usually get a lot of dislikes for this statement, which ironically proves the point, because people usually react more to uncomfortable truth).

Complicated? It's the easiest thing in the world -- when compared to building an iOS, MacOS, or Linux GUI app.

You should use "Visual Studio"

https://www.codeguru.com/csharp/hello-world-c-sharp-windows-...

I don't have much to add. I went through a similar process about a year ago. It was painful and annoying and despite the fact that it was not what I wanted to do I ended up with an Electron app.

I'd also add that they're (Microsoft) also pushing .NET MAUI and Blazor for GUIs. They're very confused over there, IMO.

I see your .NET drama and up the ante by mentioning UWP / WinRT app development. You’re welcome!

My younger self would have asserted that Windows is a poison which gets re-absorbed into one’s skin by contact; my older self wonders how long the circus tent will stand aloft. There’s no P in PTSD until you’re outside the ecosystem.

https://github.com/migueldeicaza/gui.cs

"A toolkit for building console GUI apps for .NET, .NET Core, and Mono that works on Windows, the Mac, and Linux/Unix."

I'm going to try using this for a new console app

It has always been this way on this platform. Also not helping is that the documentation is of, let us say, varying levels of quality. I don't build GUIs that often, but have build them in the past, and, honestly, I am not entirely sure what I would use if I were to build one....

https://docs.microsoft.com/en-us/visualstudio/get-started/cs...

I take it you're leaning largely on this?

Is Win32 MFC still a thing? I remember wrestling with that 20+ years ago. It felt bloated back then but would probably be considered the equivalent of embedded programming nowadays. It was all C++ but not traditional C++ that you know. If felt like J++.

I still use it and frankly it’s pretty good. If you stick to using everything as it was intended, it’s fast and easy. When you have to go off the trails a bit, you are still in good shape because all the source for MFC is included so you can see how they did things. It’s a nice way to figure out how win32 works.

It really depends on your needs. For an old style desktop application (think file browser, text editor), it's ok. But for anything modern (touch screen support, animations) it just doesn't cut it anymore. You are better off with something like Flutter.

I disagree. You can access pretty much every API Microsoft has available when you are using C or C++. Touch screen support (large targets) isn’t an issue. Animations aren’t difficult either. XAML islands is an easy way of bringing in UWP and RT stuff into a traditional desktop application.

I’m not a fan of Flutter. Desktop Flutter applications use a lot more memory and CPU and don’t feel native on Windows.

There's so much proprietary code out there that's strongly coupled to MFG and BCG (https://bcgsoft.com/) that I doubt we'll live to see it disappear, just like Cobol...

Firefox is rejecting all the docs.microsoft.com links in this thread:

> An error occurred during a connection to docs.microsoft.com. The OCSP response does not include a status for the certificate being verified.

> Error code: MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING

I can recommend Qt https://www.qt.io/ . Not only is it a well designed C++ library, but it is also cross-platform. For creating Windows installers, I use NSIS.

The way I used to deal with Windows programming was to buy the Charles Petzold “Programming <X>“ book where <X> was the version of Windows I wanted to program for.

Petzold stopped writing these and so I stopped writing Windows programs.

I've had a lot of success using Lazarus https://www.lazarus-ide.org/ for some internal apps. Try it. It's like VB6 but in Pascal!

Windows 11 has great support for PWAs. This could be an option for certain types of apps, with the advantage, that it runs also on other platforms. MS Teams and VS Code are also web apps, so I guess the technology is ready?!

If I recall correctly, the steps would be:

1. Open Visual Studio.

2. Create a new Windows Forms app.

3. Drag a label onto the form.

4. Change its Text property to "Hello, World!".

5. Press Run.

From my experience, professional-looking Windows apps are easier for a solo dev to make than websites (HTML+CSS+JS+backend).

echo "Hello world" > index.html

Can be deployed anywhere, runs on every device. No need for a 20GB+ IDE + dependencies.

Sure, and this solution requires an entire browser instance merely to display "Hello world".

The 20GB of IDE dependencies are optional. However, the IDE certainly makes development uncomplicated (the subject of the OP).

> The worst of all is that there is not even one good guide on the whole clearnet on how to do develop a Hello World windows app from scratch.

If you bothered to use a search engine (google, bing), you’d find thousands of such guides.

Been doing this for ~ 1.5 decades with no issues:

1. build DLL in visual C that does whatever your business logic is.

2. build ui in visual basic by dragging around some controls and hooking them up to a few lines of code

3. tell VB to import your DLL

4. hook it up with a few more lines

Maybe you should switch to Lazarus. I've had quite a good experience building fast and small GUI applications in Lazarus.

Best of all, your program will be multiplatform (just recompile on supported platforms).

It isn't difficult. Just use Delphi. 26+ years of unbroken excellence building using Win32. And now Microsoft is saying that going forward they are back to promoting Win32 as the best way.

> 1. I wanted to build Windows 11 apps and I had to choose between Windows Forms, WinUI3, Win32 and WPF I think.

Aside, is there a term for this type of product bloat? "industrial ADHD"?

> choose between Windows Forms, WinUI3, Win32 and WPF

The focus now is on Electron web apps... it's harder and harder to find/write native apps. I guess you just confirmed this.

I had some exp building personal projects using QT. It's definitely a complicated GUI framework but it's not difficult to meddle amd create simple gui apps.

Qt is a big framework. But you can ignore 90%+ of it to start with. Just create a "hello word" app in QtCreator and then start adding some QWidget derived classes (QCheckBox, QComboBox etc). Make sure to read up on Signals and Slots.

Yeah, for small programs it's actually quite easy to put up something. It took me about a few days to learn some concepts but after that it's just plain coding to implement the features. Sadly I don't use QT for bread and butter so next time I will have to relearn the concepts...

When I'm writing simple things for Windows I just use Autohotkey. No hassles, portable, compiles to exe. Not for everyone but for me it makes windows usable.

Hence why all apps will be electron in <5 years.

While more resource heavy, with the transition to better ARM-based processors already underway this will become a mute point.

#1 is the #1 complaint. In 2021, I still don't know what Windows framework I should invest my time in if I want to develop a native Windows app.

Have you tried Fyne?

https://github.com/fyne-io/fyne

I'm currently using it for a project, but I wouldn't say it's ready for most applications yet. First, there is still no rich text editor. Second, the layout handling is overcomplicated and has the worst defaults I've ever experienced in any desktop application framework. I'm not sure the developers really have worked with convenient frameworks before. For example, there is no maximum size for controls, only a minimum size, and virtually all standard layouts create every embedded control with the smallest size possible. Not only that, the minimum sizes are unreasonable.

For example: Make a window with a vertical splitter, put some arbitrary textboxes in one half of it, and they will all have some arbitrary small minimum size. The rest of the split window remains empty. I know of no GUI framework with such an insane default positioning. Try to fix this problem with a "maximum layout" - It doesn't work! Either the controls are now overlapping (one of the rarest use cases ever), or the layout does not have any effect at all.

Another problem: On my Linux system, every third or fourth application start totally messes up the layout. Quit and start it again, and the layout is fine again. WTF?

In a nutshell, Fyne needs a bit more time to mature before it's a viable option for Go, but unfortunately it already suffers from few bad design choices regarding layout. It's also not a good idea to separate controls and layout. This may sound good on paper but in reality it just leads to tons of boilerplate code.

Yes, it sucks, but it's not much different from any other platform.

This is essentially why Electron has won, despite its obvious downsides.

BTW has anyone tried wxwidgets? I know older UnrealED (e.g. the one for Unreal Tournament 1) was written with it.

"Why is building Windows apps so complicated?" Compared to what? Web development?

Python lets you throw together a GUI pretty easily. I used it to build some simple wxWidgets applications when I was learning how to program.

Then trying to build a wxWidgets application in C++ isn't that much of a leap from that. Building it on linux is super easy. OP is right in that it is not obvious how to even start building on windows, at least if you want to know every command being run and do it all from the command line, instead of using the microsoft IDE. After downloading a ton of tools and looking through the IDE, it starts to feel like something is wrong if you just want to build "hello world" and were able to do it easily on linux.

Why would anyone want to build an windows app when there are so many better alternatives?

Lol, I actually think for building and distribution, it’s much easier to do so on Windows than it is on Linux, because of redistributables. On Linux you have to build on <insert ancient distro> and then build and bundle all other dependencies in order to guarantee it’ll actually work somewhere else.

Op never mentioned Linux as an alternative. The original post was not about a comparison.

Android development also sucks.

and i'm here working on a SwiftUI app and i am so happy

everything is smooth and efficient, code compiles to native machine code, there is no JIT or other weird shit that slow me down

windows is being run by incompetent junior students

leave that sinking ship

To be fair, I can create the exact rant on programming in Linux...

Use Delphi or Lazarus. Superlative windows development tool.

Aaaand that's why people use electron.

What is the point, just to complain?

Is this harder than Linux/Unix/Mac OS?

I don’t know what toolkit to use Qt, GTK2 GTK3? Ugh, I’m going to give up and complain on HN.

Just use Cocoa.

Oh boy, wait till you discover how hard is it to sign/distribute an app on Windows without triggering thousands of anti-virus programs

Just use QT instead,

A common mistake I see is to let the tools/frameworks make the decisions. The engineer should make the decisions. If the tools don't let the engineer do what he wants, he must change the tools.

Not sure how much experience you have with native development but, as a person who has production code running on windows, macos and linux, frankly I don't see much difference. Getting together almost all of the moving parts that make a modern OS tick behind simple API calls is no simple feat. Native development is complex because ... well it's a complex problem. Microsoft platforms have always been clunky so if you add that as well, it might seem unsurmountable if you don't know what you're looking for.

Linux is the most developer-friendly OS out there. What's nice, its GUI toolkits have the advantage of being cross-platform so if you learn how to use them, you can easily port your code to other platforms. For windows development I'd go with Qt or Gtk instead of full-on native nowadays. Qt takes you %95 of the way (Gtk a bit less) and for what's left you can drop to native code which wouldn't be too difficult.

However, for the sake of argument, let's try using the native apis.

Here's the checklist: Get a compiler, get an editor, write some code, generate build files, build, run, iterate.

1. Get a compiler. For windows, MSVC is the obvious choice. My MSVC provisioning script is 40 lines of powershell plus some json file I exported after doing the first manual install.

2. Get an editor. Notepad++ will let your feet get wet but for advanced stuff like completion and refactoring, get a real IDE like Qt Creator, Visual Studio or CLion. But for now, notepad++ it is.

3. Ok, time to write some code. I DuckDuck "windows gui hello world" and clicking around the first result lands me here: https://docs.microsoft.com/en-us/windows/win32/learnwin32/yo... so we have our hello world sample. Get the code from there and save it as main.cpp

4. Now let's compile the code. Running cl.exe by hand is doable but won't take you very far. We need a build configuration system. It looks like CMake and ninja is now bundled with Visual Studio so let's use them. I DuckDuck "cmake windows hello world" but don't get much and you turn to Google and you get these three lines:

    cmake_minimum_required(VERSION 2.4)
    project(hello_world)
    add_executable(app WIN32 main.cpp)

Good! now, launch a developer shell and do this:

    cd \path\to\my\code
    mkdir build
    cd build
    cmake ..

And when I type make ... wait what is this? What is a .sln file?? Visual Studio Solution?? Sorry cmake, that's not what I want, give me a proper Makefile. Or build.ninja.

Let's try again:

    cd ..
    rm -r build
    mkdir build
    cd build
    cmake .. -G Ninja
    ninja
    .\app.exe

Ah! That's more like it. And you take it from there.

Never let your tools dictate your actions. You're the engineer. The tools should do your bidding. As for the framework, just use Qt. If not, I think the latest fad is WinUI but Win32/MFC is here forever.

I actually put all this here along with my MSVC Provisioning script: https://github.com/plq/hello-win32

Hope it helps!

I’ve noticed that no one has attempted to answer OP’s question: “why is it so hard?”

If you were creating an OS and you wanted to ensure its success, one obvious thing to do would be to make it as frictionless as possible to develop native software. Ideally, it would be as easy as importing the system library and typing one or two lines to create a new windowed instance. It could be made so easy that amateurs with no understanding of programming could write their own little programs like many do with Excel.

Instead, Microsoft seems to go out of its way to make GUI development as nightmarishly complicated and intimidating as possible. It has expressed zero interest in streamlining the existing clusterfuck and instead piles on more layers and paradigms and libraries that are then poorly maintained and abandoned for other fads. Microsoft itself does not seem to have a canonical way of developing programs. Visual Studio is a monstrous behemoth that becomes more obese with every release—the last time I tried to install it, it temporarily bricked my laptop because of some memory corruption bug.

Everything Microsoft touches suffers the same pathologies—nothing they do is ever excellent. Their products just manage to chug along in spite of all their defects. No sane person would ever think to design things this way, but this is how they turn out. Even the tiniest and most obvious improvements, like the recent updates to Notepad, literally takes decades to implement. The bar is set lower and lower in terms of performance because improvements in hardware almost make up for the shittiness in software.

Microsoft suffers from a complete absence of vision and responsibility. Ultimately, no one there owns any project—there is no one to blame when it turns out shitty, and there is no visionary leadership to coordinate their efforts and pick a direction. It is just aimless bureaucratic chaos.

By the way, if you want a truly simple and fun experience making GUI apps, check out PureBASIC.

It's been a very long time indeed since I developed Windows-targeted software, but this rings true from what I remember. It always seemed to me that Microsoft wanted to give you just enough tools to imagine doing what you wanted to do, but not quite enough support to get it done - thereby encouraging the growth of a consultancy industry to get their feet into more corporate doors.

The tool dependency is a vendor lock-in strategy. "Just use the Microsoft tool" is always the answer. Weird.

In short, it's so hard because he doesn't have a clue what he's doing. He's just googling and doing whatever the first hit tells him.

You could have started with Winforms nearly 20 years ago and you'd still be fine. You could have started with WPF about 10 years ago and you'd still be fine.

Yes, MS tries a lot of new things, and a lot of them fail. But as for the things that don't fail out of the gate (Winforms, WPF, ...) you can stay relevant for literally decades.

I've installed every version of VS since VS6 without a problem. If you have memory corruption bugs, I'm quite convinced you have something else to blame.

Is it my problem that I don't know how to run msbuild? I mean you've been building windows apps for years so it's easy for you but how tf am I supposed to know that I can't use nothing else other than VS to build a hello world Windows app?

> Why is building Windows apps so complicated?

This is by design.

At the beginning PC's were not much different than Ataris or Commodore 64's, they still had built-in BASIC in the motherboard ROM so the OOBE was a ready-to-program personal computer for everyone.

Not that everyone actually wants to program their own computer, but there wasn't much software anyway and if you wanted to do something imaginative you were going to have to program it yourself.

And there was nothing standing in your way.

Once MSDOS prevailed and Microsoft got more powerful, BASIC was removed which "differentiated" these serious business machines from the lesser "gaming" computers.

PC's were so sophisticated they had so much more to offer than BASIC, and the few users who might want to code a bit would just have to jump through some of the same hoops as software companies, to select and prepare a special PC to be a Microsoft development environment.

Absolute total push in the opposite direction from free BASIC everywhere by default.

So from that point it was entirely intended to be the opposite of badda-bing-badda-boom.

BASIC was never removed from MSDOS. They continued shipping it with the OS at least until Windows 95 or 98.

Visual Basic.

https://docs.microsoft.com/en-us/visualstudio/ide/create-a-v...

There's a really simple solution. Don't develop for Windows. Literally, most UNIX systems were created with the intention of having the developer experience in the foreground! Just pick one and be happy :)

Building Windows apps is easy, but you need to use the right tools instead of the legacy Microsoft ones:

https://www.electronjs.org/docs/latest/tutorial/quick-start

Reply on news.ycombinator.com