3 ms·

I have a few technical questions, as well as a few about your intentions with the software. How does it handle interrupt calls to the OS? It's not an issue for

I have a few technical questions, as well as a few about your intentions with the software. How does it handle interrupt calls to the OS? It's not an issue for Windows (because it's all done through library calls, right?) But DOS int21 and Linux int80, for example? With the x86 work, is the logic all built around protected mode? I've been using IDA to examine/document the assembly of a DOS game, so I'd be interested in the behavior if it's fed real mode code. Further (and tying in to my previous question), the game uses Borland overlays through int3f (it seeks in the binary itself and loads new sections of code into memory, while running, before jumping into the newly-retrieved code). Would that kind of thing be possible to handle automatically? IDA seems to be hard-coded to look for the offset+length tables that are used, and finds the function entry points that way. More on the business side, you've got a way to request a quote, and the impression I get is that your aim is to run a decompilation business. Where does that leave the software itself? As a proprietary technology that lets you differentiate your business? Or is it your plan to sell the software, release binaries, release code, or some combination? My perspective is that of a hobbyist with a curiosity for reverse engineering and a (strictly non-commercial) project to apply it to, and I'm trying to figure out where this software fits into my world.

zandorg 10y ago
About interrupt calls... If it finds such a call, all it has to do is look at the call's input registers (assuming they are in registers) and output the call with the 'logical' contents of the registers. The x86 code is basically 32-bit Windows. I haven't got a 16-bit compiler. However, it should work for 16-bit. The key thing is that you can write specialised modules for each CPU, and the rest (loops, variables) are standardised. On the business side... Basically, my 6502 decompiler works the best so I thought I could sell that. And as for x86, there are issues to do with structs & arrays, that I haven't had time to figure out. As for the decompiler software, I plan to finish the x86 and ARM decompilers and sell them for a reasonable price (say, $150 for all CPUs, not just one). As noted, arrays & structs are a problem. As for 'release code', anyone can write a CPU module, but I need to document it first. Thanks for your comments.

zandorg 10y ago

About interrupt calls... If it finds such a call, all it has to do is look at the call's input registers (assuming they are in registers) and output the call with the 'logical' contents of the registers. The x86 code is basically 32-bit Windows. I haven't got a 16-bit compiler. However, it should work for 16-bit. The key thing is that you can write specialised modules for each CPU, and the rest (loops, variables) are standardised. On the business side... Basically, my 6502 decompiler works the best so I thought I could sell that. And as for x86, there are issues to do with structs & arrays, that I haven't had time to figure out. As for the decompiler software, I plan to finish the x86 and ARM decompilers and sell them for a reasonable price (say, $150 for all CPUs, not just one). As noted, arrays & structs are a problem. As for 'release code', anyone can write a CPU module, but I need to document it first. Thanks for your comments.