dezgeg

Isn't decrementing pos beyond start of haystack technically undefined behaviour?

Well it doesn't need to be a generic purpose OCR, just one that works for this single UI layout and font.

How do you know the original code didn't use some undefined variable on stack, but happened to consistently work because something else spilled a register containing "suitable" value?

I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\<Distro>\home\me\whatever

On top of the performance issue you mentioned, /mnt/c will be case-insensitive and trip up lots of Linux software!

Doesn't the Microsoft implementation work by having nop instruction as the first instruction of the function, which can then be patched to a jump to the patched code, that finally jumps back to the original function past the NOP?

Naive implementation of this scheme doesn't allow stacking.

> YouTube, Google, Google Maps, and Chrome

You listed products that have been around for ~20 years. Keeping up already entrenched products running doesn't correlate with being able to launch new products.

I'm gonna guess that the crew have been regularly landing while ignoring similar automated warnings in the past

Not to mention how any sort of TLS key exchange is supposed to happen with an unidirectional network.

If your session / computer crashes, for one.

Yes, most of this is all supported. There is a existing recipe for building an image that you just dd to and SD card and can boot in a Raspberry Pi (and other devices supported by mainline kernel + u-boot).

Kernel is a package just like another; so you just write your own recipe. Patching kernel recipe works just like patching any Nix recipe.

Not sure about the rockchip-proprietary boot parts; you may be on your own.

In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.

However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.

So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.

It probably will help you maintain a better local fork, but getting all things upstreamed is the bottleneck and won't help too much here.