The other day, someone posted a comment asking what managed code was. This is an attempt at explaining it.
Although some .NET people will claim otherwise, it's basically just a fancy marketing term for interpreted bytecode that is run by a virtual machine. Yup, Java's been using "managed code" for ages folks. It's really not a new concept.
When you create a .NET application and compile it, what really happens is that your source code is compiled down into IL (intermediate language) assembly language. Then the IL code is wrapped inside of a PE32 executable file. This PE32 file's entrypoint is responsible for loading the CLR (common language runtime), which then takes your IL assembly code and compiles it on the fly (called JIT, or Just In Time, compiling) for the platform the executable is being run on. Sound familar? It's basically Java inside of a PE32 container -- nothing too fancy.
So why is it "managed"? That's because the code is essentially running in a sandbox (due to the virtual machine). Since it's abstracted from the operating system, it's more difficult to do damage since the virtual machine can do things to prevent common programming errors. For example, a buffer overflow won't start executing arbitrary code on the user's machine because the virtual machine will catch the overflow and pacify it.
However, "managed" code can still call into "unmanaged" code using certain APIs. But to make matters more humorous, .NET is built on top of parts of the Win32 API framework. So it's still possible for buffer overflows *within the "unmanaged" OS code* to cause malicious code execution. So you really only gain safety within your own code -- but you're still at the mercy of the OS security flaws.
So why should a programmer care about .NET? For a few reasons.
1) It lets you access even more functionality, and usually with a much more friendly API. Win32 APIs aren't always the most accessible APIs for people to understand. But .NET APIs are a set of OO classes, so it's conceptually easier for many people.
2) A large chunk of the new Vista functionality is implemented as a combination of .NET code and Win32 code and wrapped up as only .NET classes. So that means new functionality within the OS requires .NET.
What sort of downsides are there to using .NET?
1) As with any bytecode-oriented language, your application can be decompiled back into the original source code. So you need to run code obfuscators to secure your source code. It's annoying, but it's a fact of life -- and one you don't have to deal with when working on compiled applications.
2) The gargantuan .NET framework holds a lot of people back from deploying these apps on anything other than Windows XP.
So what does this mean for the average programmer? Currently -- nothing. Vista doesn't ship until next year, and even then, if you don't need the new-fangled OS functionality, you're safe. You can keep using your non-.NET applications without a worry.
So does this *theoritically* mean that a .NET application could run on a PowerPC version of Windows XP without a recompile?
That's a good question, I'm not so sure that the CLR supports PowerPC at the moment, though I would venture to say that you could get Mono working (an open source clone implementation of .Net) on it.
Is there even a Windows XP on a PowerPC architecture? :)
@Phil -- Yes, so long as the framework is installed.
@Jake -- yes, you can run PE32 files on PPC machines, assuming the loader is intelligent. There's a resaon it's called the "Portable Executable" file format. ;-) The linker flags certainly support PPC, as well as MIPS, 68k, ARM and others.
Is RS considering tapping into the .Net Framework and handle calling .Net functions for us RB programmers? In other words, RB would handle dealing with the framework (if it's available on workstation?) but as in RB we would get those "nifty" features exposed to us as though they were RB classes?
Generally what I'm getting at is if Microsoft is pushing to have all apps eventually go through the framework, will RB do the dirty work for me as I came to RB to get away from .Net
We're discussion various options about how to move forward, but there's nothing for public consumption yet.
However, technically speaking, I don't think it's possible to "get away" from .NET and get access to nifty new features. But I also don't think that the .NET framework is as much of an issue in the future. Your applications already rely on certain DLLs being installed on the system (hence the reason RB apps don't work on Windows 95 without a lot of mucking around -- the versions of the DLLs are too old). But on newer systems, those DLLs are there for you already, so you have no worries. The same sort of thing will eventually happen with the .NET framework. It'll come installed as a part of the OS because the OS relies on the framework itself.
Why is compiled code not at risk from decompilers but managed code is?
The short, layman's version of the explanation is this: machine code is the lowest level you can get on the computer. However, bytecode is a higher-level abstraction than machine code. So bytecode is "closer" in terms of its level to the original source, so it's much easier to get the original source back out of it.
Keep in mind that machine code can still be disassembly into assembly language. So you can get a vague idea of what the original source code was. But going from assembly to to source code is still very hard.
Bringing the topic to REALbasic's version of managed code... I was wondering how difficult it would be for a hacker to handle RBScript.
RBScript is appealing to me for serial code functions because there is no machine code to disassemble. The only weakness I see is that the source code has to be in memory at some point, and so can be susceptible to a memory dump while the source is set. Until that point it can be encrypted beforehand and deleted immediately after the RBScript has run.
What do you think?
RBScript isn't managed code -- it's a scriping language that's compiled on the fly from source. Your RBScript isn't compiled at the same time your application is compiled, for instance.
I think you're right though, there's no way around that sort of security hole.
I wouldn't worry too much about that level of obscurity -- anything that can run on a machine can be disassembled at some point.