We will be undergoing scheduled maintenance on May 20th, 2013 at 02:00 GMT.
Visitors to VTC.com will be able to view all introductory videos for each training course.
Free Trial Members will gain access to first three chapters for each training course.
Full Access Members have full access to VTC.com�s entire library of video tutorials.
Ok let's talk about MSIL or Microsoft intermediate language code. Now this is where you first get your complete picture of Microsoft .NET. We write code in the visual studio environment or in notepad just like we've always done. This code then gets compiled into what is called MSIL or intermediate language. Now this language is where the common language runtime takes whatever we write in whatever language. And brings it down into a common structure or a language that can now be manipulated to any CPU, and then, as we run different parts of program, they are executed or they are compiled down to whatever language is needed to actually execute on that particular CPU or that platform. And this is the magic of .NET. Now we know what our code looks like, but what does MSIL code actually look like? Well, if we compile some code into what used to be an executable, it still looks like an executable to us but it's in MSIL and here is what that looks like. Using the dis-assembler I've opened the wordcount.exe file. Now I got this out of the Framework documentation so you can see it. But in this notice there is a manifest, which we'll talk about later in this assembly, but we can see all the different aspects of our application. And we can see some property values and some methods and so forth, and there is a class here that is happening, there's all kind of stuff. But I can actually see what the intermediate language code looks like after it has been compiled from my standard code. So if you can get that picture of our code gets compiled into MSIL and that gets compiled down to the CPU through a process called just-in-time activation, or JIT activation, and we'll talk about that later. Intermediate language is basically a CPU independent set of instructions, it is the common ground for the common language runtime. Now understand something; if I write code in VB .NET and I write the same program in C-sharp .NET. Once it gets down into the intermediate language the code will be the same. That is the magic of the common language runtime, it takes any instructions in any .NET compliant languages, and whatever you write in your code, it compiles it down into a standard that they can then interpret and run on appropriate CPU's. Intermediate language is easily converted down to native machine language code for the CPU. It includes instructions for objects such as how to load them, storing those objects, initializing those objects and then calling the methods on those objects. The MSIL also includes instructions for handling arithmetic operations, or arithmetic operations, depending upon what part of the country you are from. Logical operations, the control or the flow of the program, direct memory access, exception handling and even more. So you see that the MSIL basically becomes the magical point for us. Now let's think about something. If we take all of our code and compile it down into MSIL code and then we get ready to run our application, isn't it going to take a lot of time for all of that MSIL code to be compiled down into native code so that the CPU can run it. The correct answer to that question is no, because a process called just-in-time activation, your code is actually compiled at the method or function level; so if you write an application with three functions and then you compile it, it goes to MSIL code. The three functions are not compiled down into native code until I actually call the functions. If I call one of the functions, it will be compiled into native code and the other two will not. Not until they are called. So we're actually only compiling the portions of the problem that were running. Which means we don't have to waste time compiling portions of the program that may never run in that particular situation. And obviously once it's been compiled, then we never compile it again. Just-in-time activation takes care of moving the code from the MSIL state to the CPU specific state. Now MSIL also has meta-data, it includes the definition of each type, this is variables and classes and so forth in our code. It handles the signature of each type of members. Now members - being procedures, functions, variables and so forth. But the signature of a member is on a method and I'll point this out later when we get to methods, is the parameters that a method takes. We create a method to calculate totals, and we want to pass it to integers. And we say you know bi-value 'x' as integer, the bi-value x as integer is the signature of that member. And any other data that's needed at runtime, the MSIL has all that stuff. So that's a quick view of the MSIL, you'll hear a lot about this thing. But just understand that it is the common area for .NET. And one more time I want to show you what this looks like, we write code, the code is written, we compile that code by building a report, what we used to do of convert to exe, we now do a project build. And this takes our code to the intermediate language level, and it sits there, and as we then begin to run our application, as the different pieces of the application get called, they get compiled down to native code and executed on the CPU. This is the fundamentals of .NET. In the next video we'll talk about the tools that we can use to actually look into the MSIL code, and see what's happening.
| Course: | Microsoft Visual Basic .NET |
| Author: | Mark Long |
| SKU: | 33433 |
| ISBN: | 1932072349 |
| Release Date: | 2003-05-27 |
| Duration: | 6 hrs / 87 lessons |
| Captions: | No |
| Compatibility: |
Vista/XP/2000, OS X, Linux QuickTime 7, Flash 8 |