10

is Visual Basic 2010 a compiled or interpreted language? Can a vb program be disassembled?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
a438
  • 115
  • 1
  • 1
  • 9
  • 1
    I know that almost any assembly created with .NET can be easily disassembled using ildasm which is provided with VS. – atoMerz May 14 '11 at 15:56

5 Answers5

15

It is compiled to IL code which is normally JITted. It is possible to create native images using a tool like Ngen.

It is very easy to disassemble .NET assemblies. There are many tools available (free and commercial) that do this.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    A good discussion of tools is available in this question: http://stackoverflow.com/questions/2646707/something-better-than-net-reflector – James Skemp May 14 '11 at 15:58
3

It's kinda both. It's compiled into IL which is then "just in time compiled" (JITed) into machine code at runtime.

Esteban Araya
  • 29,284
  • 24
  • 107
  • 141
  • 3
    While it *can* be interpreted (Mono has a mode for this), in the Microsoft .NET implementation it's always JIT compiled. – Jon Skeet May 14 '11 at 15:59
  • The IL is not interpreted, it is just-in-time compiled to native code. – driis May 14 '11 at 15:59
3

Depends on the execution environment. But it is generally compiled. Twice, first from source code to IL (Intermediate Language). Again at runtime from IL to machine code by a just-in-time compiler. Except on, say, the .NET Micro Framework which uses an IL interpreter. The intermediate form allows pretty decent decompilation, Reflector is the best tool for that.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

It's a mix of both. It's compiled to CIL (Common Intermediate Language: http://en.wikipedia.org/wiki/Common_Intermediate_Language). This CIL is JIT (Just in Time) compiled into native code by the CLR (Common Language Runtime).

Because the CIL code is left in tact, it is fairly straightforward to decompile the CIL into C#, VB .NET or another .NET variant. Several products exist to do this (Reflector, dotPeek). In order to prevent source code theft, you can use an obfuscator (eg. Dotfuscator) to make sure that any attempts to decompile the CIL into C#/VB .NET results in gibberish.

Jeff
  • 35,755
  • 15
  • 108
  • 220
  • 1
    You say it's a mix of both, presumably meaning that you believe it's interpreted. In normal operation on a Microsoft .NET implementation, can you say when you believe it's interpreted? – Jon Skeet May 14 '11 at 16:00
  • An interpreted language is one that is interpreted at runtime by an interpreting program (http://en.wikipedia.org/wiki/Interpreted_language). In .NET, that interpreting program is the CLR. – Jeff May 14 '11 at 18:31
  • @JeffN825: I would take that as a *very* broad interpretation of "interpreted", given that after the first pass, the IL isn't needed. I don't think it really makes sense to have a black and white "compiled" vs "interpreted" viewpoint which includes JIT-compiled as "interpreted". Suppose you had a system where the "executable" format was just C source code, which was immediately compiled before it was run (by the system)... would that count as being "interpreted" in your view? The system's *input* is source, after all. – Jon Skeet May 14 '11 at 19:55
  • If it's the runtime aspect of it that you dislike (for GC etc), would you view Mono's AOT compiler as still being "interpreted"? What if the runtime compiled the *whole* of all the assemblies to native code before running *any* of the code, rather than doing it just-in-time? It's hard to see how these scenarios count as "interpreting" the IL IMO. – Jon Skeet May 14 '11 at 20:03
  • I don't think Mono's AOT compiler would could as being "interpreted"...nor do I think ngen'd assemblies are "interpreted"....but in the more common scenario where you leave your assemblies in CIL format and they are JIT compiled....yes, I'd consider that interpreted. Your comments are fair, but I don't think it's a black and white situation where I'm necessarily wrong. – Jeff May 14 '11 at 23:03
  • 3
    @JeffN825: Consider a server which has been running for a year without a reboot. The IL hasn't been used since the first hour of operation - since then, everything's been completely native. Why is it useful to consider that "interpreted"? I consider "interpreting" code to mean examining it and executing "what it means" each time - so if you've got a loop, the interpreter system will have to *interpret* the code on each iteration of the loop. That's what makes it slow, of course. – Jon Skeet May 15 '11 at 06:22
0

It's complicated.

Like Java, .Net languages (including both C# and VB) are compiled down to a byte-code-like language called IL (Intermediate Language). This IL is what is then distributed to other computers.

However, it doesn't stop there. The IL is in turn compiled to native code by the JIT(just in time) compiler before it is actually executed. And yes, vb, like all languages, can be disassembled.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794