The main difference is that when you compile a program for Windows, Linux etc., you have an operating system and kernel with their exposed functions/interfaces so even in a compiled program it’s pretty easy to find the function calls for opening a file, moving a window, etc. (as long as the developer doesn’t add specific steps hiding these calls). But in an embedded system, it’s one large mess without any interfaces apart from those directly on the hardware level.
Comment on Why can't code be uncompiled?
noli@programming.dev 8 months agoIsn’t that still the same exact process as a normal compiler except in the case of embedded systems your OS is like a couple kilobytes large and just compiled along with the rest of your code?
As in, are those “crazy optimizations” not just standard compiler techniques, except applied to the entire OS+applications?
morhp@lemmynsfw.com 8 months ago
Treczoks@lemmy.world 8 months ago
In a way, yes. But it really creates a mess when the linker starts sharing code between your code of which you have sources, and then jumps in the middle of system code for which you don’t have sources. And a pain in the whatever to debug.
noli@programming.dev 8 months ago
Don’t you have the code in most cases? Like with e.g. freeRTOS? That’s fully open source
Treczoks@lemmy.world 8 months ago
For a number of reasons people use commercial OSes in this world, too.
noli@programming.dev 8 months ago
Does commercial mean closed source in this context though? It seems like a waste of resources not to provide the source code for an rtos.
Considering how small in size they tend to be + with their power/computational constraints I can’t imagine they have very effective DRM in place so it shouldn’t take that much to reverse engineer.
May as well just provide the source under some very restrictive license.