Ask HN: Can anyone recommend a Windows Systems programming book? There's a hundred of these and I want something well-written. I'm primarily using Nim but a C/C++ book wouldn't hurt. Ideally it would have lots of exercises. |
Ask HN: Can anyone recommend a Windows Systems programming book? There's a hundred of these and I want something well-written. I'm primarily using Nim but a C/C++ book wouldn't hurt. Ideally it would have lots of exercises. |
https://learn.microsoft.com/en-us/windows/apps/
https://learn.microsoft.com/en-us/windows/apps/get-started/s...
https://learn.microsoft.com/en-us/windows/win32/api/
It covers near everything, is extremely exhaustive, and constantly updated. That being said, if you're more interested in how the Windows API is organized/works internally (why you have to give it handles/resources and what those mean, for instance), then Charles Petzold's series is generally considered the definitive resource:
Most of the old APIs still work exactly the same so I am frequently tempted to look stuff up in my VS6 install just because it's so fast and convenient.
MSDN_Library_October_2001 is the latest one they mailed out for Visual Studio 6.
https://www.pcworld.com/article/917478/microsofts-biggest-so...
For example, most of the authors of the old-time classics were not employed by Microsoft when they wrote their books. I think Charles Petzold (Windows Programming) was a freelancer, Jeffrey Richter (MFC) was working a company called Wintellect, David Solomon (Inside Windows NT) had a seminar company (Solsem), I think initially primarily for VMS and Mark Russinovich (Inside Windows 2000) at Winternals Softwre.
Usually its 1 year and 15 upgrades outdated.
Its basically why I have completely given up on Microsoft. Every update is a breaking change that isnt updated in their docs. And chances are, it wasnt going to work anyway.
Any time you have to use a microsoft service/product, know that documentation is just going to be worse than any FOSS made by teens.
You can find full tutorials and documentation on the entirety of WinUI3, which is the literal bleeding edge; for instance.
https://learn.microsoft.com/en-us/sysinternals/resources/win...
But you have to be aware the part 1 is now a bit dated, the 7th edition is from 2017. The part 2 is from 2021. It’s not a big deal but some references are a bit outdated and some modern stuff is missing, but nothing that will be a blocker.
The books aren’t focused on programming though, but they explains the security, threading model, etc. Really interesting reads.
I comment it often but something great with windows API is that you can still use all the Win32 APIs, almost all old examples you can find on MSDN are still relevant to this day. The only thing you need to get started is a way to interact with C, and learn windows conventions (parameter names are weird at first but make sense, the error handling can also be confusing at first, the process model is a bit strange at first if you come from Unix, etc)
A lot of useful links on that page for additional reading.
Repo for the tools used in the book https://github.com/zodiacon/WindowsInternals which are invaluable
Windows Internals is a really good source for deep understanding of the OS.
Example, the new MIDI subsystem, https://github.com/microsoft/midi
Windows Internals is a great book/reference for understanding how Windows work, but it won't teach you how to actually program Windows.
The Fifth Edition of Petzold's book will actually take you through the Win32 API, which is still usable even on modern Windows platforms.
Programming Windows covers systems programming in C and in later editions, in C#.
Inside Windows goes over the Window OS architecture in-depth. There’s not much programming in the book but you will come away with a deep understanding of the OS.
Both books are published by Microsoft Press. You’ll of course want the latest editions but if you come across earlier editions, those are fine too.
I’m partial to the earlier Petzold editions of Programming Windows.
The technical docs at microsoft.com are also super helpful and up-to-date: https://learn.microsoft.com/en-us/docs/
[1]:https://learn.microsoft.com/en-us/sysinternals/resources/win... [2]: https://www.amazon.com/Windows-Kernel-Programming-Pavel-Yosi...
Richter also wrote "Windows via C/C++", which was previously titled "Programming Applications for Windows 2000" (4th edition) or "Advanced Windows" (3rd and earlier editions).
I realise these books are now very old (17 years old for "Windows via C/C++" and 25 years for "Programming Server-Side Applications") but really, the Windows API hasn't changed all that much in that time.
Then depending on which area of Windows you want to focus on, there are plenty of Microsoft Press books.
Windows is not open source, so unless you work for Microsoft, you won’t really be doing much “real” systems programming probably.
Do you want to program applications? Windows services? Device drivers?
What would you consider systems programming on Windows for example?
I know nothing about windows internals, but I’m curious
In Linux, configuration is done via plain text files. In Windows, there is the registry.
In Linux, there is the root filesystem, where everything else is mounted beneath. In Windows, there is C: and more.
In Linux, the native string encoding is UTF-8 code units stored in char of one byte size. In Windows, the native string encoding is UTF-16, stored in wchar_t of two bytes size.
In Linux, there is fork. In Windows, there is no fork.
In Linux, there is no unified graphics API. There is GTK and Qt for UI, and OpenGL and Vulkan for games (roughly speaking). On Windows, there is Win32, WinForms, WPF, WinUI, DirectX and also OpenGL and Vulkan.
A handle to an object. I think that is the main difference that is also visible in tools like PowerShell (as compared to the UNIX shell).
Linux is very free form, Windows is much more structured and strongly typed.
Also The Windows API pattern is typically:
1. Initialize a "descriptor" struct
2. Pass that descriptor struct by reference to a "create" function
3. Get ComPtr<> for resource
Where a ComPtr<> is a smart pointer that manages the lifecycle of an object across different processes
Also Windows built UTF-16 support into their APIs 30 years ago, so a lot of API calls involve constructing UTF-16 literals
Or to put it another way, picking languages takes exploration of Windows system programing from an X problem to an XY problem. Good luck.
For related examples, you can learn Ruby just by learning Rails. Or in more general aspect, the web technology stack through a modern web framework.
Though I believe it has regressed at least a bit with the introduction of DotNet Core.
Maybe it is actually better for OP to learn .net, maybe not. But the answer had quality, so I do not think the downvotes are appropriate.
The OP is coming all the way from Nim into two decades of .Net as Windows “easy mode.” There are important reasons to use cpp, but most of the reasons in the world of Windows are .Net.
SharePoint, Exchange Online, Azure, it's all bound together by a string with APIs that can barely speak the same language.
(Disclaimer: I speak for myself, based on my memory of public knowledge.)
PowerShell is .NET and operates a few more abstraction layers above the Win32 API.
On the other hand, HWNDs are global (at least within a window station, I don’t know how that works). If you display the numeric value of a HWND in a message box in program A and type it by hand into program B, program B can (usually) pass it to PostMessage and successfully reach program A. I don’t know if other USER and GDI “handles” (e.g. HMENU, HRC) are like that, but I wouldn’t be surprised if they are.
I also think defining STRICT before windows.h will still prevent you from passing a HANDLE where an HWND is needed, even though the last (also the first and the only) time Microsoft promoted this feature was in the Win16-to-Win32 migration docs in the early 90s. A HANDLE to a file vs a HANDLE to a named pipe or even a mutex is another matter—those are all genuine NT objects, and handles to them are to an extent all the same kind of thing.
I'm literally writing this to you on a Laptop exclusively running Fedora Linux. I do most of my development in OSS tools. I'm not some fanboy, yet despite that (or maybe due to that) I'm still able to recognize the very obvious fact that Microsoft has very robust documentation.
What's more, it's a step back from how well Microsoft did it in the past.
It's essentially like stepping into half-done move between two different places, and never being able to tell where did you put what.
They can, and in the past did, do better.
There's something interesting about that; it implies that grey text signifies a non-conformist view and approach to a technical issue. As is the case here.
I like to skip to the grey text.
By contrast, it also prevents users from commenting. See dang's posts on this.
Regardless, it's interesting to note that it also, indirectly, highlights interesting comments.
Do you also find that interesting?
The complaint is that now it often ends up disjointed, especially when you're starting to search for a topic, and the links pointing you to "new site because this one no longer updated" don't point to the same topic (or area) on the new site.
Also, I have absolutely no idea where you come from with fanboyism or Microsoft hate as context in previous comment.
Thinking about it, downvoting for disagreement is the analog of upvoting for agreement.
But my point isn't to criticize anyone for downvoting. Just the opposite. It's to illustrate that thinking outside the box is in itself disagreeable, which, as is the case here, can be a searchable metric.
I am not contrarian in the sense that I think good comments are downvoted to a meaningful extent. YMMV.