That's, uh, really impressive. I'd like the author to write about it, because I'd like to understand how much extra work it took to get compiling from the C code once it was disassembled by the tools. It'd be interesting to understand what sort of pitfalls the tools produce, so that the tools can be more efficiently used to do more work like this.
It's well above my head, but it'd be a fascinating read!
By the way it's not the first time this is done, there were some other static recompilations (Xcom i think) done in the same way 3 years ago. But Starcraft was probably harder.
On a vaguely related note, it doesn't matter much for X-Com since there is a very, very complete open-source reimplementation: https://github.com/SupSuper/OpenXcom
I used to play it on a 90MHz Pentium with 48MB of RAM, running Windows NT4, and let me tell you, it did not run well.
I remember there being this one mission where you have to survive for a fixed amount of time (10min? 15min?), and on this machine it lasted more like half an hour. Also reminds you how they accounted for time in those days.
Diablo (the first) with the Hellfire expansion ran smooth as butter on the same machine. I also remember trying to do Python and Java on that machine, didn't go over to well either, although Python wasn't too bad.
Keep in mind that the speed of Starcraft's ingame time does not necessarily match your wall clock. It can be faster or slower, depending on game speed setting.
Yeah I think I used a Pentium 233MMX at first. And single mode, online multilplayer massive maps would probably slow everything down. Gosh I wish I still had these machines to witness the differences before my eyes.
A bit unrelated, but this reminded me of when I did a full install (as opposed to a partial install and running the rest from the CD-ROM) of SC as a kid, which made my father extremely angry. "You used a whole 95 megabytes!"
I say this fully aware that the cycle will continue one day when I get angry at my future child for installing Flight Sim 27, taking up 1.5 terabytes of precious HD space. And of course, they will remember it one day and laugh because a 100PB SSD will be a $10 purchase at the gas station.
It looks like it's not a full decompiler, but just an instruction-level one - it doesn't attempt to recover any more high-level structure beyond if/goto and function boundaries with parameters. Look at lines 4500-4533 for an example. He also appears to be parsing disassembler output(!) for its input.
This kind of reverse engineering never fails to impress. If you asked me ahead of time, I'd probably have said "possible in theory, but there would be so many obstacles to overcome that no one will succeed in practice."
"The Winulator doesn’t work like an emulator. It just converts an x86 game executable to an ARM-friendly one. Here is what you need to do.
You’ll need three things – a computer with installed Winulator Converter Helper, the original DRM-free game installed on that computer and the Winulator Android app installed on your phone."
Yes I was a bit confused that this is supposed to be new information, I installed StarCraft on my android about a year ago using winulator.
It even supports a bluetooth mouse, (which I went and bought the same day I installed and got working). Works perfectly. like having a '96 gaming PC in your pocket(s)
I even changed the winulator icon to StarCraft icon then went to the pub and pulled the mouse out of my pocket, setup my android and made all my iphone-owning friends $#!^ bricks. Good times.
I've kicked around the idea of translating machine code to LLVM assembly code specifically to do things like this.
I actually got as far as creating a GitHub repo to work on this <https://github.com/wtracy/recompile> but my code never got farther than some logic for parsing ELF headers.
I can't wait until I find such a project that is in a usable state! I've tried all of these (save dagger, no releases yet) and always hit some issue due to their immaturity.
I think the most stable implementation in this space (if limited in scope) would be Apple's Rosetta. Sadly both closed-source and now abandoned; if it was opened up, it'd be great to base a more general A-to-B translator on.
Excuse my ignorance here; I wanted to get into LLVM more but never did. Don't you have: frontends which do Language => LLVM intermediate code and backends which do LLVM code => native ? So you were writing a frontend which could do x86 => LLVM code and then it can compile to ARM, x86, JS etc?
Sounds like a HUGE undertaking (esp for one person) but worth it; once you have that frontend (if my assumptions are correct), you would be able to have a lot of fun.
That's a pretty accurate description of what I was trying to do. You are correct that it's a huge undertaking. :-)
That said, even once you've got x86 -> LLVM translation working, there's a lot of code out there that makes x86-specific assumptions.
I once interviewed with a group that was trying to port a large codebase from PPC to x86, and even having the source code didn't help with the fact that their code assumed a big-endian architecture.
One approach to this is taken by RevGen [1], which uses QEMU to disassemble the target code and lift it to QEMU's intermediate representation (TCG). The TCG ops are then translated to LLVM.
It's definitely not perfect, but I suspect it will work much better than trying to do x86->LLVM from scratch. QEMU's IR is very likely much closer to correct than anything you'd come up with, since it is used for emulation, and the mapping from QEMU IR to LLVM is very straightforward (you can even run QEMU with LLVM as the backend, albeit with some performance penalty).
Two things to watch out for in this approach: helper functions (places where QEMU has decided to use a C function to implement some functionality rather than implementing it in TCG) and there may be some artifacts in the generated LLVM from things that are related to QEMU's system emulation rather than what the original code did.
Very cool--I'll look at this if I ever get back to this project. (Unlikely, given the changes in my priorities since I started it.)
At the time, my primary motivation was really to learn more about x86 machine code, which explains the brute-force approach. (Hey, Linux got started because Linus wanted to learn more about x86 memory management, so it's not a completely dumb approach.)
Yeah LLVM would be really cool like emscripten, but for x86.
I would like to see a performance comparison of this approach vs. running a full virtual machine since the x86 to arm conversion approach still requires a wine lib to execute all the windows APIs.
It's still the only option for long flights if you don't have the $ to pay for business class (power sockets there); I have a Pandora with 2 batteries (which are quite small) which is over 20 hours of a system which actually lets you do your work. Wouldn't have survived my trip of 25 hours last week without it.
I love my Pandora too .. 10 hours on a single charge, you really can't beat that. Plus the fact that its a portable Linux workstation just makes it so damned valuable even when I'm not playing games on the thing ..
We are almost there with other devices; a phone size tablet with a clamshell keyboard would do, especially if you can hook up a game keyboard, normal keyboard and mix. Problems are; 1) there are none which qualify, both tablets and keyboards; somehow clamshell, you know, the battle tested way of doing keyboards, is not something which caught on on tablets (except Clamcase I guess) :) And why can't I buy a phone sized tablet without the GSM crap in it; that would/should be tons cheaper than buying a phone 2) they are not open as the pandora. I don't really want to be stuck with Android, iOS or Win; some Linux with a complete desktop env please.
Hopefully that continues as I have been flying a lot all over the place the past month and none had it, not in the EU nor in the USA. Only in the top tier seatings. Maybe just bad luck...
Besides that ; I need devices with 'infinite-ish' battery life because battery life really really sucks.
I had various models of the GP2X and hacked together a game for it and really enjoyed the community around it. That said, I thought the Pandora project would either fail or units would only be available when better alternatives exist, or the unit price would be too high. I'm glad to see there is still some momentum.
I thought the same thing ; I didn't think I would like it that much as I do either. But there are really no alternatives; they are closed and just not the same. But the market is VERY limited to gaming coders basically. That's what it's great for...
Neat! As I'm not much of a gamer, I hadn't heard of this device before. But for under $600, you get a modest portable Linux box with 10-hour battery life.
Done by some of the founders of OpenPandora. Will probably be the only followup device. It has impressive specs, but is priced like a laptop (which it is tbh).
While I'm never one to stand in the way of tinkering, I'm curious as to why you chose FF7?
There are many open source implementations of PS1 emulators, and the PC version of FF7 is notoriously bad. So from a gameplay perspective, the PS1 version of FF7 is far easier to run an any platform, and is superior in all respects.
Starcraft was ported to ARM in 2010 to run on the Windows Mobile platform. Details are rather light, so I don't know if they used the same approach, but it's likely.
Isn't this the same thing then? You can release a recompiled ARM binary but not the source with which it was built? I think legally they are both derived works. I don't really care about that as I believe it should be allowed for software > 10 y/o, but isn't it technically the same thing and thus not allowed at all?
It's well above my head, but it'd be a fascinating read!