PATH

While there are some noticeable differences in the runtime behaviour of MSYS’s tools they are close enough to a familiar environment that existing scripting shouldn’t need much attention.

However the PATH environment variable did trip me up a few times. One quick method of addressing the MSYS tools is to prepend/append the MSYS paths to the system or user PATH. Unfortunately in my case CLion requires 'MinGW Makefiles' which result in hard errors when sh is in your path. The workaround for this was to point CMAKE_PREFIX_PATH at the MSYS tools for Windows targets rather than modify the system PATH.

Be careful that your PATH refers to the correct tool for your architecture. pkg-config in particular may appear to operate correctly but search only for 32 bit libraries if you have installed versions of the tool for multiple architectures.

sh

Shell scripts may more effort to support under Windows than is warranted. A shell may not be present and differences in filesystem behaviours can rapidly trip up some tools (with file locking being the most common culprit).

Given I already use Python as a hard dependency in other locations of Edict I finished the incremental transition from Shell to Python that had already started.

Vulkan

While I don’t currently use Vulkan nerdcruft has a set of independent C++ bindings and a library/layer loader created over the course of some experiments last year. I spend a small period porting this library until sufficient complexities emerged that it wasn’t worth the investment for this project.

Enumeration of platforms under Windows felt unjustifiably complex. Under Linux (and presumably other POSIX systems) we scan a hardcoded set of locations for JSON configuration files. Under Windows we scan PnP registry keys for values that point to the actual configuration files. Perhaps my distaste for this approach comes from my disdain for the Windows registry (and associated lack of support in my platform libraries).

Coupled with the various platform issues outlined above it wasn’t worth the time investment for this project. Some improvements are being made over weekends, but it’s unclear when I’ll get to finishing this proper.

Win32

The Windows platform APIs are totally different to every other platform I intend to support.

There are some components which almost necessarily need to be written for each platform, e.g. `How do we query the current application’s path?'

Others are similar across POSIX but different under Windows, e.g. `How do we memory map a file?' Thankfully most of these concerns fall neatly into some form of abstraction we already provide.

IO

Path differences, binary IO, and file locking were unreasonably annoying. A good number of differences in configuration and build differences come down to either:

More insidious is the need to opt in to binary IO (i.e. decline the transformation of newlines). While the above problems tend to result in hard build or runtime errors, forgetting to set O_BINARY on one occasion may result in data corruption which might only be detected much further along in the pipeline.

My current approach is to introduce an assertion that binary mode has been selected in all IO wrapper objects. While this complicates any hypothetical support requirement for Windows line endings I’m not convinced that enabling this behaviour will ever be a valid use case for my projects.

And lastly, the default behaviour to lock access to files differences substantially from the UNIX model (where files can be readily moved and deleted at any point after their creation irrespective of open file handles). It’s possible to work around this behaviour in my own code, but more troublesome is the behaviour of external tooling; we can’t change, for example, the locking mode of Python’s tempfile module despite how thoroughly it broke the assumptions of some of my unit tests.

Symbol renaming

There appears to a tendency for developers to know what symbol names I desire and define them with macros deep inside some critical Windows header, e.g. NEAR and FAR for pointers vs clipping planes, and OPAQUE for blending. This can result in some bugs that are difficult to track down or necessitate a great deal of renaming within your own projects. Given I have a hard enough time remembering many enumeration names without going to my second choice name I opted for a third approach: nuke their macro and replace it with my own.

Yes, it’s incredibly dangerous; not because of symbols redefinitions, but the chance of silently using invalid values. This is mitigated somewhat by consistent use of strong typing in these definitions such that there’s a limited risk of inadvertent casting to a common type (like int), and the Windows specifics tend to be very tightly controlled and auditable.

Multithreading

I’ve created a few special purpose threading primitives outside those of the standard libraries. Some of these can be efficiently implemented using standard library primitives (e.g. ticketlock uses std::atomic), others may be implemented less efficiently in terms of standard library primitives or by using system primitives (e.g. semaphores using std::condition_variable and std::atomic);

This would have been incredibly simple if there was no need to support Windows 7 as future iterations provide WaitOnAddress which is a superset of the futex functionality these primitives are implemented with under Linux. Unfortunately it’s a hard call to drop Windows 7 support and so we need to resort to constructing these structures from older Win32 APIs.

Having written a few iterations of this functionality over the years it wasn’t terrifically time consuming but it does require a fair amount of concentration for the duration.

CL/GL

Our OpenGL and, to a lesser extent, OpenCL binding generator needed a variety of small improvements.

Some amount of the generated code was hacked together under the assumption that the required platform was GLX; statically specified headers, some type overrides, and functionality to select the desired platform (GLX/WGL/etc) needed to be modified. Now we have the ability to select the platform provider for OpenGL and Vulkan (as the binding generator is largely a shared codebase for the Khronos APIs).

The primary complication of platform selection under Windows has been avoiding symbol clashes. The Windows headers include definitions for OpenGL functions under GDI which tend to be included frequently enough that clashes can’t be avoided. The simplest solution to this is namespacing all generated OpenGL functions. But it does have the drawback that it’s quite possible to accidentally reference the Windows symbols rather than our own.

To mitigate this problem I’ve imposed a strict requirement to never refer to any header that we wrap outside of one canonical wrapper header; i.e. if we want OpenGL functions we include <cruft/gl/gl.hpp> rather than <GL/gl.h>. This allows us to contain any platform specific mitigations or hacks in the one place.