May Contain Code

A common issue I see in platform abstraction libraries is complete ignorance of fundamental incompatibilities between platforms. Let's look at an example case study: the arguments to the main function in C and C++. For starters, what text encoding do they use? Do you know off the top of your head? Better yet, where do they even come from? What is the purpose and source of the provided arguments? Do they come from a user? From the operating system? From a mix of the two? Do you really know what a locale is? Perhaps you think you know all these answers. There was once a time where I thought I did. Can you really be confident in your answers to these questions when you consider all platforms you hope to develop for? Consider this: on desktop operating systems, program arguments are often used for passing filesystem paths. The NTFS filesystem used by Windows stores file and directory names as arbitrary sequences of 16-bit numbers. Aside from a few banned numbers and sequences with sp

I've been using my Windows DevKit 2023 a lot over the past years since it has good performance for software development and doesn't make my room hot like my traditional desktop PC. Inside it is a Microsoft SQ3 processor based on the Qualcomm Snapdragon 8cx Gen 3, making this a Windows on ARM device. It shipped with Windows 11, which was annoying until they finally added back the ability to get window titles on the taskbar, though it took them a long time to work out the bugs with that. Unfortunately, today's post is mainly about issues specific to this device, rather than to Windows 11 in general. I typically use the maximum supported number of displays: 3. Up to two displays can be 4k, but I only have one 4k display. I basically just re-use my existing 4 display setup for my x86 desktop which arranges the displays in a 2x2 grid (4k display is bottom right, primary display is bottom left, extra displays are above), using the extra monitor inputs and excluding the top right