What is the best way to learn to write programs for Windows? For example, let's say 'I want to disable taskbar tab grouping programmatically', how would I know where to look?
The quickest "I want to write an application" is probably C#, and then good old Windows Forms on top of that for UI. (Many more modern options exist with various drawbacks).
C# has an excellent system for native interop ("P/Invoke") if you need to write a program that calls a couple of native functions that aren't available as nuget packages.
> disable taskbar tab grouping programmatically
.. fiddling with windows settings, on the other hand, is kind of a nightmare. Either you identify the registry key or you have to go hunting in an endless maze of APIs.
> What is the best way to learn to write programs for Windows?
There are many ways to program Windows.
If you want C or C++, you can use Win32[0] and COM[1]. Of course, the C and C++ standard libraries are also available, within ucrt.dll[2]. Not to mention additional libraries/frameworks like Direct3D, OpenGL, DirectSound, etc.
For .NET, there's several options:
- Windows Forms[3]
- Windows Presentation Foundation (WPF)[4]
- WinUI 3[5] (most recent, but lacking some features)
Windows' command-line shell of choice is PowerShell[6], written in C#. There are two flavours, Windows PowerShell 5.1 (Windows-only, uses .NET Framework 4.8), and PowerShell Core (cross-platform, uses .NET 6+).
> For example, let's say 'I want to disable taskbar tab grouping programmatically', how would I know where to look?
There are registry keys and GPO policies[7] (you can use any of the above C/C++/C# APIs to read/write from the registry, but your program will need the appropriate permissions)> However, Windows really is best configured with the GUI (Settings app -> Personalisation -> Taskbar).
Actually, Windows development has moved on since the Win32/.NET days.
A "modern" Windows app can use WinRT, which is a reasonably clean OOP API, from multiple languages including C++. The API is based around coroutines and async/await for concurrency and you can do a lot without ever touching Win32, e.g. there are HTTP clients, file APIs etc all of which are not Win32 and also don't require .NET. Under the hood it's all COM based stuff but you aren't really exposed to that.
No, you can use it in any app including "normal" Win32 apps. I've done it, it works. You can think of it as a plain upgrade over Win32.
The reason you think that is that once, it was indeed the API of UWP apps and those had various constraints as Microsoft tried to Apple-ify the platform. But they gave up on that a long time ago and got far more relaxed. Now you can mix and match old/new tech. You can ship Win32 apps in the app store, Win32 apps using MSIX, WinRT code using custom installers etc (the "sideloading" toggle switch went away a while ago for up to date Windows 10 machines, it still exists in Windows Server which is a fork of an ancient Win10 branch).
Caveat: some WinRT APIs want you to have "package identity", which (I think??) requires MSIX. This is not different to macOS though, where some APIs require you to have a bundle ID and be code signed. The OS wants to be able to have some stable identifier for an "app" which is allowed to change arbitrarily between versions. On macOS that identity is plumbed through Apple's in-house certificate authority through to a CMS signed CodeDirectory structure in the MachO headers. On Windows it's in some ways a bit simpler, in other ways, more complex - it comes from a combination of your code signing certificate and your package ID. There is an API and cmdlet for granting an app package identity without it being installed via MSIX but for some reason it's limited to developer mode. My guess is that MS will give up on that at some point and let old-style Win32 installers grant package identity too. The MS approach is there for a reason though, because the files installed via MSIX are "tamper-proofed" which prevents other apps from overwriting them. So, establishing the identity of an app installed this way is extremely fast and there's no way to hijack another app's identity by fiddling with its data files. If you look at how macOS does it, it's kind of painted itself into a performance corner by lacking this, the requirements on apps w.r.t. loading data files is very unclear, and they're still changing how they enforce code immutability even in Ventura as a consequence.
Ewwww, metro apps. Please don't make any more of those! Use Electron instead: it's faster, cross-platform, and has better dev tools. (Yes, I am saying Electron is better than something else)
That's a user setting, if you change that from your program Raymond will get mad at you.
But yes, it's a registry key. It will be a bit hard to make explorer.exe reread that registry key without restarting it, though, since it probably reads the key on startup and caches it.
