Tag Archives: software

How to install free web server latest version 3.1.0

WampServer is a Windows web development environment. It allows you to create web applications with Apache2, PHP and a MySQL database. Alongside, PhpMyAdmin allows you to manage easily your database. How to install the free Server in your computer. http://www.wampserver.com/en.




Introduction to Visual Basic(Part3)

Because Visual Basic was not tied to the operating systems low-level operations, its programmers had to use library calls to access functions of the Win32 Application Programming Interface (API), the library that “defines” Microsoft Windows.

This also accentuated the difference with other programming environments like Microsoft Visual C++ or other libraries like Microsoft Foundation Class (MFC). In fact, although Microsoft shipped Visual Studio 6 that combined various programming environments with different languages (Visual Basic, C++, ASP, Win32, etc), the only real thing they had in common was that they shipped in the same box (and the same DVD).

To unify the various languages or programming environments that Microsoft had developed for many years, the company created a new library aside from Win32. This was the birth of the .NET Framework. This library is used by, or shared among, different programming languages or environments so that programmers can benefit from a better collaboration.

Now it is possible for people who “speak”, that is, people who program in, different languages to work on the same project with less regard for compatibility issues. This is because (most of) the functions, classes, and resources, are used in conceptually the same way in the different languages.

Microsoft Visual Basic .NET is Microsoft’s implementation of the .NET Framework for Visual Basic programmers. Although Visual Basic .NET is a “child” of Visual Basic 6.0, there are many differences that can be interpreted as a complete shift, with a lot of improvements.

Because of these differences, many already Visual Basic 6.0 programmers resisted the move to this new environment (there were also many other considerations) but those programmers are catching up.

  • Common Language Runtime

The CLR is the execution engine for the .NET Framework. This runtime manages all code compiled with VB.NET. In fact, code compiled to run under .NET is called managed code to distinguish it from code running outside of the framework. Besides being responsible for application loading and execution, the CLR provides services that will benefit component  developers:

  • Invocation and termination of threads and processes
  • Object lifetime and memory management
  • Cross-language integration
  • Code access and role-based security
  • Exception handling (even across languages)
  • Deployment and versioning
  • Interoperation between managed and unmanaged code
  • Debugging and profiling support (even across languages)

Runtimes are nothing new. Visual Basic has always had some form of a runtime. Visual C++ has a runtime called MSVCRT.DLL. Perl, Python, and SmallTalk also use runtimes. The difference between these runtimes and the CLR is that the CLR is designed to work with multiple programming languages.

Every language whose compiler targets the .NET Framework benefits from the services of the CLR as much as any other language..NET is also similar to Java. Java uses a runtime called the Java Virtual Machine.

It can run only with Java code, so it has the same limitations as the other languages. Another distinction is that the JVM is an interpreter. Although all languages in the .NET environment are initially compiled to a CPU independent language called Intermediate Language (which is analogous to Java byte code), IL is not interpreted at runtime like Java.

When code is initially executed, one of several just-in-time (JIT) compilers translate the IL to native code on a method-by-method basis. Cross-language integration is one of the major benefits provided by the CLR. If a colleague has written a base class in C#, you can define a class in VB.NET that derives from it. This is known as cross-language inheritance.

Also, objects written in different languages can easily interoperate. The two parts of the CLR that make this interoperation possible are the Common Type System and the Common Language Specification. The Common Language Runtime (CLR) is the virtual machine component of Microsoft’s .NET framework and is responsible for managing the execution of .NET programs.

In a process known as Just-in-time compilation, the compiled code is converted into machine instructions that, in turn, are executed by the computer’s CPU.

The CLR provides additional services including memory management, type safety and exception handling. All programs written for the .NET framework, regardless of programming language, are executed by the CLR.

It provides exception handling, garbage collection and thread management. CLR is common to all versions of the .NET framework. The CLR is Microsoft’s implementation of the Common Language Infrastructure (CLI) standard. The Common Type System (CTS) defines rules that a language must adhere to in order to participate in the .NET Framework.

It also defines a set of common types and operations that exist across most programming languages and specifies how these types are used and managed within the CLR, how objects expose their functionality and how they interoperate.

The CTS forms the foundation that enables cross-language integration within .NET. The Common Language Specification (CLS) is a subset of the CTS that describes the basic qualities used by a wide variety of languages.

Components that use only the features of the CLS are said to be CLS-compliant. As a result, these components are guaranteed to be accessible from any other programming language that targets .NET. Because VB.NET is a CLS-compliant language, any class, object, or component that you build will be available from any other CLS-compliant programming language in .NET.

Introduction to Visual Basic

Introduction to Visual Basic

  • Managed Execution

The .NET CLR provides a common context within which all .NET applications execute, regardless of the language in which they are written. CLR is responsible for handling every aspects of the managed code such as memory and resource management, secure environment to run in, garbage collection , access to the operating systems services etc. Code that targets the CLR is commonly known as managed code. The managed execution process includes the following steps:

  1. Choosing a proper compiler
  2. Generating MSIL code
  3. Compiling MSIL to CPU specific native code using JIT
  4. Executing the processor specific code.

Chapter 1(Part 3)Introduction to Visual Basic

Every constructs (such as class, struct, etc. ) in every .NET languages must compile to CLR compatible types to qualify as .NET managed code. You can choose compilers such as Visual Basic, C#, Visual C++, JScript, or one of many third-party compilers like Eiffel, Perl, or COBOL compiler. CLR supports a wide variety of data types and language features.

It is not mandatory to include all the CLR features in every .NET enabled languages, but the exposed language features should be compatible with the standard .NET frame work.

If your component is targeted to use by components written in other .NET languages, your component’s exported types must expose only language features that are included in the Common Language Specification (CLS).

1.3.3 Microsoft Intermediate Language (MSIL)

MSIL Code Generation is the first level of .NET compilation in which the high-level compiled in to a language called Intermediate Language (IL). The IL code look more like machine code than high-level language, but the IL does contain some abstract concepts such as base classes and  exception handling, which is why the language is called intermediate.

MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. When a compiler produces MSIL, it also produces metadata.

Metadata describes the types in your code, including the definition of each type, the signatures of each type’s members, the members that your code references, and other data that the runtime uses at execution time.

1.3.4 Just-In-Time Compiler

CPU-independent MSIL code can be efficiently converted to native code using Just-in-Time (JIT) compiler, only when that portion of IL code is required for execution.

JIT generated machine code is CPU-specific code that runs on the same computer architecture as the JIT compiler and it takes advantage of the added instruction sets offered by each CPU type.

1.3.5 Executing Code

When CLR executes a .NET method for the first time, it generates a processor specific native code from MSIL using the JIT compiler. The next time the method is run, the existing JIT-compiled native code is run.

The process of JIT-compiling and then executing the code is repeated until execution is complete. CLR provides myriad set of services to managed components like garbage collection, versioning, interoperability with unmanaged code, etc.

1.3.6 Assemblies

An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; the common language runtime does not support types outside of assemblies.

Each time you create a Microsoft Windows  Application, Windows Service, Class Library, or other application with Visual Basic .NET, you’re building a single assembly. Each assembly is stored as an .exe or .dll file.

The .NET Framework uses assemblies as the fundamental unit for several purposes:

  • Security
  • Type Identity
  • Reference Scope
  • Versioning
  • Deployment

1.3.7 Assembly Manifest

Every assembly contains an assembly manifest, a set of metadata with information about the assembly. The assembly manifest contains these items:

  • The assembly name and version
  • The culture or language the assembly supports (not required in all assemblies)
  • The public key for any strong name assigned to the assembly (not required in all assemblies)
  • A list of files in the assembly with hash information
  • Information on exported types
  • Information on referenced assemblies

In addition, you can add other information to the manifest by using assembly attributes. Assembly attributes are declared inside of a file in an assembly, and are text strings that describe the assembly. For example, you can set a friendly name for an assembly with the Assembly Title attribute:

<Assembly: AssemblyTitle(“Test Project”)>




1.3.8 An End to DLL Hell

DLL hell is a common term for various problems associated with the use of dynamic link libraries (DLLs) or DLL files. A DLL file is a resource within the Windows operating system that  contains code and data related to the functionality of one or more applications.

These files, which may have the file extension .dll or other file extensions, have been a major building block for the Windows operating system and Windows programs since the early MS-DOS versions of Microsoft’s computer technology. Successive versions of Windows have illustrated certain problems with the use of DLL files for many different programs.

From a customer perspective, the most common versioning problem is what we call DLL Hell. Simply stated, DLL Hell refers to the set of problems caused when multiple applications attempt to share a common component like a Dynamic-Link Library (DLL) or a Component Object Model (COM) class.

In the most typical case, one application will install a new version of the shared component that is not backward compatible with the version already on the machine. Although the application that has just been installed works fine, existing applications that depended on a previous version of the shared component might no longer work.

In some cases, the cause of the problem is even more subtle. For example, consider the scenario where a user downloads a Microsoft ActiveX control as a side effect of visiting some Websites. When the control is downloaded it will replace any existing versions of the control that were present on the machine.

If an application that has been installed on the machine happens to use this control, it too might potentially stop working. In many cases there is a significant delay before a user discovers that an application has stopped working.

As a result, it is often difficult to remember when a change was made to the machine that could have affected the application. A user may remember installing something a week  ago, but there is no obvious correlation between that installation and the behavior they are now seeing.

To make matters worse, there are few diagnostic tools available today to help the user determine what is wrong. The reason for these issues is that version information about the different components of an application aren’t recorded or enforced by the system.