• Dots, Crosses, and Looking at a Thing the Hard Way (part 1 of 2)
• Rotation Matrices and Looking at a Thing the Easy Way (part 2 of 2)
• SwapEditorShortcutsOnPlayerFocus for Unity

• Unity3D Category Posts – For all my Unity3D topics
• GameDev Category Posts – For all my general gamedev posts (includes Unity topics too)

If we interviewed a carpenter in the same way we interview software engineers these days, I imagine it would be something like this…

Blogging. Every so often I take up the torch. And every time I do, enough years pass in between that everything about the best way to blog changes. More or less.

First up, might as well make an effort to achieve high visibility – which means using WordPress to hook into all these “social media platforms” so that my blog post can be broadcast to as many bored eyeballs with active fingers as possible. The first item on that list, Facebook. Easy!

Wrong.

Facebook only lets WordPress post to Facebook Pages, which are basically facebook’s fancy new digital-age version of the classic local-governing registrar of “doing-business-as.” Fine. I created a page, and called it:

The Corporate Communist

Our Mission: develop a unifying theory of four of the greatest tools in humanity’s great sociopolitical experiment: Capitalism, Socialism, Oxymorons, and Alliterations.

The Corporate Communist

Awesome.

WordPress/FB still complains. Why? I can’t post to the Corporate Communist because the Page is marked as Private. Like, yeah. I might want to try this first — in private — before putting it out for all the world to see. Apparently FB doesn’t allow this. Clearly, Facebook isn’t too jazzed with the idea of WordPress using their platform to monetize WordPress users and the WordPress business ecosystem.

OK, Made it Public. Success. Extra Awesome.

Conclusion: WordPress is finally allowed to perform CTRL-C + CTRL-V on my behalf to Facebook. I think I will need to post at least 20 times for me to get a Return on Investment (ROI) on the time I sunk into creating this page vs. just manually pasting my blog URLs into my FB status. If the last five or so attempts at blogging are an indication of trend, I’ll not reach that ROI break-even point.

Next, I wanted to write a post to my new page, The Corporate Communist, from inside Facebook. Only because I thought it would be a nice baseline task, ahead of the (supposedly more complicated) process of WordPress posting on my behalf.

Wrong again.

Long story short, I still can’t figure out how to do it. There’s new facebook and classic facebook, and different instructions for both, and different UI depending on if I’m trying to post as the Corporate Communist to a friend’s feed, or trying to post as the Corporate Communist to the Corporate Communist page itself (the former is much more obvious than the latter).

Moving on, have WordPress post for me. And hopefully it works. And since I wasn’t afforded the basic option of verifying this privately, I feel like a speaker on a stage who gets up to the mic and taps…

Testing, testing 1..2..3…

An engineering choice made by Microsoft around the time of the release of Visual Studio 2015 was to explicitly require the Windows Platform SDK version to be specified by each and every C++ project. 
There is a reason for that choice, and it’s both rather lengthy and specifically to do with UWP. If you’re curious, read later in the entry.

The odd part is that there’s no default fallback setting. If your project doesn’t request a specific WindowsTargetPlatformVersion then it’s an msbuild error. There’s no built-in logic to fall back on whatever SDK the developer might have installed, and there’s no msbuild property that’s initialized with whatever SDK the developer might have installed. As a result, every project is forced to define this very specific
WindowsTargetPlatformVersion and any collaborating developer who attempts to build the project must have precisely that version Windows SDK installed. This causes a lot of unnecessary headache among developers since, as far as Windows Native application development is concerned, this very specific SDK version stuff just doesn’t matter.

Query the Registry!

I admit that I was never a fan of querying the registry from an msbuild project. In general I find the registry to be dangerous and often littered with bogus or out-dated entries (a side effect of it being an entirely separate entity from the programs themselves and also well-hidden from the user). But since Microsoft has neglected to provide us this information on their own, I’m left with little choice. So here’s what I came up with, which I save to a property sheet called SetWindowsTargetPlatformVersion.props:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
	<WinSdkRegistryVersion>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v10.0', 'ProductVersion', null, RegistryView.Registry32))</WinSdkRegistryVersion>
  </PropertyGroup>

  <PropertyGroup>
    <WindowsTargetPlatformVersion>$([MSBuild]::ValueOrDefault(`$(WindowsTargetPlatformVersion)`, `$(VC_WIN_SDK_VERSION)`))</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>$([MSBuild]::ValueOrDefault(`$(WindowsTargetPlatformVersion)`, `$(WinSdkRegistryVersion).0`))</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>$([MSBuild]::ValueOrDefault(`$(WindowsTargetPlatformVersion)`, `10.0.16299.0`))</WindowsTargetPlatformVersion>
  </PropertyGroup>
</Project>

This snippet is designed with two features in mind. First, the selection of Windows Platform SDK can be made via the environment variable VC_WIN_SDK_VERSION, giving the developer full control over SDK usage where required (also useful for automated build slaves/nodes). Second, the snippet provides a fail-safe in the event the registry key isn’t found for some reason, and falls back to a default SDK version. I arbitrarily picked 10.0.16299, the latest installed version at the time I wrote the snippet.

Alas there’s some bad news. This props sheet only works if you make sure to include it at a very specific place in your vcxproj project files. You cannot include it via the Visual Studio Properties Manager UI, because msbuild will throw it’s error long before those sheets are even included. You need to edit the vcxproj by hand and import SetWindowsTargetPlatformVersion.props before Microsoft.Cpp.Defaults.props is imported, like so:

This ensures that the WindowsTargetPlatformVersion property gets set long before msbuild tries to use it.

And in the end our goal is finally accomplished: Happy open source dev’ing of Windows Native applications with Visual Studio 2017.

Windows SDK is in the Registry32 Namespace

Curiosity killed the dev, and I dared to ask myself a question: What’s going on with the RegistryView.Registry32 part? The whole 32 or 64 bit registry thing is a throw-back to some seriously impressive hoops designed by Microsoft to allow 32 bit and 64 bit versions of the same application or shared library to be installed on a system and behave in an “expected” manner. The short of it is that an application’s registry key signature changes depending on if an application classifies itself as 32 bit or 64 bit. For legacy 32 bit apps this is fine. For the Windows Platform SDK — which is a set of libraries and tools targeting several platforms including 32 and 64 bit Windows — the idea that it’s classified as either 32 or 64 bit seems like nonsense. Microsoft has decided to classify it as a 32 bit application and, probably, it’s very safe to assume that won’t change.

Extra Reading: The Strictness of UWP, Imposed on All

So why did Microsoft decide to force the Windows Platform SDK Version on us in this manner? There is a reason for that choice, and it’s both rather lengthy and specifically to do with UWP. The change to require this setting coincided with the integration of the UWP SDK in or around Visual Studio 2015. The UWP SDK promises two things:

• a rapid update and release cycle
• strict version control checks at build and at runtime

By strict checks, I mean that a UWP app built against a newer SDK is blocked from being allowed to run on an older version of Windows. In practice this shows up in the Windows Store when you try to upgrade an application and then it tells you something along the lines of:

You must upgrade Windows to install this application.

That happens when the UWP SDK version used to build the app is newer than the version of Windows running on the computer. The rule of thumb goes that newer SDK typically has some new features and APIs that would result in runtime failures on an old operating system. Software built on older SDKs is allowed to run indefinitely on the premise that existing APIs retain compatibility. There’s also some package security and encryption benefits to this strict version check rule. None of this is unique to UWP. Android, iOS, Playstation, XBOX, etc. all have similar strict SDK versioning requirements.

The frustrating part comes from how Microsoft decided to impose that on everyone, all at once, and without some built-in means to manage it from a developer or build system administrator point-of-view. Windows Native application developers don’t need to care about this strict version specification, and build system admins typically want to specify these type of SDK things from build/CI interfaces and not via Visual Studio.

I came up with a tentative hack for allowing shebangs in .bat / .cmd files invoked from MSYS2.  The purpose of this hack is to allow running batch files directly from an MSYS2 / MinGW shell.  Normally that’s not permitted because the shebang syntax is invalid windows batch file syntax.  Here’s an example of how we would normally specify a shebang:

#! /bin/cmd

:: This is a batch file, with batch file looking things like this:

@echo off
SETLOCAL
echo Success!

On Linux/MSYS, the hash (#) is widely supported as a comment character.   But not so much on Windows.  Running this batch file from MSYS throws an error:

$ ./batch-test.bat
'#!' is not recognized as an internal or external command,
operable program or batch file.

As a workaround though we can create an empty file by the name of #!.bat:

$ touch #!.bat
$ ./batch-test.bat

C:\Projects\test>#! /bin/cmd
$

It should have printed Success!but all we got was this:

C:\Projects\test>#! /bin/cmd

… and right back to the prompt, with no errors or anything. What happened?  It goes back to stupid rules of Windows Batch files: When executing another batch file, you must use the CALL keyword to have control return to the initial batch file.  Let me re-iterate that in a bold quote box, only because it’s so surprisingly unexpected behavior by modern programming and software engineering standards:

When executing another batch file, you must use the CALL keyword to have control return to the initial batch file.  If you do not use the CALL keyword, then the current batch file is completely unloaded and replaced by the target batch file!

So in my specific case here, what happens is #!.bat is loaded and run (which does nothing), and then CMD.EXE says “job well done!” and exits without returning control to batch-test.bat.

We can’t prefix our shebang with CALL however, so the only solution left is to create a dummy #!.exe instead of a dummy #!.bat.   That will circumvent the silly CALL requirement.

But even then there’s a drawback: the syntax of the shebang must always contain a space between the ! and the / or else Windows will treat it like a directory path.  Meh.

So by this point the whole thing feels like way too much work.  Cleverness be damned, and time to move on to more practical problems with more practical solutions.

(the end)