find the sum of digits of any given integer

/* to find the sum of digits of  any given integer */
#include<stdio.h>
#include<conio.h>
main()
{
//declare int variable n for number for which have to find addition
//m is for temp variable to store rest value
//x is for the single digit/reminder from whole number
//sum which is initialized as 0 to store a sum of the number
    int n,m,x,sum=0;
//clears the screen
    clrscr();
//print msg to screen to enter a number
    printf("\ngive the number:");
//read input from user and store it to n
    scanf("%d",&n);
//store entered number to temp variable m
    m=n;
// start while number number is greater then 0
  while(n>0)
    {
//divide the number by 10 and store the reminder in x
    x=n%10;
//add x to sum
    sum=sum+x;
//again divide n by 10 and store it to n
    n=n/10;
//again check n>0 if yes go to top else exit while
}
//print the given/inputed digit
    printf("\ngiven number is =%d",m);
//print the sum of digit
    printf("\nsum of digits of given number is =%d",sum);
//wait for response
       getch();
       }

count the no. of characters and no. of vowels in a file 2

// to count the no. of characters & no. of vowels in a file

#include<stdio.h>
#include<conio.h>
main()
{
    FILE *fp;
    char ch;
    int nov=0,noc=0;
    clrscr();
    fp=fopen("b.c","r");  // here 'b' is the name of the file to be opened.
    while(1)
    {
        ch=fgetc(fp);
        if(ch==EOF)
        break;
        noc++;
        if((ch=='a')||(ch=='e')||(ch=='i')||(ch=='o')||(ch=='u'))
            nov++;

           }
        fclose(fp);
        printf("\n number of characters=%d",noc);
        printf("\n number of vowels=%d",nov);
        getch();
        }

count the no. of characters and no. of vowels in a file

this program demonstrates your how you can open a file and count number of character in that file and no of vowels in that file .....

#include<stdio.h>
#include<conio.h>
main()
{
//declare a file pointer   
FILE *fp;
//declare a variable character type "ch" to store a character when read a file
    char ch;
//declare integer variable "nov" to count no of vowels and "noc"  to count number of character in file
    int nov=0,noc=0;
    clrscr();
  //open file name x1.c 
fp=fopen("x1.c","r");
//start reading file till end
    while(1)
    {
  //get a single character in ch variable  
ch=fgetc(fp);
//check for end of file
  if(ch==EOF)
//exit while loop if file reached to end.
        break;
//add 1 noc
        noc++;
//get the variable in ch and check
        switch(ch)
        {
//add +1 to nov if ch is a e i o or u .....
           case'a':
              nov++;
              break;
           case'e':
              nov++;
              break;
           case'i':
              nov++;
              break;
           case'o':
              nov++;
              break;
           case'u':
              nov++;
              break;
           default:
              continue;
            }
           }
//close file      
fclose(fp);
//print number of character in file
        printf("\n number of characters=%d",noc);
//print number of vowels in file
        printf("\n number of vowels=%d",nov);
//wait for your key response       
getch();
        }

Structure, Architacture of assembly

Assembly: - Assembly is a collection of classes developed in different languages & packaged as DLL to achieve a task.

Assembly Architecture: Internal organization of a DLL file is called as “Assembly Architecture”.

"A diagram of an assembly"

DLL file is divided into 3 layers.

• Manifest information : Holds the summary of dll.
• Type information : stores the behavior of the language.
• MSIL : contains the actual logic.

Structure of an assembly

The structure of an assembly

Assemblies contain code that is executed by the Common Language Runtime. The great thing about assemblies is that they are self-describing. All the details about the assembly are stored within the assembly itself. In the Windows DNA world, COM stored all its self-describing
data within the server’s registry, and so installing (as well as uninstalling) COM components meant shutting down IIS. Because .a NET assembly stores this information within itself, it makes XCOPY functionality possible. Installing an assembly is as simple as copying it, and there is no need to stop or start IIS while this is going on.

Assemblies are made up of the following parts:

• The assembly manifest
• Type metadata
• Microsoft Intermediate Language (MSIL) code

The assembly manifest is where the details of the assembly are stored. The assembly is stored within the DLL or EXE itself. Assemblies can either be single or multifile assemblies and, therefore, assembly manifests can either be stored in the assembly or as a separate file. The assembly manifest also stores the version number of the assembly to ensure that the application always uses the correct version. When you are going to have multiple versions of an assembly on the same machine, it is important to label them carefully so that the CLR Common Language Runtime knows which one to use. Version numbers in assemblies are constructed in the following manner:

...

Type metadata was explained earlier in this chapter as data about data. This metadata contains
information on the types that are exposed by the assembly such as security permission information, class and interface information, and other assembly information.

Assemblies

Assemblies

In the applications that you build within the .NET Framework, assemblies will always play an important role. Assemblies can be thought of as the building blocks of your applications.

Without an associated assembly, code will not be able to compile from IL. When you are usingthe JIT compiler to compile your code from managed code to machine code, the JIT compiler will look for the IL code that is stored in a portable executable (PE) file along with the associated assembly manifest.

Every time you build a Web Form or Windows Form application in .NET, you are actually building an assembly. Every one of these applications will contain at least one assembly.

As in the Windows DNA world where DLLs and EXEs are the building blocks of applications, in the .NET world, it is the assembly that is the used as the foundation of applications.

In the world of Windows DNA and COM, there was a situation that was referred to as DLL Hell. COM components were generally designed so that there was only one version of that COM component on a machine at any given time. This was because the COM specification did not provide for the inclusion of dependency information in a component's type definition. When the developer had to make some changes to the COM component, this new component was introduced and, in many cases, broke applications.

With .NET, it is now possible to have multiple versions of components, or assemblies, running on the same server side by side. An application will always look for the assembly that built it.

When an application is started in .NET, the application will look for an assembly in the
installation folder. Assemblies that are stored in a local installation folder are referred to as
private assemblies. If the application cannot find the assembly within the installation folder,
the application will turn to the Global Assembly Cache (GAC) for the assembly.

The GAC is a place where you can store assemblies that you want to share across applications.
You can find the assemblies that are stored in the GAC in the WINNT\ASSEMBLY folder in
your local disk drive.

Compilation to managed code

Compilation to managed code

The .NET Framework requires that you use a language compiler that is targeted at the CLR, such as the Visual Basic .NET, C#, C++ .NET, or JScript .NET compilers provided by Microsoft. Note that there are a lot of third-party compilers on the market (such as COBOL and Perl), and the number will continue to grow.

So how does the code that you typed into Visual Studio .NET become the code that the user receives when he is using your application? It is fairly simple and straightforward. Figure a diagram of the compilation process.

"managed-code-execution-process"

After using one of the language compilers, your code is compiled down to Microsoft Intermediate Language. Microsoft Intermediate Language, known as MSIL or simply IL, is a CPU-independent set of instructions that can be easily converted to native code. The metadata
is also contained within the IL.

The IL is CPU-independent. This means that IL code is not reliant on the specific computer that generated it. In other words, it can be moved from one computer to another (as long as the computer supports the .NET Framework) without any complications. This is what makes XCopy,
or just copying over the application, possible.

After IL, the code that you started with will be compiled down even further by the JIT
compiler to machine code or native code. The IL contains everything that is needed to do this,
such as the instructions to load and call methods and a number of other operations.

Read about how clr executes dll file

Jit compilation

Jit compilation

The .NET Framework contains one or more JIT compilers that compile your IL code down to machine code, or code that is CPU-specific. This is done when the application is executed for the first time.

You will notice this process after you build your first ASP.NET page. After you build any ASP.NET page, you compile the page down to IL. When you go to the browser and call the page by typing its URL in the address bar, you notice a slight pause of a few seconds as the computer seems to think about what it is doing. It is actually calling this IL code and converting it with a JIT compiler to machine code. This happens only the first time that someone requests the page. After the first time, you can hit F5 to refresh the page, and the page is immediately executed. The page has already been converted to machine code and is now stored in memory. The CLR knows the JIT compiler has already compiled the page.

Therefore, it gets the output of the page from memory. If you later make a change to your ASP.NET page, recompile, and then run the page again, CLR detects that there was a change to the original file. It uses the JIT compiler once again to compile the IL code down to machine code.

The JIT compiler, as it compiles to machine code, makes sure that the code is type safe. It does this to ensure that objects are separate, thereby making certain that objects won’t
unintentionally corrupt one another.

Read about How CLR Execute DLL Files

Steps How CLR executes a DLL file

How CLR executes a DLL file.

1. CLR will be loaded into memory

2. CLR loads a Manifest

3. CLR loads Type Info.

4. CLR generates CTS of CLS (System.Int16, System.Int32, 64)

5. CTS information will be loaded into MSIL

6. CLR generates output.

Always CLR tracks for the changes in the program. If program is modified step 1- 6 will be executed, otherwise only step 6^th will be executed. Due to this behavior CLR is called as Just In Time Compiler.

Common Language Runtime - CLR Versions

The Common Language Runtime

Many different languages and platforms provide a runtime, and the .NET Framework is no exception. You will find, however, that this runtime is quite different from most.

The Common Language Runtime (CLR) in the .NET Framework manages the execution of the code and provides access to a variety of services that will make the development process easier.

The CLR has been developed to be far superior to previous runtimes, such as the VB runtime, by attaining the following:

• Cross-language integration
• Code access security
• Object lifetime management
• Debugging and profiling support

Code that is compiled and targeted to the CLR is known as managed code. Managed code provides metadata that is needed for the CLR to provide the services of multilanguage support, code security, object lifetime management, and memory management.

CLR (Common Language Runtime):

CLR is a standard runtime execution engine for managed code. When .net software is installed, CLR files will be installed in C:\Windows\System32 folder. In CLR software the most important file name is MSCoreE.dll (Microsoft Core Execution Library)

Version:

.Net FW: 2.0

Visual Studio: 2005

CLR version: 2.0.50727.42

The .NET languages

The .NET languages

In the past, you chose the development language for an application based upon the functionality that you were trying to perform. Some languages were more powerful than others, but at the same time they might have required a higher level of understanding and were, in most cases, more difficult to program in.

Now the .NET Framework provides you with a language-independent programming platform. You do not have to decide which language would provide a better solution. All languages are now on a level playing field.

In .NET, no one language is superior to any of the other languages. They all have equal access to everything that .NET offers.

To be part of the .NET Framework, a language only has to follow certain rules. The biggest and most important rule for inclusion is that the language needs to be an object-oriented language. Microsoft provides four languages with the .NET Framework: Visual Basic .NET, C#, C++.NET, and JScript .NET. Microsoft also provides J# (pronounced J-sharp), but in order to use this new language that is basically Java for .NET, you need to download the language to install it on your server. You can find this download at http://msdn.microsoft.com.

The .NET IDE

The .NET IDE

Instead of a multitude of tools for development, the .NET team created a single tool for
developing Windows Forms, ASP.NET Web Applications, and XML Web services. This tool
is Visual Studio .NET.

As a developer, you will find Visual Studio .NET an indispensable tool. It is finely interwoven
within the .NET Framework and will give you full and complete access to everything that
.NET has to offer

The .NET solution

In anticipation of this future, Microsoft has developed the .NET Framework and the tools
necessary to build in this new environment. Microsoft realized that it had many languages and
tools that basically did the same thing. Admittedly, some languages and tools did certain
things better than others, but all of them worked towards the same goal, and there was plenty
of overlap.

Microsoft has taken the best of all these different worlds and has merged them into a single
environment,

"A Unified model"

This new unified model will allow you, as a developer, to use one development environment
and platform to build every application type that you need.

The .NET Framework

.NET is a collection of tools, technologies, and languages that all work together in a framework to provide the solutions that are needed to easily build and deploy truly robust enterprise applications. These .NET applications are also able to easily communicate with one another and provide information and application logic, regardless of platforms and languages.

Sounds pretty outstanding, doesn’t it?

"The .Net Frame Work"

The first thing that you should notice when looking at this diagram is that the .NET Framework sits on top of the operating system. Presently, the operating systems that can take the .NET Framework include Windows XP, Windows 2000, and Windows NT. There has also been a lot of talk about .NET being ported over by some third-party companies so that a majority of the .NET Framework could run on other platforms as well.

At the base of the .NET Framework is the Common Language Runtime (CLR). The CLR is the engine that manages the execution of the code. The next layer up is the .NET Framework Base Classes. This layer contains classes, value types, and interfaces that you will use often in your development process. Most notably within the .NET Framework Base Classes is ADO.NET, which provides access to and management of data.

The third layer of the framework is ASP.NET and Windows Forms. ASP.NET should not be viewed as the next version of Active Server Pages after ASP 3.0, but as a dramatically new shift in Web application development. Using ASP.NET, it’s now possible to build robust Web applications that are even more functional than Win32 applications of the past. This was always quite difficult to do in the stateless nature of the Internet, but ASP.NET offers a number of different solutions to overcome the traditional limitations on the types of applications that were possible. The ASP.NET section of the .NET Framework is also where the XML Web services model resides.

The second part of the top layer of the .NET Framework is the Windows Forms section. This is where you can build the traditional executable applications that you built with Visual Basic 6.0 in the past. There are some new features here as well, such as a new drawing class and the capability to program these applications in any of the available .NET languages. You may view XML Web services as something you use within the ASP.NET applications that you build, but this isn’t the only place where you can consume XML Web services. It's quite possible to consume XML Web services within a Windows Form application and a number of other application types, just as you can from any ASP.NET Web application.