Like many, I also thought that this project was a joke. Somebody obviously created something like the Visual Basic and made it work on Android. Then from this blog post, it became clear that Simple is dead serious.
Simple tries to replicate the 20 year old Microsoft idea about high-performance components and a script language binding them into applications. There is one thing, however, that caught my attention. Why not Python or any other "real" script language? Why this Basic afterthought?
The intriguing fact is that Android's virtual machine, Dalvik just got another language beside Java. The Simple compiler takes the Simple code and compiles directly into Dalvik bytecode, without going through Java. For example there is this Simple subroutine (remember the term "subroutine" ages ago? :-)).
Sub PreviewBrick(brick As Brick, orientation As Integer)
The Simple compiler turns it into a proper Dalvik method (Simple compiler's DEX output decompiled by Dedexer):
.method public PreviewBrick(Lcom/google/devtools/simple/samples/tetris/Brick;I)V
There is a runtime for Simple programs but it is not really an interpreter, it is just a glue between the standard Android classes and the Simple event system. That may explain, why the scripting language is not Python; a real scripting language may be too dynamic to compile.
There have been similar attempts for Java proper but the JVM was never designed to run anything other than Java. When .Net appeared, Microsoft claimed that the .Net Common Language Runtime is much more suitable running certain languages than the Java bytecode. This may or may not be true, the fact remains that CLR runs mostly C# and Visual Basic.NET programs.
From this demonstration with Simple, it is clear that Dalvik can also run a script language (Simple) and a component language (Java). Whether developers will find attractive enough to work in a script language that needs time-consuming compilation and deployment before running it (one huge advantage of scripting languages is that the program can be executed immediately after modification) or whether experimenting software experts want to use a rather obsolete language (like this BASIC clone) for binding their components is yet to be seen.
Simple tries to replicate the 20 year old Microsoft idea about high-performance components and a script language binding them into applications. There is one thing, however, that caught my attention. Why not Python or any other "real" script language? Why this Basic afterthought?
The intriguing fact is that Android's virtual machine, Dalvik just got another language beside Java. The Simple compiler takes the Simple code and compiles directly into Dalvik bytecode, without going through Java. For example there is this Simple subroutine (remember the term "subroutine" ages ago? :-)).
Sub PreviewBrick(brick As Brick, orientation As Integer)
The Simple compiler turns it into a proper Dalvik method (Simple compiler's DEX output decompiled by Dedexer):
.method public PreviewBrick(Lcom/google/devtools/simple/samples/tetris/Brick;I)V
There is a runtime for Simple programs but it is not really an interpreter, it is just a glue between the standard Android classes and the Simple event system. That may explain, why the scripting language is not Python; a real scripting language may be too dynamic to compile.
There have been similar attempts for Java proper but the JVM was never designed to run anything other than Java. When .Net appeared, Microsoft claimed that the .Net Common Language Runtime is much more suitable running certain languages than the Java bytecode. This may or may not be true, the fact remains that CLR runs mostly C# and Visual Basic.NET programs.
From this demonstration with Simple, it is clear that Dalvik can also run a script language (Simple) and a component language (Java). Whether developers will find attractive enough to work in a script language that needs time-consuming compilation and deployment before running it (one huge advantage of scripting languages is that the program can be executed immediately after modification) or whether experimenting software experts want to use a rather obsolete language (like this BASIC clone) for binding their components is yet to be seen.
Dedexer got competition! Not one but immediately two - smali and baksmali is a DEX assembler/disassembler pair. The programs are brand new and - like Dedexer - they are also based on a Jasmin-like format. I tried them very shortly, the disassembler - baksmali - worked correctly and indeed produced an output similar to dedexer but I could not compile the output of baksmali back to DEX format with the assembler - smali. The disassembler does not handle ODEX files either.
The initiative is indeed valuable, however, and I encourage every reverse engineer out there give the new tools a try.
The initiative is indeed valuable, however, and I encourage every reverse engineer out there give the new tools a try.
