This article was discussed on Hacker News.

Years ago, OpenBSD gained two new security system calls, pledge(2) (originally tame(2)) and unveil. In both, an application surrenders capabilities at run-time. The idea is to perform initialization like usual, then drop capabilities before handling untrusted input, limiting unwanted side effects. This feature is applicable even where type safety isn’t an issue, such as Python, where a program might still get tricked into accessing sensitive files or making network connections when it shouldn’t. So how can a Python program access these system calls?

As discussed previously, it’s quite easy to access C APIs from Python through its ctypes package, and this is no exception. In this article I show how to do it. Here’s the full source if you want to dive in: openbsd.py.

My friend over at Possibly Wrong created a code name generator. By coincidence I happened to be thinking about code names myself while recently replaying XCOM: Enemy Within (2012/2013). The game generates a random code name for each mission, and I wondered how often it repeats. The UFOpaedia page on the topic gives the word lists: 53 adjectives and 76 nouns, for a total of 4028 possible code names. A typical game has around 60 missions, and if code names are generated naively on the fly, then per the birthday paradox around half of all games will see a repeated mission code name! Fortunately this is easy to avoid, and the particular configuration here lends itself to an interesting implementation.

I like to test my software across different environments, on strange platforms, and with alternative implementations. Each has its own quirks and oddities that can shake bugs out earlier. C is particularly good at this since it has such a wide selection of compilers and runs on everything. For instance I count at least 7 distinct C compilers in Debian alone. One advantage of writing portable software is access to a broader testing environment, and it’s one reason I prefer to target standards rather than specific platforms.

However, I’ve long struggled with architecture diversity. My work and testing has been almost entirely on x86, with ARM as a distant second (Raspberry Pi and friends). Big endian hosts are particularly rare. However, I recently learned a trick for quickly and conveniently accessing many different architectures without even leaving my laptop: QEMU User Emulation. Debian and its derivatives support this very well and require almost no setup or configuration.

The C strcpy function is a common sight in typical C programs. It’s also a source of buffer overflow defects, so linters and code reviewers commonly recommend alternatives such as strncpy (difficult to use correctly; mismatched semantics), strlcpy (non-standard), or C11’s optional strcpy_s (no correct or practical implementations). Besides their individual shortcomings, these answers are incorrect. strcpy and friends are, at best, incredibly niche, and the correct replacement is memcpy.

My previous article explained how to work with dynamic-link libraries (DLLs) using w64devkit. These techniques also apply to other circumstances, including with languages and ecosystems outside of C and C++. In particular, w64devkit is a great complement to Go and reliably fullfills all the needs of cgo — Go’s C interop — and can even bootstrap Go itself. As before, this article is in large part an exercise in capturing practical information I’ve picked up over time.

I’ve recently been involved with a couple of discussions about Windows’ dynamic linking. One was Joe Nelson in considering how to make libderp accessible on Windows, and the other was about w64devkit, my Mingw-w64 distribution. I use these techniques so infrequently that I need to figure it all out again each time I need it. Unfortunately there’s a whole lot of outdated and incorrect information online which gets in the way every time this happens. While it’s all fresh in my head, I will now document what I know works.

It’s been about a decade since I last worked in Java and much has changed. I thought I’d brush up by re-reading Effective Java by Joshua Bloch which has since received a new edition. It was once my guiding star for Java. However, after an additional decade of experience in a variety of languages and platforms, this book frequently made me shake my head. I strongly disagreed with 20% of its items. One conflicting topic was enumerations, particularly item 36: “Use EnumSet instead of bit fields.”

“Call it,” Kelsey said, tossing a quarter. Her command was ritual, meaningless, though not only because I always chose heads, but because it was a false choice. My decision wouldn’t affect the odds. She established this ceremony years ago when our work lunches became routine. Winner pays for lunch. We were software engineers at Fastr, a tech startup involved in the burgeoning domain of high-frequency trading, so her idea of a simple, stateless solution to splitting the bill naturally appealed to us both. We didn’t have to remember who paid last, and the law of large numbers meant it would only become more fair the more we had lunch together.

There’s a trend of building services where a monolithic application is better suited, or using JavaScript and Python then being stumped by their troublesome deployment story. This leads to solutions like bundling an entire web browser with an application, or using containers to circumscribe a sprawling dependency tree made of mystery meat.

My small development distribution for Windows, w64devkit, is my own little way of pushing back against this trend where it affects me most. Following in the footsteps of projects like Handmade Hero and Making a Video Game from Scratch, this is my guide to no-nonsense software development using my development kit. It’s an overview of the tooling and development workflow, and I’ve tried not to assume too much knowledge of the reader. Being a guide rather than manual, it is incomplete on its own, and I link to substantial external resources to fill in the gaps. The guide is capped with a small game I wrote entirely using my development kit, serving as a demonstration of what sorts of things are not only possible, but quite reasonably attainable.

Since its inception I’ve faced a dilemma with w64devkit, my all-in-one Mingw-w64 toolchain and development environment distribution for Windows. A major goal of the project is no installation: unzip anywhere and it’s ready to go as-is. However, full functionality requires alias commands, particularly for BusyBox applets, and the usual solutions are neither available nor viable. It seemed that an installer was needed to assemble this last puzzle piece. This past weekend I finally discovered a tidy and complete solution that solves this problem for good.