The process of deciding to adopt a new programming technology like .NET reminds me of little kids walking around a swimming pool, occasionally sticking a toe in the water to check the temperature. They'll continue to circle, but then when one goes in the water, they all do.
Every so often, aspiring application developers find themselves in the annoying position of having to shed their comfortable programming platform and reinvent themselves under a new (and hopefully better) technology. We only hope it's worth it. To this end, Microsoft has built a better mousetrap in the .NET Framework. The .NET Framework for application development has been around for a few years now, but most of that time was spent in betas 1 and 2. Consequently, not many of us have taken the bait yet, so an overview of this new platform merits presentation.
Before delving into the details of the .NET framework, however, let's have a look at the more popular programming platforms in use today and pick at their warts (always fun).
C/Win32--C/Win32 programmers spend their days (and probably some nights) developing software for the Windows family of operating systems using the C programming language together with the Windows API. While developers have created many stellar applications through this approach over the years, few who have done so would dispute the complexity of coding to the raw Win32 API.
C++/MFC--A giant leap toward programmer sanity is afforded by C++, the object-oriented spin-off of C (in many ways C++ can be thought of as an object-oriented layer built on top of C). Although C++ programmers can take advantage of the "three pillars" of object-oriented programming languages (encapsulation, polymorphism, and inheritance), they are still pained by the annoying aspects of the language--e.g., manual memory management, ugly syntactical constructs, and even uglier pointer arithmetic.
To somewhat ease the discomfort, many pre-fabbed C++ application frameworks have been made available. Among these is the Microsoft Foundation Class (MFC), which provides the C++ programmer with a library of canned classes, macros, and wizards that facilitate the construction of Windows applications.
Even with this much-appreciated assistance provided by the MFC (et al), developing applications with C++ remains a complex and error-prone experience, mostly due to its underlying roots in C.
Visual Basic 6--VB is the king of wrappers. Under the hood, VB is madly placing WinAPI calls on the programmer's behalf--perhaps to a fault. Many VB programmers are blissfully unaware of the underlying mechanics of the language's interaction with the operating system and maybe rightfully so. Further, VB (at least until the advent of VB .NET) lacks support for true object-oriented program design. For example, VB does not allow the programmer to establish an "is-a" relationship between objects (classical inheritance). Similarly, without classical inheritance, you cannot have classical polymorphism.
Java/J2EE--Now we're getting closer to striking a reasonable compromise between ease-of-use and flexibility. With its syntax roots in C++, the Java programming language is nearly completely object-oriented with a large number of predefined helper packages available. And don't forget Java's primary strength: support for cross-platform independence, just like .NET. And yet, Java has its shortcomings as well. Java does not integrate well with other application development languages, so any application developed under Java must be Java from end to end (you know, 100% pure Java). You can't mix your legacy apps into the fray. Java is also weak in graphically and numerically intensive applications. (These types of applications are better developed in C++ for that very reason.) Nevertheless, Java can be thought of as a cleaned-up version of C++ lite.
COM--The Component Object Model is an architecture that supports most cross-platform interactions. So, for example, a C++ programmer can create COM classes that can be used by a VB program, but again, the devil's in the details. While COM is a very strong object model, it is extremely complex under the covers and lacks cross-platform classical inheritance.
DNA--Distributed interNet Architecture is also a very complex specification to code to and has the added drawback of requiring multiple technologies in its creation (ASP, HTML, XML, JavaScript, VBScript, COM(+), etc.). This creates a hodgepodge of language syntax, variable type interpretations, and programmer fear and loathing.
OK, so Windows programmers don't live on Easy Street and code from home. You may be thinking, "After all, if it was easy to write this stuff, everyone would be doing it, right?" Well, maybe, maybe not, but regardless, new technologies will continue to emerge to allow quicker development of safer and more useful software.
Enter .NET
In general terms, .NET is an application development platform for building systems on both Windows and non-Microsoft operating systems, now and in the future (at least until the next technology tsunami rolls over us).
The .NET Framework for application development complies with these tenets:
- Thou shalt not break any existing Win32 or COM code.
- Thou shalt implement true object-oriented programming support.
- Thou shalt achieve complete and total language integration.
- Thou shalt use a single runtime engine shared by all .NET-aware languages within a given operating system.
- Thou shalt provide a base class library to insulate the programmer from unsavory Win32 API calls and to encapsulate common programming tasks.
- Thou shalt use standard variable types and object-oriented programming constructs across all .NET-aware languages.
- Thou shalt employ a truly simplified deployment model.
- Thou shalt allow operation safely within the confines of "managed code" (aka "inside the sandbox").
- Thou shalt not condemn thy user to "DLL hell," and the user shall be delivered from machine-specific entries in an evil place (like the system registry).
You bet. These are all great ideas. As it turns out, these are the core specifications at the heart of the .NET Framework.
How .NET Works
So, how is all this to be accomplished? How is one language supposed to work with another? How can a single development platform create applications that can run on varied operating systems? Part of the answer lies in the .NET technique of compiling any .NET language into an intermediate form called Common Intermediate Language (CIL).
CIL is conceptually similar to Java byte code in that it is not machine-ready object code but rather a set of generic instructions that is compiled to machine-specific instructions by the system it's running on, thus allowing compatibility with that particular machine's operating system.
Compiling a .NET application renders a file with an extension name of .exe or .dll even though the compiled file actually contains CIL. This pseudo-executable is properly called an "assembly," which, as its term would suggest, puts things together (remember the "complete and total language integration" goal?).
So, then, VB .NET, C++.NET, J#, and C# (C# is a new .NET-only language that sure looks a lot like Java) all produce nearly the exact same Intermediate Language instructions, given equivalent source statements. Therefore CIL from one type of source code may be integrated with CIL from another type of source code (remember, the .NET .exe file is called an "assembly").
The Common Language Runtime (CLR) Execution Engine
As you know, Java's runtime support "engine" that converts byte code to machine instructions is called the Java Virtual Machine (JVM). In .NET, the equivalent runtime execution engine is part of the Common Language Runtime (CLR) and includes the Just-In-Time (JIT) compiler ("Jitter" for short). The CLR execution engine is the piece that makes a .NET app go. Physically, the CLR execution engine takes the form of mscoree.dll.
The CLR execution engine attends to such low-level chores as automatic memory management, language integration, and simplified deployment and versioning of binary code libraries. We programmers appreciate it, too.
As its name implies, the JIT compiler creates machine instructions from CIL on the fly. When a bit of code is required, the CLR locates it and passes it to the JIT compiler for conversion to machine instructions. Once compiled and loaded, the machine instructions remain in memory so they will be readily available if needed again. There is a performance hit for this type of arrangement, of course, but mostly at program startup time.
The CLR also includes the handy base class library, formally called the Framework Class Library (FCL). The base class library is a collection of encapsulated core types to perform a wide variety of common programming tasks. The bulk of the base class library is in mscorlib.dll, but there are some more specialized assemblies in other attendant DLLs. When you write a program in a .NET language, you always use the mscorlib.dll assembly and maybe some of its minions.
Figure 1 shows an example of how the CLR works.
Figure 1: The Common Language Runtime (CLR) execution engine is the heart of .NET.
Note: Be aware that the .NET Framework runtime objects must be present on the target computer in order to run .NET applications. You can get the runtime installation package from Microsoft.
The Common Type System
Have you ever noticed that data type descriptions vary from one programming language to another? For example, an "int" in C is not the same as an "int" in JavaScript, which is different from an "Integer" in VB. Don't you hate that?
To remedy this irritation, .NET adheres to a set of rules central to the .NET Framework--the Common Type System (CTS). The CTS provides a complete description of all possible types supported by the CLR, determines how those types may interact with each other, and details how they are formatted in a part of a .NET assembly called the "metadata." (The notion of a "type" in the .NET Framework includes classes, structures, interfaces, primitive data types, etc.)
The Common Language Specification
The last aspect of the .NET Framework is the Common Language Specification (CLS). The CLS is a set of rules that specify the minimal and complete features a given .NET-aware compiler must support to produce code that can be hosted by the CLR. The CLS is a sort of subset of the CTS that brings uniformity into cross-language integration. The CLS is not a .NET protocol but rather a list of rules. Rule number one is of particular interest.
Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining assembly.
That is, CLS rules do not apply to private types; they apply only to public types exposed to the outside world of other .NET apps. Any data elements that are not visible outside the defining assembly are free of this restriction. For example, the "unsigned integer" data type is known to the C++ .NET language but is unknown in VB .NET. However, you may still use unsigned integers within your C++ .NET application and keep it CLS-compliant as long as you make the visibility of the unsigned integers private to the C++ assembly.
Creating .NET Framework Applications
Currently, the .NET Framework is supported on Windows operating systems Win98, NT (sp6), ME, Win2000, WinXP, Win64, and WinCE. Future versions of Windows will integrate the .NET Framework into the base Windows operating system.
There are three ways to get the development tools required to create a .NET application:
- You can download the .NET Framework Software Development Kit (SDK) from Microsoft at no charge. The .NET Framework SDK includes everything developers need to write, build, test, and deploy .NET applications--documentation, samples, and command-line tools and compilers. The SDK is quite large (about 108 MB). You can download it from Microsoft's .NET SDK Web site or order it on CD.
- You can purchase all or part of Microsoft's Visual Studio .NET IDE. The full package includes the C++, C#, VB, and J# IDEs and compilers, but you may also purchase a single language standard version separately.
- You can use one of the free .NET IDEs like the one provided for C# and VB .NET by IC#Code called #develop.
For more information on Microsoft's .NET Framework, start here.
Future articles in the Microsoft Computing column will look further into the .NET Framework and examine the Visual Studio .NET IDE and Microsoft's "new" .NET language: C# (sounds like "see-sharp").
Chris Peters has 26 years of experience in the IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries/400 Report Downloader. Chris is the author of The OS/400 and Microsoft Office 2000 Integration Handbook, The AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400 (MC Press). He is also a nationally recognized seminar instructor. Chris can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online