Context: So I wanted to implement drag and drop with files the quick and dirty way; specifically, WM_DROPFILES. (You can also do this with COM, but it’s a bit more involved, especially from raw C. I haven’t written about drag and drop yet, so the comparison is covered elsewhere for now.) My use case is simple, so I didn’t need the benefits or complexity of COM drag and drop. Turns out it’s just marking it as having the extended style in the resource editor or calling DragAcceptFiles, or so I thought. While I could get my dialog to accept the files, I couldn’t get the list view to do so. It turns out that the list view doesn’t handle these messages, nor does it send a notification back to the parent.
One strategy to deal with this is subclassing, although we aren’t going through the formal channels to do. That’s trickier, because it involves using things like CreateWindowEx, and might be a pain with dialog resources that already have a list view. Instead, we’ll actually replace the window procedure out from under the already materialized dialog control – basically monkey patching. In fact, Microsoft’s own documentation mentions this (and a better way with caveats). However, it doesn’t provide a concrete example. This article will quickly show you how, and provides an interesting, if brief example of Windows API principles.
If you need the icons for files in a Windows program, the easiest way to do so is with the system image list. This is an image list (a resource containing icons, mapped by index) that caches those system icons. The advantage of being an image list is you can easily associate it with a control (like a ListView) and pick out the images by their index, or draw out of it.
Short post: On Windows, UTF-16 was the dominant locale, and UTF-8 was something only to convert to and from. (Microsoft jumped the gun before Unicode expanded the address space.) While it got better (Windows 10 can use UTF-8 as an MBCS locale with ANSI APIs), it was historically a lot worse.
For converting, you’d use the MultiByteToWideChar and its opposite WideCharToMultiByte. On legacy Windows, they have slightly confusing semantics. Specifically, with flags. While Vista on introduced many flags that can be used with the UTF-8 codepage (to deal with the quirks of conversion, like invalid characters), previously only MB_ERR_INVALID_CHARS was allowed, and only if you were running XP or 2000 SP4. Before that, you can’t have any flags if you’re converting to or from UTF-16 and UTF-8. It’s unfortunately a little dangerous, but that’s the rub.
I had a simple Win32 application fail to create its window (in my case, a dialog box, using either CreateDialog or DialogBox). I got back the error 0x583; unable to create window class. If I forced the window style on my dialog to create regardless of errors, my dialog was empty.
It turns out I was using themed controls in my manifest, but I didn’t call InitCommonControls. After that, my application worked.
If your Win32 application needs to declare that is supports something before it even executes, this is where a manifest file comes in. While you can ship one with your application (in the form of appname.exe.manifest), it’s more fool-proof to just embed it into your application. You can do so with
It’s because Visual Studio seems to copy an x86 version of the VC++ runtime into system32 on ARM64 systems. That’ll make it crash with a bad image format error. If you copy the ARM64 version of vcruntime140.dll (for me, found in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.28.29325\arm64\Microsoft.VC142.CRT) into the build directory, binaries will work.
QEMU recently gained Apple Silicon hypervisor support. That was pretty damn cool for the first few weeks of M1 in people’s hands. Even without any optimizations, Windows 10 on M1 outclasses the Surface Pro X and even my Ryzen gaming desktop. Unfortunately, that didn’t include 3D acceleration (though virtio-gpu is now a thing for 2D).
Luckily, Parallels has ported their virtualization software to M1. It’s incredibly janky (and certainly deserving of a technical preview because of that!), but shows a lot of promise, complete with D3D11 support for games. Unfortunately, it requires some hacks to get running stable, but it’ll work fine after that.
I tend not to like cross-compiling, but sometimes it’s just the simplest solution, particularly if Windows and autotools come into the mix. Recently, I wanted to build xz for Windows, and build it in some particular ways.
windres (the GNU Windows resource compiler) will eat CPPFLAGS, but it won’t process most of them the same way. I often like to use it as a shorthand for both C++ and C compiler options (like -O2), but if windres is in play, only put preprocessor related things. As an example, if you enter -O2 for CPPFLAGS, you get unknown format type `2'.
If you need to target pre-Windows XP, be sure that the compiler is before 7.3. This patch has a hard dependency on a symbol that exists only on XP.
The end result is now I have a cursed xz for an even more cursed operating system: