What is .Net and Where is ASP.NET? - History
(Page 2 of 3 )
Stop for a moment and ask yourself how computer programs work, exactly. How does the code you write in a Visual Basic application go from that high-level programming code (i.e., MsgBox "Hello, Welcome to .Net!") to an actual running program? Classically, this has been accomplished via a compiler, which is a special program that translates the source code into a machine-specific language, such as assembly code (which is then transformed into machine code, an even lower-level language.)
Assembly code and machine code, though, are very platform specific. That is, machine code written for an Intel Pentium chip won't run on any machines such as Macintoshes (more generically, they won't run on a machine that uses microprocessor whose instruction set is different that that of Intel's microprocessor's instruction set).
Programs written for Windows are compiled down directly into machine code; rather, they are translated to use the Win32 libraries, which are a set of hundreds of Windows-specific functions. These functions communicate directly with Windows, which in turn knows how to communicate with the lower-level hardware. So when you write a VisualBasic program that simply displays a message box, this entire process doesn't begin until you compile the project (Make an Executable). Once this process in complete, you will have an executable file (.exe), which can be run on any Windows box by simply double-clicking the icon - VisualBasic is not needed. In essence, the VisualBasic compiler has turned your high-level instructions into something the Windows operating system can understand, which, in turn, is translated down into instructions the actual computer can understand.
Whew! That's a lot of work. Thankfully, all of those translations are hidden from you, the developer. You can concentrate on simply writing your programs using your high-level language of choice. It is then the compiler's job to do all of the necessary translations, resulting in a final executable file.
There are, however, some fundamental problems with this approach:
1. First, it is very platform specific, meaning that when you write a program using VisualBasic it will only run on computers that use Microsoft Windows.
2. Second, there is no guarantee that any two executable programs written in different programming languages will contain similar low-level code, making it next to impossible for disparate programming languages to share libraries of functions. (On an aside, Microsoft's attempt at making a single, common object model using COM has failed in certain respects; if you've ever tried to use COM objects created in VB with COM objects created in Visual C++ you'll have noted that there are oftentimes issues when passing parameters between a COM components written in a different programming language.)
3. Thirdly, the Win32 APIs are nothing more than a slew of functions. These functions contain cryptic descriptions and calling parameters. Since there are times in a VB or Visual C++ program where you may wish to call a Win32 API function directly, finding the right Win32 API function call you need to make can be a pain.
The second problem is one of the most profound as programs become more advanced. Ideally, we'd like to be able to share any function libraries or components written in one language with another seamlessly. This task is exasperated due to the fact that different programming languages may define primitive data types differently. For example, VisualBasic allows developers to create arrays with any lower bound, whereas Visual C++ forces arrays to have a lower bound of zero.
Next: .NET to the Rescue! >>
More ASP.NET Articles
More By Lakshmi Moningi
/ 98 
