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.
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`
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.
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.
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.
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.
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.
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)
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...
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.
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)
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.
0: https://www.wikihow.com/Create-Your-First-Qt-Program-on-Ubun...
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.
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".
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.
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...
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.
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).
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.
- WPF with NET 6
- Electron
- WinUI
- Flutter
- That GUI programming is complicated
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.
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.
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.
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.
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?
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.
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.
Don't listen to whatever the Microsoft marketing department is hyping.
Compared to what? GUI programming has always been hard on all platforms I tried.
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.
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.
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).
@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
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.
"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.
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/
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.
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!
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.
It was a nightmare to figure out how to do it, though.
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...
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.
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.
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.
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).
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.
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.
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.
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?
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.
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 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.
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).
Nowadays if I want to build a simple Windows compatible app for side projects, I use cross platform frameworks like Flutter.
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).
You should use "Visual Studio"
https://www.codeguru.com/csharp/hello-world-c-sharp-windows-...
I'd also add that they're (Microsoft) also pushing .NET MAUI and Blazor for GUIs. They're very confused over there, IMO.
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.
"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
I take it you're leaning largely on this?
> 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
Petzold stopped writing these and so I stopped writing Windows programs.
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).
If you bothered to use a search engine (google, bing), you’d find thousands of such guides.
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
Best of all, your program will be multiplatform (just recompile on supported platforms).
Aside, is there a term for this type of product bloat? "industrial ADHD"?
The focus now is on Electron web apps... it's harder and harder to find/write native apps. I guess you just confirmed this.
While more resource heavy, with the transition to better ARM-based processors already underway this will become a mute point.
This is essentially why Electron has won, despite its obvious downsides.
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
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.
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)
cd \path\to\my\code
mkdir build
cd build
cmake ..
Let's try again:
cd ..
rm -r build
mkdir build
cd build
cmake .. -G Ninja
ninja
.\app.exe
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!
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.