I would also read "Windows Native Development" as driver development or compiling directly with `nmake` (neither of which are described there).

Windows SDKs, WDKs (driver dev), Visual Studio releases, and .NET SDKs all coexist peacefully on a machine. If a project build breaks due to newer SDKs, it's because it was configured with "use newest version". (Which is usually fine but sometimes requires pinning if you're using more "niche" things like WDK)

> You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.

You do because the downloaded ZIP contains an EXE, not a readable script, that then downloads the compiler. Even if you skip that thinking "I already have VS set up", the actual build line calls `cl` from a subdirectory.

I'm not going to reconstruct someone's build script. And that's just the basic example of a one file hello world, a real project would call `cl` several times, then `link`, etc.

Just supplying a SLN + VCXPROJ is good enough. The blog post's entire problem is also solved by the .vsconfig[1] file that outlines requirements. Or you can opt for CMake. Both of these alternatives use a build system I can trust over randomgithubproject.exe, along with a text-readable build/project file I can parse myself to verify I can trust it.

1: https://learn.microsoft.com/en-us/visualstudio/install/impor...

If you haven't already, you can ask Google for a refund on that (the second, recent) in-app purchase:

https://support.google.com/googleplay/answer/15574897?hl=en

The policies are "up to 48 hrs after purchase" but I'm sure "purchase does not work at all" is an exception. (It is on iOS)

It could also just pretend to encrypt your drive with a null key and not do anything, either.

You need some implicit trust in a system to use it. And at worst, you can probably reverse engineer the (unencrypted) BitLocker metadata that preboot authentication reads.