Rendered at 09:55:05 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dryark 6 hours ago [-]
One important thing the article glosses over: even if you sign your binary with task_for_pid, that does NOT mean you can attach to arbitrary processes on modern macOS, especially on Apple Silicon machines.
There are two separate layers people often confuse:
1) Having the task_for_pid entitlement
2) Being allowed to obtain a task port for a target process
AMFI and the kernel enforce the second one.
Even if your binary has the entitlement, the kernel will still refuse task_for_pid() for many targets (Apple platform binaries, hardened runtime processes, protected tasks, etc). In those cases the call simply fails.
Older blog posts and guides often mention disabling AMFI with a boot argument like:
amfi_get_out_of_my_way=1
(also seen as amfi=0x80)
Historically that worked because AMFI behavior could be weakened via NVRAM boot arguments. The flag effectively disabled entitlement validation and allowed processes to obtain otherwise restricted capabilities. :contentReference[oaicite:0]{index=0}
That advice is now largely outdated on Apple Silicon.
On modern M-series Macs the boot chain is tied into Secure Boot and the Secure Enclave. The kernel image, boot policy, and security configuration are verified during boot, and the system enforces what boot arguments are allowed to affect security policy.
In practice this means:
• You cannot freely change security-sensitive boot args from a normal system.
• Boot policy is enforced by the secure boot chain.
• Root does not get to override it.
Changing these policies requires booting into Recovery and modifying the machine’s security mode (Reduced Security). Even then, many AMFI protections remain active.
So the old “just set amfi_get_out_of_my_way and reboot” trick that worked on older Intel systems does not translate cleanly to Apple Silicon machines.
As a result, signing a tool with task_for_pid does not magically give you the ability to attach to arbitrary system processes on modern macOS. Without weakening the system’s boot security policy or patching the kernel, AMFI-protected processes remain non-attachable by design.
Nevermark 13 minutes ago [-]
For JIT you self-manage run protections for code segments. That isn’t free editing of arbitrary executables out of the gate, but you could develop code running in a self-harness supporting arbitrary runtime changes during development.
There would be indirection somewhere, but that could be high up the code tree, so zero impact on downstream performance sensitive code.
talkvoix 11 hours ago [-]
Reading this brings back so many memories of the early 2000s, using Cheat Engine to inject code into GunBound. It's funny how trying to get infinite gold or a perfect aimbot in a multiplayer game was the ultimate gateway drug to learning memory management, pointers, and assembly for an entire generation. The OS targets change, but the thrill of manipulating a running process remains exactly the same.
fny 13 hours ago [-]
I never understood how people use compiled languages for video games let alone simple GUIs. Even though I'm now competent in a few, and I have LLMs at my disposal, I fall back to electron or React Native just because it's such a pain in the ass to iterate with anything static.
Native devs: what are your go to quality of live improvements?
danielheath 9 hours ago [-]
Having a visual builder tool in an IDE like Delphi or Visual Basic or any of the others.
They ship with an existing library of components, you drag and drop them onto a blank canvas, move them around, live preview how they’ll change at different screen sizes, etc… then switch to the code to wire up all the event handlers etc.
All the iteration on design happens before you start compiling, let alone running.
huflungdung 7 hours ago [-]
[dead]
ellg 13 hours ago [-]
what does compilation have to do with iteration speed? There's a lot of ways to get a similar feedback loop that youd get in something like react, like separating out your core gameplay loop into its own compilation unit / dll and reloading it on any changes inside your application
jpablo 11 hours ago [-]
Yeah... that's way, way, way more complex than npm run dev
ellg 9 hours ago [-]
if i wrap a bunch of abstractions in a `make run` command whats the difference
zdragnar 8 hours ago [-]
Hot reloading is about the only difference if you're doing incremental builds.
For that, some languages are blocked by runtimes that don't support it. C can do it [0] so it's not a limitation of the static/dynamic divide.
NPM is absurdly complex in comparison, it's just neatly abstracted. Maybe somebody will write a cross-platform reactive layer which can compile both natively and to the web?
MaulingMonkey 12 hours ago [-]
> video games
Often use dynamic/scripting languages to improve iteration on gameplay code, even if a lot of the fundamental underlying code is native. And add dev-time hot reloading wherever we can so when you change a texture, it reloads ≈immediately without needing to so much as restart the level. We exile as much as we can to tables and other structured data formats which can easily be tweaked and verified by non-coders so we're not a bottleneck for the game designers and artists who want to tweak things, and make that stuff hot-reloadable if possible as well.
We also often have in-house build server farms full of testing code, because it's such a pain in the ass to iterate with anything dynamic. After all, games are huge, and sufficient testing to make sure all your uncompiled unanalyzed typecheckless code works is basically impossible - things are constantly breaking as committed during active development, and a decent amount of engineering work is frequently dedicated to such simple tasks as triaging , collecting, and assigning bugs and crash reports such that whomever broke it knows they need to fix it, as well as allowing devs and designers to work from previous "known good" commits and builds so they aren't blocked/unable to work on their work - which means internal QA helping identify what's actually "known good", hosting and distributing multiple build versions internally such that people don't have to rebuild the universe themselves (because that's several hours of build time), etc.
Some crazy people invest in hot-reloadable native code. There's all kinds of limits on what kinds of changes you can make in such a scenario, but it's entirely possible to build a toolchain where you save a .cpp file, and your build tooling automatically kicks off a rebuild of the affected module(s), triggering a hot reload of the appropriate .dll, causing your new behavior to be picked up without restarting your game process. Which probably means it'll immediately crash due to a null pointer dereference or somesuch because some new initialization code was never triggered by the hot reloading, but hey, at least it theoretically works!
And, of course, nothing is stopping you from creating isolated sandboxes/examples/test cases where you skip all the menuing, compiling unrelated modules, etc. and iterating in that faster context instead of the cumbersome monolith for most of your work.
chuckadams 11 hours ago [-]
Having a faster build step helps: I just stepped back into C recently, and I don't even want to imagine doing it without ccache and meson.
brcmthrowaway 10 hours ago [-]
Why not ninja?
chuckadams 10 hours ago [-]
Meson uses ninja under the hood.
colejhudson 13 hours ago [-]
re, iteration: Have you encountered ImGui [0]? It's basically standard when prototyping any sort of graphical application.
re, GUIs in statically typed languages: As you might expect, folks typically use a library. See Unreal Engine, raylib, godot, qt, etc. Sans that, any sort of 2D graphics library can get the job done with a little work.
You might also take a look at SwiftUI if you have an Apple device.
> It's basically standard when prototyping any sort of graphical application.
while imgui is super-cool, this is wildly overstating its reach or significance. It also embodies a very particular style of GUI programming (so-called "immediate mode", hence the "Im" part of the name) that is very well suited to some sorts of GUI applications and less so for others. The other style, often called "deferred mode", is the one used by most native toolkits, and it is very far from trivial to just switch an application between the two.
So, while there are plenty of good reasons to consider imgui for a graphical application, there are also many reasons why you would not want to use it too. It is very far from "standard" in terms of prototyping such apps.
There are two separate layers people often confuse:
1) Having the task_for_pid entitlement 2) Being allowed to obtain a task port for a target process
AMFI and the kernel enforce the second one.
Even if your binary has the entitlement, the kernel will still refuse task_for_pid() for many targets (Apple platform binaries, hardened runtime processes, protected tasks, etc). In those cases the call simply fails.
Older blog posts and guides often mention disabling AMFI with a boot argument like:
Historically that worked because AMFI behavior could be weakened via NVRAM boot arguments. The flag effectively disabled entitlement validation and allowed processes to obtain otherwise restricted capabilities. :contentReference[oaicite:0]{index=0}That advice is now largely outdated on Apple Silicon.
On modern M-series Macs the boot chain is tied into Secure Boot and the Secure Enclave. The kernel image, boot policy, and security configuration are verified during boot, and the system enforces what boot arguments are allowed to affect security policy.
In practice this means:
• You cannot freely change security-sensitive boot args from a normal system. • Boot policy is enforced by the secure boot chain. • Root does not get to override it.
Changing these policies requires booting into Recovery and modifying the machine’s security mode (Reduced Security). Even then, many AMFI protections remain active.
So the old “just set amfi_get_out_of_my_way and reboot” trick that worked on older Intel systems does not translate cleanly to Apple Silicon machines.
As a result, signing a tool with task_for_pid does not magically give you the ability to attach to arbitrary system processes on modern macOS. Without weakening the system’s boot security policy or patching the kernel, AMFI-protected processes remain non-attachable by design.
There would be indirection somewhere, but that could be high up the code tree, so zero impact on downstream performance sensitive code.
Native devs: what are your go to quality of live improvements?
They ship with an existing library of components, you drag and drop them onto a blank canvas, move them around, live preview how they’ll change at different screen sizes, etc… then switch to the code to wire up all the event handlers etc.
All the iteration on design happens before you start compiling, let alone running.
For that, some languages are blocked by runtimes that don't support it. C can do it [0] so it's not a limitation of the static/dynamic divide.
[0] https://www.slembcke.net/blog/HotLoadC/
Often use dynamic/scripting languages to improve iteration on gameplay code, even if a lot of the fundamental underlying code is native. And add dev-time hot reloading wherever we can so when you change a texture, it reloads ≈immediately without needing to so much as restart the level. We exile as much as we can to tables and other structured data formats which can easily be tweaked and verified by non-coders so we're not a bottleneck for the game designers and artists who want to tweak things, and make that stuff hot-reloadable if possible as well.
We also often have in-house build server farms full of testing code, because it's such a pain in the ass to iterate with anything dynamic. After all, games are huge, and sufficient testing to make sure all your uncompiled unanalyzed typecheckless code works is basically impossible - things are constantly breaking as committed during active development, and a decent amount of engineering work is frequently dedicated to such simple tasks as triaging , collecting, and assigning bugs and crash reports such that whomever broke it knows they need to fix it, as well as allowing devs and designers to work from previous "known good" commits and builds so they aren't blocked/unable to work on their work - which means internal QA helping identify what's actually "known good", hosting and distributing multiple build versions internally such that people don't have to rebuild the universe themselves (because that's several hours of build time), etc.
Some crazy people invest in hot-reloadable native code. There's all kinds of limits on what kinds of changes you can make in such a scenario, but it's entirely possible to build a toolchain where you save a .cpp file, and your build tooling automatically kicks off a rebuild of the affected module(s), triggering a hot reload of the appropriate .dll, causing your new behavior to be picked up without restarting your game process. Which probably means it'll immediately crash due to a null pointer dereference or somesuch because some new initialization code was never triggered by the hot reloading, but hey, at least it theoretically works!
And, of course, nothing is stopping you from creating isolated sandboxes/examples/test cases where you skip all the menuing, compiling unrelated modules, etc. and iterating in that faster context instead of the cumbersome monolith for most of your work.
re, GUIs in statically typed languages: As you might expect, folks typically use a library. See Unreal Engine, raylib, godot, qt, etc. Sans that, any sort of 2D graphics library can get the job done with a little work.
You might also take a look at SwiftUI if you have an Apple device.
[0]: https://github.com/ocornut/imgui
while imgui is super-cool, this is wildly overstating its reach or significance. It also embodies a very particular style of GUI programming (so-called "immediate mode", hence the "Im" part of the name) that is very well suited to some sorts of GUI applications and less so for others. The other style, often called "deferred mode", is the one used by most native toolkits, and it is very far from trivial to just switch an application between the two.
So, while there are plenty of good reasons to consider imgui for a graphical application, there are also many reasons why you would not want to use it too. It is very far from "standard" in terms of prototyping such apps.