I'm working on an embedded project where I'm actually thinking about using ECS on a STM32H5. It's not about cache-friendly locality (waitstates on internal SRAM for MCUs is basically a rounding error compared to the DRAM latency seen on desktop or server-class hardware), but the business is so complex that the traditional inheritance/composition is getting quite messy. When you end up using virtual and diamond inheritance in C++, you know you're in trouble...
It's too bad that ECS isn't more widely known outside of gamedev. It's not just good for performance, it's also legitimately a useful architecture design on its own to solve problems.
I'm working on ghidra-delinker-extension [1], which is a relocatable object file exporter for Ghidra.
The algorithms needed to slice up a Ghidra database into relocatable sections, and especially to recover relocations through analysis are really tricky to get right. My MIPS analyzer in particular is an eldritch horror due to several factors combining into a huge mess (branch delay slots, split HI16/LO16 relocations, code flow analysis, register graph dependency...).
The entire endeavor requires an unusual level of exacting precision to work and will produce some really exotic undefined behavior when it fails, but when it works you feel like a mechanic in a Mad Max universe, stripping programs for parts and building unholy chimeras from them, some examples I've linked in the readme. It has also led to a poster presentation to the SURE workshop at ACM CCS 2025 in Taiwan as a hobbyist, an absolutely insane story.
Mad respect. I tried extracting a clean .o file out of a statically linked ELF once, and it's an absolute nightmare. How are you handling switch tables and indirect jumps? Without dynamic analysis, it's sometimes physically impossible to figure out what a register is actually pointing to
I have analyzers that resynthesize relocations from the contents of the Ghidra database, no custom annotations required. They evaluate relocation candidate spots through primary references and pointers/instructions and emit warnings if the math doesn't check out.
It does require a reasonably accurate Ghidra database to work properly, but I've had users delink megabytes of code and data from a program successfully (as in, relinking it at a different address results in a functionally identical executable) once they've cleaned it up. The accuracy warning in the readme is mostly because it's really complicated to describe exactly what inaccuracies you can get away with, there's a fair amount of wiggle room in reality as long as you know what you're doing.
I'm working on stuff in that market, it's still largely is. DC Power System Design For Telecommunications is still a must read and it doesn't even cover the last 15 years or so of development, notably lithium batteries and high efficiency rectifiers.
I will say that this is a surprisingly deep and complex domain. The amount of flexibility, variety and scalability you see in DC architectures is mind-boogling. They can span from a 3kW system that fits in 2U all the way to multiples of 100kWs that span entire buildings and be powered through any combination of grid, solar and/or gas.
This appears to be organized top-down, with categories as the entry point. How do we reverse-lookup a story? That is, given a story, how can I find it (if it's there) and walk it back up into its category?
I have stories (assuming that they've made the cut) that are either in my favorites or that I've submitted, that I'd like to know how they were classified and alongside what other stories. So instead of browsing this from the outside in, I'd browse it from the inside out.
I'm currently building a full-blown OpenAPI toolchain at work, where the OpenAPI document itself is the AST. It contains passes for reference inlining, document merging, JSON Schema validation, C++ code generation and has further plans for data model bindings, HTML5 UI...
Why? Because I'm working on a new embedded system which has a data model so complex, it blew past 10k lines of OpenAPI specifications with no end in sight. I said "ain't no way we're implementing this by hand" and embarked on the mother of all yak shavings.
I want all of the boilerplate/glue code derived from a single source of truth: base C++ data classes, data model bindings, configuration management, change notifications, REST API, state replication for device twins and more. That way we can focus on the domain logic instead, which is already plenty complex on its own.
I'm not designing all of this to be simple to develop. I'm designing it so that it's simple for the developers. Even with the incomplete prototype I have currently, the team is already sold ("you mean I just write the REST API specification and it generates all of the C++ classes for me to inherit?"). The roadmap of features for that toolchain is defined, clear and purposeful: to delete mountains of menial, bug-prone source code before it is ever written by hand.
Sometimes, it takes complexity to deliver simplicity. The trick is to nail the abstractions in-between.
It's a relocatable object file exporter that supports x86/MIPS and ELF/COFF. In other words, it can delink any program selection and you can reuse the bits for various use-cases, including making new programs Mad Max-style.
It carved itself a niche in the Windows decompilation community, used alongside objdiff or decomp.me.
Easily one of the coolest RE projects out there, I've always looked on in awe.
> The relocation table synthesizer analyzer relies on a fully populated Ghidra database (with correctly declared symbols, data types and references) in order to work
It's a shame that this requirement exists (I am well aware that it's a functional necessity), because all the stuff I want to relink is far too big to make a full db!
You only need a full DB if you want to fully delink your artifact. You can just clean up the subset you're interested in exporting (the fully populated disclaimer is just there because there's a lot you can get away with, as long as you know precisely what you are doing).
Even then, a full DB is quite achievable, even on large projects. The biggest public project using ghidra-delinker-extension out there is the FUEL decompilation: https://github.com/widberg/FUELDecompilation
The executable is 7 MiB, has over 30,000 functions and has more than 250,000 relocations spots. The user made the game relocatable in six weeks (with four of them debugging issues with my extension). They then managed to replace code in spite of the fact that the artifact was built with LTO by binary patching __usercall into MSVC.
I've also had one user manage to fully delink the original Halo on the Xbox in one week. To be fair, they were completely nerd-sniped and worked non-stop on it, but it still counts.
Most of my known userbase hangs out in the decomp.me Discord server. Each project also tends to have its own dedicated Discord server.
The Windows decompilation community is far more fragmented than the console one, as it hasn't coalesced around a common set of tools like splat or decomp-toolkit.
I imagine PIE chunks that you can kludge into other programs to Frankenstein implementations? Kind of like how mad max cars are made of bits and pieces bolted together
Half-assing self-hosting sucks, regardless of the underlying platform. You tie things together with shoestrings and gum, leaving ticking timebombs and riddles to your future self.
This is the point where I'm supposed to describe my self-hosting solution on my so-called homelab, where my blog lives. I won't, because it's both stupid in smart ways and smart in stupid ways, therefore it sucks all the way.
Self-hosting is like any hobby. Half-ass it and you'll half-like it.
I've just started a new personal project, a C++20 library for running composable visitors over data documents and data models with JSON/CBOR semantics, DOM-less.
Basically, if you define a data model with bindings, you can inject data into it or extract data from it by running SAX-style visitors. You can use serializers/deserializers for standard formats like JSON/BSON/CBOR/CSV, or you can define custom formats for formating structured data however you want to. You can also run a serializer visitor on a deserializer to convert between formats. You can compose filter visitors to extract a subtree or filter out keys. And it's designed to fit on microcontrollers with very limited dynamic memory allocations, because it either streams data on-the-fly or works directly with the underlying data format in a big preallocated buffer.
I worked with libraries that offered a subset of these features before in my professional career (even built one myself), but recently I've had an epiphany (a document can also be used as a data model) that makes me think I can create something elegant and unique.
Shipped out of the box with Android 2.3, Samsung supported it up until Android 4.1, then I switched to CyanogenMod until my father rage-bought me a new phone in 2016 because it crashed so much he had trouble contacting me. I still kept it up to date with LineageOS and then unofficial versions for fun (it's at Android 13 last I checked).
Do I expect a Samsung Galaxy SII to do as well with 2026 software as it did in 2013? No, but I can run a 2013 computer with 2026 software without needing to track down dodgy homebrews on xdaforums.com and that reflects badly on the smartphone ecosystem.
>That reminds me of my own Samsung Galaxy SII.
Shipped out of the box with Android 2.3, Samsung supported it up until Android 4.1
Even that was amazing for Samsung's standards back then.
For example my former Samsung Note II shipped with Android 4.1.1 Jellybean and they only supported it till 4.4.2 KitKat. Just let that sink in. I basically bought a flagship e-waste device.
Custom ROMs didn't help much since you'd lose S-pen functionality if you went past 4.4.2 as modders couldn't port the needed firmware blobs past that kernel or something like that.
Oh, and also, using custom ROMs could brick your wifi from working as the FW of the wifi chip was tied to Knox tripping the e-fuse on custom ROMs, so then you'd need to use some voodoo to patch wifi back. That is, if you were lucky and your phone wouldn't brick itself due to the FW bug in Samsung's eMMC, that would lock itself to read-only mode out of nowhere.
Seriously, fuck Samsung for that PoS phone, fuck them in the a**. That phone should have been a lemon recall with full refund to consumers.
I rooted my old S3 probably around 2016 I had laying around. There was an exploit called "let it rain" and that got me root access.
Then on XDA Developers I found several custom ROM'S. Someone even created a Nougat ROM for that thing later on. That was the last version I was able to load on it. I sure did learn a lot back then.
It's too bad that ECS isn't more widely known outside of gamedev. It's not just good for performance, it's also legitimately a useful architecture design on its own to solve problems.
reply