[Openmcl-devel] CCL images, consumer apps, and piracy

[Pascal J. Bourguignon]

Tim Bradshaw <tfb at tfeb.org> writes:

> On 10 Apr 2011, at 04:55, Brandon Van Every wrote:
>
>> It is trivially easy to decompile a bytecoded language such as Java or
>> C#.
>
>
> Is this true?  I'm sure it's easy to essentially *disassemble* the
> bytecode, in the same way it's possible to disassemble native code,
> and for the JVM say, that disassembly might take the form of Java
> source, but I wonder how useful such disassembly is: surely the
> hallmark of a decent compiler is that the source->object mapping is
> very far from being 1-1?  

Yes, but the distance between the code and the source may be more or
less important. 

In the case if specific virtual machines, one point of designing them is
to reduce this distance, so the compilers are simplier.  A side effect
is that it's easier to uncompile the code.

One could say that the x86 instruction set came from military projects
originally, so it has encryption embedded in its nature...


> Certainly my, now fairly distant, experience of looking at disassembly
> from serious (native code) compilers was that it just was not that
> helpful because so much stuff was optimised away.
>
> In the case of the JVM how would such decompilation know whether the
> source language was Java or, say, Clojure, or one of the other
> languages which target the JVM (I forget the name of the CL
> implementation - is it Armed Bear?).

The patterns in sequences of generated code betray the compiler.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.