As far as I’m aware, the main problem with decompilers is the fact that they can’t name variables and functions automaticly. But that doesn’t matter if you are just going from binary -> decompiler -> compiler -> binary
And I know there’s a lot of platform dependent code like OS APIs (such as DirectX, and WinAPI). But surely there are substitutions of the functions defined in these APIs right? I think automated porting could be performed 90% of the time and the remaining 10% could be fixed with community patches
This feels like a incredibly stupid idea after writing down but I just want to know
Generally speaking, the initial compile is where your theory breaks. The initial compile process creates a binary that is very specific to its target system. When you decompile, you get code that is, no surprise, very specific that same target OS and hardware architecture.
Its probably a bit like English to Mandarin (random language choice). If you translate and lose the original english, you can never get the original english back, never be sure exactly what words and phrases were used.
I think licensing may have something to do with it. A proprietary licence will typically prohibit decompilation so if you do it, you’re in violation of the licence. Whether that’s enforceable… Idunno. Often just writing a rule down will make people averse to testing it. Software under a non-proprietary licence probably comes with the source code to begin with, so there’s no need. This leaves a relatively small useful area for this technique, where people either don’t mind being in potential legal trouble (or just losing their licence to use a particular piece of software) or are interested in a specific few pieces of software that don’t offer source but allow sortof digging it out of the binary directly.
How wine works might be an interesting read for you
I know how wine works. I’m basically asking why is the translation step is done in runtime rather than during the installation
The article I posted goes into that level of detail.
I wont spoon feed it to you if you don’t want to read it
Very enjoyable read, thank you for sharing!
Doesn’t seem stupid. It could maybe work for simple stuff like standard C programs that don’t use special libs, but I doubt those simple programs are bothering you.
WINE does essentially what you’re proposing in a smarter way. Rather than requiring each program to be re-compiled, it offers APIs that look like those of Windows, but then when those get called, it does the same substitution thing to make equivalent Linux API calls.
If you’re thinking “but WINE doesn’t work very well”, yeah, because these OS APIs are complex and even mildly different behaviour will cause many programs to explode. Your approach would suffer from that same problem.
If you’re not a programmer, then what you’re saying sounds reasonable, but if you are, it’s not.
Different operating systems use different ways to interact with the outside world, in fact, it’s pretty much the only thing an operating system does.
Consider for example responding to a mouse click.
Each operating system handles this differently, sometimes within the same OS it’s different depending on what else is happening, (Linux X11 vs Linux Wayland).
A mouse is pretty trivial on the face of it, but the operating system needs to be able to track each pulse from a mouse and respond to that and then it needs to tell your program about it. In other words, it needs to interrupt your program, deal with the pulse, update the relevant information, then resume your program.
The same is true for the screen, disk storage, keyboard, memory and even the CPU itself.
Even if the various operating systems use the same CPU, and these days they mostly don’t, running the same program in multiple places is extremely rare, and that’s for companies who have the source code to the software they sell.
Some programs are more universal, because they’re written in a language like python that’s compiled when you launch it, but dig inside and you’ll find code specific to each operating system.
Source: I’ve been writing software for over 40 years.
