Back in 2017 I wrote about a technique for creating closures in C using JIT-compiled wrapper. It’s neat, though rarely necessary in real programs, so I don’t think about it often. I applied it to
↫ Chris Wellonsqsort, which sadly accepts no context pointer. More practical would be working around insufficient custom allocator interfaces, to create allocation functions at run-time bound to a particular allocation region. I’ve learned a lot since I last wrote about this subject, and a recent article had me thinking about it again, and how I could do better than before. In this article I will enhance Win32 window procedure callbacks with a fifth argument, allowing us to more directly pass extra context. I’m using w64devkit on x64, but the everything here should work out-of-the-box with any x64 toolchain that speaks GNU assembly.
Sometimes, people get upset when I mention something is out of my wheelhouse, so just for those people, here’s an article well outside of my wheelhouse. I choose honesty over faking confidence.
Since this hasn’t been clearly stated anywhere…the approach used by the author is bad practice. It’s also oddly overengineered given that win32 already provides us with simple functionality to store user pointers along with hwnd handles. This is alluded to but the author seemed determined to not use it. Not only does the standard approach work fine, but it’s even less convoluted, less risky, and more portable than generating architecture specific machine byte code at runtime as proposed.
http://jdearden.org/programming_windows_notebook/setwindowlong.html
http://jdearden.org/programming_windows_notebook/setwindowlongptr.html
To the extent that the author feels compelled to use a higher abstraction, it would have been possible to do it with functions or macros in an include file without resorting to hacking machine code, which carries more caveats. I honestly think it’s a case of a solution in search of a problem rather than a problem in search of a solution.
Alfman,
I agree it is over-engineered and badly designed. Would restrict the app to Win32 on x86 only. Not even going to work on x86_64 let alone ARM (which also comes with a different set of memory assumptions, and would require a barrier).
Let’s see it as a “a demo that scratches an itch, with little to negative real life utility”.