FLEX GRID CONTROL

Steps to add a flex grid control to the project:

Select Project.

• Components menu item.
• Click the controls tab in the components dialog box.
• Select the Microsoft FlexGrid Control entry in the components dialog box.
• Close the components dialog box by clicking on OK. This displays the Flex grid control tool in the toolbox.

Adding a flex grid control to project

Steps to be followed:

• Add a flex grid control to your form by using flex grid control tool which is currently present in tool box.
• You can set the flex grid's Rows and Cols by using properties window.
• You can also customize your flex grid by setting properties such as BorderStyle,Forecolor,BackColor and so on.

Working with data in flex grid control

Several Flex grid properties help us to work
with flex grid control:

• Row-The current row in a flex grid.
• Col-The current column in a flex grid.
• Rows-The total number of rows.
• Cols-The total number of columns.
• Text-The text in the cell at(Row,Col).

Setting Flex Grid Lines and border styles

You can set what types of grid lines a flex grid uses with the Grid line property:

• flexGridNone.
• flexGridFlat.
• flexGridInset.
• flexGridRaised.

BorderStyle properties

You can set the BorderStyle property to
show a border around the whole control or
no border at all:

• flexBorderNone
• flexBorderSingle

Labeling Rows and Columns in a flex grid

• The columns and rows you label in a flex grid are usually colored gray.
• You can set the number of label columns and rows with the Fixed Cols and Fixed Rows properties.
• We use visual basic functions Chr and Asc functions and enter text directly into the flex grid using its TextArray Properties.

Formatting Flex Grid Cells

You can format text using these properties of flex grids:

• CellFontBold
• CellFontItalic
• CellFontName
• CellFontUnderline
• CellFontStrikethrough
• CellFontSize

You can also size cells as you like using the CellWidth and RowHeight.

Sorting a Flex Grid Control

We can use the flex grid’s Sort property (at run ime).

For example,
To sort a flex grid according to the values in column 1 when the user clicks a button,add this code to your program
Private Sub Command1_click()
MSFlexGrid1.Col=1
MSFlexGrid1.Sort=1
End Sub

Dragging columns in a flex grid control

• One of the attractive aspects of flex grid is that you can use drag-and-drop with them to let users rearrange the flex grid as they like.
• When the user presses the mouse button to start the drag operation we store the column in MouseDown event. This event is stored in flex grid’s MouseCol property.
• When the user drags the column to a new location and drops it we can catch that event in DragDrop event.

Connecting a flex grid to a database

Steps to connect a database to a flex grid:

1. Add a data control,Data1,to your form by using data control tool in tool box.
2. Set the data control’s DatabaseName in property window.
3. Set the Data1’s RecordSource Property to the table in the database you want to work with.
4. Set the flex grid’s DataSource property to the data control’s name, which is Data1 here.

The Timer Control

• The specific use of a timer control is to execute code at specific intervals.
• To use a timer,you add a timer control to your program and sets its Interval property,while the timer is enabled it creates Timer events.
• To add a timer to your program, use timer control tool in the tool box.
• The Interval can be set to values between 0 and 64,767 seconds.

Adding and initializing a timer control to a program

• You can add a timer control to your form by using a timer tool which is available in tool box.
• The timer control is invisible when the program runs so the size and location doesn’t matter.
• For initializing we use two properties they are,
• Enabled determines whether or not the timer creates Timer events.
• Interval sets the number of milliseconds between Timer events.
• Enabled :You can set Enabled property to False, which means no Timer events will occur. When you want to start the timer, you can set Enabled to True.
• The timer’s Enabled property varies from other controls Enabled property. the timer’s Enabled property makes Timer events occur or not, whereas other Enabled properties make controls accessible or inaccessible to the user.

Interval: It sets the interval between Timer events, Timer events cannot actually occur faster than 18.2 times a second.

Handling Timer events

The main event for timers is the Timer event,
and double-clicking a timer at design time creates
a handler function for that event
Sub Timer1_Timer()
End Sub
The code to be executed must be added in this
procedure. Timer events are not guaranteed to
occur.

The Communications Control

• To add this control to your program,
• Select the ProjectComponents menu item.
• Click the controls tab in the Component dialog
• box.
• Select the Microsoft Comm Control entry and
• click OK.
• The communication control tool appears in
• toolbox.

Creating a Clock Program

Creating a clock program involves following
steps:

• Create a new project with a form.
• Add a timer control,Timer1 to form using timer control tool.
• Set the timer’s Interval property to 1000.
• Add a label that covers that covers most of form and give it large font size.

Add the Timer1_Tick() event handler now:
Sub Timer1_Timer()

End Sub
When there’s a timer event is to update the clock and we use visual basic Time$ function to do so,
Sub Timer1_Timer()
Display. Caption=Time$
End Sub

Creating a Stopwatch

• Create a new project with a form.
• Add two command buttons in form named ‘START’ and ‘STOP’ .
• Add a label named ‘DISPLAY’ also add a timer control to form .
• Set its Enabled property to False .
• The first command button contains starting time using Now in a Form-wide variable named StartTime .
• We can start the by setting its Enabled property to True.
• The second command button contains code to stop timer i.e. Enabled property to False.
• Finally generate a Timer event by calculating time from start and stop time stored in both command buttons.

Read more of my Vb & Vb.Net Articles.

It is a Menu based program in which we ask user to give his choice. A menu is displayed in which there are options like time table, reservation, add remove route etc. The control is passes to the module which is associated with the choice selected by the user. If the option is for time-table then the records about all records are displayed.

If the option is for add or remove route, a menu prompts for a choice to add or remove route. If the choice is to add route then the user is asked several questions about Route no, No. of bus, Starting point, Destination, Fare and Departing Time, and the format of each input is checked. If the format is not correct then the user is asked to give input in required format like date is required in format of dd/mm/yyyy. The given record is checked with the stored records, if the record exists, then an error message is displayed stating that the record already exists. If the record does not exist then the time-tab file is opened in which record is written. Then the user is asked if he want to insert more records, if the answer is yes then the whole procedure is repeated else the file is closed and the control passes back to the main program.

If the option is for remove route then the user is asked to give route no. of the record of the route to be deleted. Then the record is searched in the file if it exists or not. If it does not exist an error message is displayed. If the required exist a conformation is demanded that 'Are you sure you want to delete this route'. If the answer is yes then the deleting of record is done. The route record is deleted form time-tab file. The user is asked if he wants.

If the user want to reserve seats in a route then the several inputs are required i.e. information about Date of Journey, Route no. and number of passengers i.e. number of seats to be reserved. If the information is valid and correct the file is checked for the number of available seats. If less number of seats are available then the no. of available seats is displayed else the information about passengers is asked like name of passenger, sex, age etc. it is continued until the input about all passengers is got. The records are written into the file.

If the user want to cancel seats in a route then the several inputs are required i.e. information about Route no. and seat no. If the information is valid and correct the file is checked for that seat. If the give input is correct than the record corresponding to that seat is deleted. Then the user is asked if he want to delete more seats. If the answer is yes then this procedure is continued until the required no. of seats get deleted. The records are deleted into the file.

In case of Inquiry the user is asked to give the Date of Journey & Route no. Then all the records are displayed in which user can get the required information. In case of preponment the user is asked to give the required information about Date of Journey, Route no., Starting point, Destination and Seat no. and Date to be transferred to an earlier date. The Starting Point & destination are compared with all the other records of the required date. If the places exist on any route on that date then the record of that seat no. are transferred to that date otherwise an error message is displayed.

In case of postponement the user is asked to give the required information about Date of Journey, Route no., Starting Point, Destination, Seat no. and Date to be transferred to an post date. The Starting Point & destination are compared with all the other records of the required date. If the places exist on any route on that date then the record of that seat no. are transferred to that date otherwise an error message is displayed.

In 1970, E. F. Codd developed the relational data model from which the RDBMS was born. The concept centered around tables, called relations or entities, to store data. Codd called the model “relational” after the name he used for tables, not the relationships you can build among them. From his model Codd created 12 rules summarizing the features of a relational database. One rule specifies that a system must have integrity constraints to protect data. The constraints apply both to tables and table relationships. He also created a rule stating that the relational database system should have a single language that supports all the data −access and system−management needs. This rule provided the impetus for creating the universal database language called SQL.

Codd’s relational model was revolutionary at the time and stood in stark contrast to existing database systems. Soon after he presented his model companies began building database systems around it. Vendors also added features, such as indexing logic and custom procedural languages to enhance their systems. As a result, enterprises quickly adopted the RDBMS and it is now the default database system. The benefits an RDBMS provides over the other database−systems helped increase its adoption rate. The following list summarizes some of the model’s advantages:

Data integrity — The relational model defines integrity rules that help guard against data corruption. That is, the data you place into an RDBMS do not change, disappear, or become corrupt.

Flexibility — In some respects an RDBMS server acts as an application−development platform. It provides an environment in which you can create data−centric applications. By definition, an RDBMS enables you to create entities and build relationships among them. More advanced RDBMSs incorporate a procedural language enabling you to build store procedures. Using these languages, in conjunction with entity relationships, enables you to model business processes and company workflow and store the resulting data in the database.

Universal data access — SQL has evolved as the default language for interacting with an RDBMS. Although some RDBMSs extend SQL to take advantage of proprietary features, the core language still remains portable.

An enterprise RDBMS is a complex system. It must provide robust data storage, incorporate integrity rules, and include server capabilities to share data. Figure 1 shows a conceptual view of a relational database system in a client−server deployment. As you can see, many pieces must come together to form the system.

Figure 1: Conceptual view of an RDBMS

Most RDBMSs use a client−server architecture, an architecture wherein clients communicate with the server over a network. Most often TCP/IP is the protocol for sending requests and receiving responses. The host server houses the database kernel, which consists of several internal−server processes that manage client connections, process SQL statements, and communicate with the host’s file system to manage data. Despite the number of different enterprise RDBMSs on the market, they all share two common components: data−storage structures and data−integrity rules. The following sections provide an overview of the major components.

Understanding data storage

The purpose of a database is to safely store data. How it organizes the data on the physical storage device depends on the vendor. Regardless, an RDBMS has two basic storage structures, tables and indexes. Tables, the center of an RDBMS, hold the data. Indexes, although not technically required, improve data access performance. A database system typically stores the tables and index data in files on a local file system. Depending upon the database, it may use either multiple files or one large file to hold the data. Some database systems also enable you to create distributive systems and store data on other hosts.

Tables

Tables consist of rows and columns. Rows represent entries like patient medical records or customer invoices. Each table row is called a record and is unique in a purely relational model. Without uniqueness, you cannot ensure consistent access to the same row. In addition, non−unique data can create data−corruption problems when you start creating relationships among tables. Columns, often called attributes, describe each record. A table can have one or more columns. In general, columns define the information you want to track. The data type of the columns varies between databases. However, SQL standards such as SQL−92 and SQL3 define data types that most databases support. Some example data types include CHAR, NUMBER, and DATE. As Codd mentioned, an RDBMS is based on tables. In fact, all data, even the table definitions themselves, are stored in tables. To store them, the relational database relies on system tables to completely describe itself. Storing the database metadata in tables enables database administrators (DBAs) or other authorized clients to manage the system using the same language as other users.

Indexes

Indexes help SQL queries quickly locate records. The way indexes work depends upon the index type. In general, an index ranks, or sorts, records based on a column in the table. The indexed column is known as a key. Indexes can also use composite keys consisting of multiple columns.

Without indexes a search for a record usually requires a table scan, which starts at the first row and looks sequentially at each entry for a match. Table scans do not provide quick access to a particular record or group of records, especially when a table has thousands or millions of records. For example, imagine a phone book in which names and numbers were listed in the order in which the subscribers initially obtained their phone service. In this scenario it is nearly impossible to locate a person’s phone number. You have to perform a table scan, starting with the first entry, and look at every entry until you find a match. Fortunately, a phone book indexes entries alphabetically to help you locate the person you’re looking for. Although RDBMS indexes organize the data differently, the end result is the same: You can locate the information quickly.

Indexing is a science unto itself and many different types exist. Some common types include B−tree, clustered, non−clustered, and function−based indexes. However, most databases employ B−tree, or balanced−tree, indexes as the default. This type provides very quick access to data with minimal storage requirements. The actual implementation details of a B−tree index vary between vendors. Figure 2 shows a conceptual view of a B−tree index for the alphabet. It consists of nodes that contain keys pointing to the location of data. The top node is called the root, subsequent nodes are branches, and the lower nodes are leaves. A B−tree index minimizes the path from the root node to any leaf node in the tree. Using the index you can locate any letter in the alphabet in three steps or fewer. The keys in a database B−tree index point to individual records. The figure shows only three levels in the index; real indexes often have more levels.

Figure 2: Conceptual view of a B−tree index

Ensuring data integrity

One of the biggest benefits an RDBMS provides is that it protects the integrity of the data. Once you place data into a relational database you can remain confident that it will not change. To help provide this protection, the relational model defines integrity rules. Different types of data corruption can occur in a database. Some, like disk−drive corruption, an RDBMS cannot guard against because it occurs at the physical layer. A whole drive does not have to become damaged for this type of corruption to occur; one bad block can cause significant problems. A DBA usually handles this situation by restoring the database from the last good backup. Unfortunately, an RDBMS can only mitigate the effects of this type of corruption, not prevent it.

However, two types of corruption exist that the RDBMS can protect against. The first occurs when the data among related tables become unsynchronized, creating orphan records. For example, suppose a Medical_Claims table contains records for patients, which requires a link between the Medical_Claims table and the Patients table. Deleting records from the Patients table without removing the corresponding records from the Medical_Claims table will create orphan records in the Patients table. Under relational−database rules, each medical record should map to a patient. In this situation you cannot retrieve any information on the patients associated with the orphan claims records. Duplicate table records constitute the other form of data corruption. Data duplication can lead to incorrect values generated during queries. For example, when you have two or more identical line items in an Order table, reports based on that table may be flawed. Duplicate records also create problems when you define a relationship between two tables. For instance, you cannot reliably locate the correct record that provides the link between the two tables if one of the tables has duplicate entries.

Theoretically you may create database designs to allow orphan and duplicate records. However, you will rarely encounter these designs. Remember, an RDBMS provides you with the flexibility to create good data models as well as bad ones. You should always design with data integrity in mind. Ensuring data integrity requires both entity and referential integrity. Entity integrity pertains to individual tables while referential pertains to table relationships. The following sections describe both in greater detail.

Entity integrity

Entity integrity ensures that table data remain unique, which is a requirement of Codd’s relational model. As  mentioned previously, duplicate rows can lead to erroneous values on reports or in summary queries. In addition, you cannot effectively create a relationship between two tables when duplicate records exist. RDBMSs rely on data integrity as a foundation.

To ensure uniqueness a table employs a primary key, a single attribute that is unique for every record in a table. You may also define a composite primary key consisting of multiple attributes that remain unique for each record. In any given record the other columns may contain identical data, but the column(s) representing the primary key must be unique. In general, a primary key, when combined with the table name, acts as a pointer to a particular record.

Figure 3 illustrates the primary key for the Employees. I have defined the column SSN, which represents an employee’s Social Security number, as the unique identifier for each row. No two rows can have the same value as this column.

Figure 3: Example of a primary key

A column that represents a primary key carries some additional constraints. For example, you cannot store NULL values in these columns. The column(s) that define a primary key must contain meaningful data. NULL values represent uncertainty. In addition, you must always specify a primary key value when adding a new record to a table. Not doing so is equivalent to adding a NULL value.

Referential integrity

You may build RDBMS applications that contain multiple unrelated tables. However, this creates a database application good for looking up information in only one table at a time. Most RDBMS applications consist of multiple tables related in some manner to model real−world objects and processes. To relate two tables you must create a link from one table to the other table. Foreign keys provide that link. Foreign keys are primary keys from one table used in another table. Because they are primary keys, they act as pointers to unique records in the other table.

For example, consider the Employees and Location tables in Figure 4. The Employees table has a column, Loc_Id, which holds the code from the Location table that indicates the home −office location. In this example the Loc_Id column in the Employees table is a foreign key. Each entry points to a unique record in the Location table. Regarding nomenclature, the Employees entity is called the relational table and the Location table is known as the base table.

Figure 4: Example of a foreign key

Foreign keys also limit data duplication, which minimizes your database’s size. If you reference the primary key in a base table you do not have to include the whole record. The foreign key points to it. For example, when querying the Employees table you can easily retrieve the location by joining the two tables in a SELECT statement. Like primary keys, foreign keys have usage rules. For instance, foreign keys must contain valid values in the base table. However, unlike primary keys, a foreign key can also contain NULL values. A table may even have multiple rows containing NULL values for the foreign key. Why? In some situations a record may not have valid value in the foreign key’s base table. Figure 5 provides an example of a situation in which you might store a NULL value in a foreign key. Notice that in the Family table the foreign key, Pet_Type, references a Pet lookup table. In some cases a family may not have a pet, in which case a NULL value is appropriate.

Figure 5: Example of a NULL value for a foreign key

However, a NULL value introduces ambiguity because it represents the unknown. In the previous example, if you encounter a NULL value you don’t know whether the family doesn’t have a pet, forgot to answer the question, or has a type of pet that is not listed. Good database design suggests including a "no pet" or "not listed" entry in the Pet table to deal with this problem.

Table relationships

As I mentioned above, the ability to relate entities enables you to model systems and processes. Table relationships describe how records in one table map to records in another table. When creating the relationship you rely on primary and foreign keys to glue the entities together. Because the keys have integrity constraints associated with them, they also help to ensure that the relationship remains valid.

The following sections present the different table relationships with examples explaining them.

One−to−one relationships The one−to−one relationship is the simplest. It specifies that only one record in a table maps to only one record in another table. This relationship seldom occurs in database applications. However, you will need it in some obvious situations.

Figure 6 shows an example of a situation in which you might encounter a one−to−one relationship. In this case, it describes the relationship between an automobile and an engine. As you know, an automobile can only have one engine and vice versa. In the model, both the Automobile and Engine tables have composite primary keys: Auto_ID and Engine_ID, respectively. The Automobile table stores data about the vehicle, such as color and model. The Engine table stores engine specific information. The two tables share a one−to−one relationship based on their primary keys. In this example the one−to−one relationship is obvious.

Figure 6: Example of a one−to−one relationship

You can also use the one−to−one relationship to split a table into two parts. For example, suppose you have a table with a large number of columns. To make administration and documentation easier, or circumvent system limitations, you may want to split the table into two smaller entities. When splitting a table you keep the same primary key for each table and create the one−to−one link based on it. Splitting a table also makes sense if it contains both confidential and non− confidential data. You can keep the confidential data in a separate table and allow only authorized personnel to access it. Again, identical primary keys in each table create the link.

One−to−many relationships The most common entity relationship is the one−to−many relationship. It occurs when a record in one table has zero, one, or many matching records in another table. You may also hear this relationship appropriately called a parent−child or master−detail relationship. The relationship frequently occurs when a relational table includes information from a lookup table. Figure 7 shows an example of a one−to−many relationship used in the data model for an online store that sells computer systems. All the lookup tables — Mouse, Monitor, and Keyboard — contain unique inventory items for the different components.

Figure 7: Example of a one−to−many relationship

The lookup tables have a one−to−many relationship with the Computer_System table. That is, every record in a lookup table can have zero, one, or many records in the Computer_System table. For example, a certain style of mouse is used in many different systems. The same holds true for keyboards and monitors.

Many−to−many relationships Two tables share a many−to−many relationship when a record in Table A has many matching records in Table B, and a record in Table B has many matching records in Table A. Unfortunately, the relational model does not enable you to directly implement this relationship between two tables. To implement the relationship you need to use a third table that indirectly join the two other tables to each other. The third table, often called a joining, linking, or association table, has a one−to−many relationship with each table.

Figure 8 illustrates this relationship between an Order and a Products table. A single product can exist on many different orders, and a single order can contain many different products. To uniquely identify a specific product−order combination you need an association table, Order_Details. It has two one−to−many relationships, one with the Products table and another with the Order table. Each entry in the Order_Details table represents a specific order−product combination. As you can see, many−to−many relationships can become complex and confusing. This underscores the importance of understanding the data model before developing an application.

Figure 8: Example of a many−to−many relationship

Operating system is an essential part of a computer system. There are variety of operating systems available in computer market, such as Microsoft MS-DOS, Windows, and Windows NT, IBM OS/2, UNIX, the Apple Macintosh Operating System, and DEC VMS, TOPS-20 and many other popular operating systems.

In this article we will go through one of the most popular multi-user timesharing operating system – UNIX, a trademark of AT & T Bell Laboratories. At one time UNIX was almost small enough to understand and yet was not a toy operating system.

The primary advantage of UNIX is that of its portability. Only a small portion of UNIX operating system depends on the architecture of the machine. The programmer, who shifts from one type of UNIX system to another type of system, needs to recompile his program only. The programmer does not need to bother about this aspect.

The data structures, algorithms and programming languages may be different from machine to machine to achieve the same results. This is the reason, why many versions of UNIX are available for personal computers, microcomputers, minicomputers, large main frames and supercomputers.

Among various versions of UNIX, the AT & T’s UNIX System V, and Berkeley’s UNIX System BSD 4.3 are very important versions. The other versions, such as SCO XENIX, DG-UX, HP-UX, and Ultrix, borrow ideas from either System V or BSD 4.3, or both. Therefore instead of discussing each type of UNIX system we will discuss the At&T’s UNIX system.

History of UNIX

Ken Thompson of the Research Group at AT & T Bell Laboratories, later joined by Dennis Ritchie, in the late 1960s developed the first version of UNIX. The first version of UNIX was a single user system for the PDP-7 computer system and was written in assembly language.

Initially it was written to use an otherwise idle PDP-7 system. At that time even the developers of UNIX Ken Thompson and Dennis Ritchie would never have been thought that they had to make a popular operating system.

It was their selfish motto that led to the development of UNIX and created the most powerful and popular multi-user operating system. Dennis Ritchie joined Bell Laboratories in 1968. Before joining Bell Laboratories, he was involved MULTICS (Multiplex Information and Computing Service) project. After that he worked part time for MAC, the MIT (Massachusetts Institute of Technology) computer timesharing project before joining Bell Laboratories.

Some features of UNIX, such as file system, command interpreter (the shell) as a user process, the use of a separate process for each command, and many other features came directly from MULTICS.

At that time Ken Thompson was working on a project – “Space Travel” which simulated the movement of planets within Solar system. Dennis Ritchie soon joined him. They used an ideal system PDP-7. There were no microcomputers at that time. And the cost of using mainframe at that time was too great. Only minicomputers, such as PDP-7 or PDP-11 were available at Bell Laboratories. The primary limitation of PDP-7 was that there were no software, such as assembler, compiler, operating system, and so on, available on it.

To overcome this limitation, Thompson wrote a cross assembler program running on a large computer GECOS system. Therefore whenever they made any change in the program, they wrote for GECOS system first and then use that cross assembler to get the machine program for PDP-7.

The machine program for PDP-7 was produced, by GECOS system, by punching strategy on a paper tape. After this that paper tape was carried to the PDP-7 machine, load it and then run the program. It was very ridiculous whenever they made a bit of change in the program.

After this harassment, they decided to write an operating system for PDP-7. But unfortunately Bell Laboratories rejected their approach because they had already seen the major failure of MULTICS operating system, which was developed by Generic Electric, MIT and Bell Laboratories as a combined project.

The primary goals for developing MULTICS operating system was to

- Allow more than one user to share the resources of the computer system
- Provide ample disk space and memory
- Allow sharing of data

It was very difficult to maintain MULTICS because it was mainly written in PL/1 and the assembly language of the system. The thoughts behind the development of MULTICS were, no doubt, very good. But its failure made a disaster decision for Thompson and Ritchie. And they failed to get the approval from Bell Laboratories.

After some time Thomson got an opportunity by which he could continue his dreams. They got a PDP-11 machine along with a PDP-10 memory management unit by back door entry. After that Thompson and Ritchie worked quietly on UNIX for many years. You may be surprised to know that initially UNIX was written completely in assembly language like all other operating system of that time.

They took a lot of ideas from MULTICS and XDS-90. That’s why this new operating system was named as UNICS (Unilplexed Information and Computing Service). After some days, the spelling of UNICS was modified to UNIX. But still it was not a pleasant time for both Thompson and Ritchie.

They suffered a serious limitation of UNIX and that was none other than portability. It was so because UNIX was written in assembly language relevant to the system. Therefore when they shift from one type of system to another type of system they had to write each time in a different assembly language.

To make UNIX portable, Ken Thompson designed a new language “B” in 1970. The “B” language was a simplified version of another high level language “BCPL” (Basic Combined Programming Language) designed by Martin Richards at Cambridge University. But unfortunately “B” was too specific and could deal with only specific problems.

After this Ritchie designed another new language “C” in 1972 by inheriting the features of “B” and “BCPL”, and added some of his own features. The primary advantage of “C” language is that it combined features of both high and low level languages. That’s the main reason why “C” is often called as a middle level language.

After this most of the UNIX system was rewritten in “C” by both Thompson and Ritchie together in 1973 with careful isolation and confinement of machine dependent routines. Near about 90% of source code of UNIX was written in “C” language and only 10% is machine dependent in order to control the hardware directly.

Now whenever they shifted from one type of system to another type they needed only a “C” compiler on the new system and to rewrite only the 10% of assembly code for the new system. It made UNIX portable to some extent. Now UNIX was also moved to larger PDP-11 family of computers, such as 11/45 and 11/70. Initially UNIX was used within the Bell Laboratories only. After some time UNIX slowly spread outside Bell Laboratories to a few Universities.

When Thomson rewrote UNIX in “C”, he added multiprogramming and other enhancements to systems that had hardware support for multiprogramming. Thus UNIX supports multiple users on such systems with memory management hardware.

That’s why UNIX was ported to many hardware systems from microcomputers to supercomputers quite rapidly. Bell Laboratories issued UNIX source code at very low prices to many Universities. And fortunately most of the Universities at that time had PDP-11 systems. Therefore the students of such Universities got the source code and made the changes according to their systems and requirements.

In 1978 Version 7 was distributed and replaced Version 6. This version of UNIX worked on the PDP-11 and the InterData 8/32. After this AT & T Bell Laboratories soon realized that UNIX system could be a product, rather than just simply a software tool. The Research Group within AT & T Bell Laboratories had continued to develop their own versions of UNIX.

Next came Version 8, 9 and 10. The later version is available with in Bell Laboratories. The very first UNIX product that AT & T sold commercially was System III, in 1982. It had features of Version 7, and 32V, and also of several UNIX systems. But still it had a lot of problems. Unfortunately System IV never came up. AT & T released directly System V with different releases: 2 (V.2) in 1984, 3 (V.3) in 1987 and 4(V.4) in 1989.

The other UNIX systems developed a group that does not belong to non-Bell Laboratories and non-AT & T was from University of California at Berkeley. University of California at Berkeley had the complete source code of UNIX. That’s why they could easily modify the code. Berkeley produced a number of UNIX versions, called 1BSD, 2BSD, 3BSD and 4BSD.

They got aided from Defense Advanced Research Projects Agency (DARPA) for the development of a standard UNIX system. One of the main primitives of 4BSD was that it provides enough support for Internet networking protocol (TCP/IP). TCP/IP became a de facto standard protocol by UNIX. After 4BSD, they continuously produced the improved versions in UNIX, such as 4.1BSD, 4.2BSD, 4.3BSD, and 4.4BSD.

Berkeley UNIX had a number of facilities such as a new editor (vi), a new user interface (the C shell), and many new system programs. All these improvements made many vendors like SUN, DEC, etc. base their UNIX on Berkeley UNIX. Unix software from Berkeley is released in Berkeley Software Distributions.

In late 1980s, there were two major UNIX vendors – one which used AT & T’s UNIX and the second which used BSD UNIX. There are many differences between these two. We could not use the object code of one type of UNIX system to another type of UNIX system because they have totally different file formats. Although source code could be ported from UNIX system to another by recompiling it.

After some time IEEE came forward to bring the two vendors together under one umbrella and define a standard UNIX called “POSIX” standard. “POS” stands for Portable Operating System and the “IX” is taken from UNIX. Now both vendors were agreed to follow the POSIX standard.

In market we have a wide variety of UNIX and UNIX-like operating systems. The DEC system supports Ultrix operating system, Microsoft provides XENIX for the Intel 8088 family and its new Windows/NT operating systems and mainframes. The usage of UNIX varies from department to department.

But most of these systems are based on Version 7, System III, 4.2 BSD or System V. The last Berkeley release 4.4BSD was finalized in June of 1993. The current set of UNIX system is not limited to those by Bell Laboratories, AT & T, and Berkeley.

The strong point about UNIX is that it is so mature that there are no major bugs left in it. It was initially designed by two Bell Laboratories employees Thompson and Ritchie. Now-a-days it is defined by multinational standardized organizations. The originators of UNIX, Thompson and Ritchie, were honored by the Association for Computing Machinery Turing award in 1983 for their contributions on UNIX.