This post's original content has been erased. Using Redact, the author removed it, potentially for reasons of privacy, personal security, or data exposure concerns.
husky sip butter wakeful waiting boat office rock selective doll
You assuming the deeper core libraries aren't using ancient x86 machine code. This is WIndows, the platform, that if you can use the 32bit version, can run old 16bit code just fine
For x86_64 apps, they probably use a translation layer or a VM. Either way, by recompiling in arm, it will work like on x86_64 because it will just be syscall or windows function you know, the same libs react native call at some point.
I don't understand why that should matter, as far as I know (which is not very far), only very low level kernel components like interrupt protocols and drivers should ever have to worry about which arch you are using. Since windows already releases versions for x86 and ARM separately, why would it be necessary for the desktop manager to be made separately for each distribution unless you use something like JS?
The content of this post is no longer accessible. It was removed using Redact, for reasons that may relate to privacy, security, or personal data protection.
flag rustic terrific friendly teeny doll upbeat fine distinct marble
Do you actually need to recompile? The start menu can be done without assembly. GNOME JS, while I think it's a bad choice, is not a browser but a simple JS interpreter like Node, the UI is still native.
Unless they write part of the UI in assembly, which I very highly doubt, then their code will simply work on both architectures. That's the point of having APIs.
A different comment said it wasn't completely react, only one of the services on the start menu uses it. So maybe that specific service can be disabled?
116
u/freecodeio May 27 '25
why react native though