Académique Documents
Professionnel Documents
Culture Documents
SUBMITTED TO
ABINASH BHAGAT
SUBMITTED BY
PRIYANKA SHARMA
ROLL NO RTB901A04
MSC( CS)
Part-A
The problem with sequential files is that they are, well, sequential. They are
great for dumping and retrieving large blocks of data all at once, but they are
not suitable for applications that need to read, write, and rewrite the same
data in a file multiple times. In those situations random access files provide
the only reasonable alternative.
Windows and Linux don't differentiate sequential and random access files
anymore than the CPU differentiates byte and character values in memory;
it's up to your application to treat the files as sequential or random access. As
such, you use many of the same functions to manipulate random access files
as you use to manipulate sequential access files; you just use them
differently is all.
You still open files with fileio.open and fileio.openNew. Random access files
are generally opened for reading or reading and writing. You rarely open a
random access file as write-only since a program typically needs to read data
if it's jumping around in the file.
You can read and write the files with fileio.get and fileio.put, although you
would not normally use these functions for random access file I/O because
each record you read or write has to be exactly the same length and these
functions aren't particularly suited for fixed-length record I/O. Most of the
time you will use one of the following functions to read and write fixed-
length data:
The fileHandle parameter is the usual file handle value (a dword variable).
The count parameter is an uns32 object that specifies how many bytes to
read or write. The buffer parameter must be an array object with at least
count bytes. This parameter supplies the address of the first byte in memory
where the I/O transfer will take place. These functions return the number of
bytes read or written in the EAX register. For fileio.read, if the return value
in EAX does not equal count's value, then you've reached the end of the file.
For fileio.write, if EAX does not equal count then the disk is full.
Here is a typical call to the fileio.read function that will read a record from a
file:
You can use fileio.read and fileio.write to read and write data from/to a
sequential file, just as you can use routines like fileio.get and fileio.put to
read/write data from/to a random access file. You'd typically use these
routines to read and write data from/to a binary sequential file.
The functions we've discussed to this point don't let you randomly access
records in a file. If you call fileio.read several times in a row, the program
will read those records sequentially from the text file. To do true random
access I/O we need the ability to jump around in the file. Fortunately, the
HLA Standard Library's file module provides several functions you can use
to accomplish this.
The fileio.position function returns the current offset into the file in the EAX
register. If you call this function immediately before reading or writing a
record to a file, then this function will tell you the exact position of that
record. You can use this value to quickly locate that record for a future
access. The calling sequence for this function is
The fileio.seek function repositions the file pointer to the offset you specify
as a parameter. The following is the calling sequence for this function:
The function call above will reposition the file pointer to the byte offset
specified by the offset parameter. If you feed this function the value returned
by fileio.position, then the next read or write operation will access the record
written (or read) immediately after the fileio.position call.
You can pass any arbitrary offset value as a parameter to the fileio.seek
routine; this value does not have to be one that the fileio.position function
returns. For random access file I/O you would normally compute this offset
file by specifying the index of the record you wish to access multiplied by
the size of the record. For example, the following code computes the byte
offset of record index in the file, repositions the file pointer to that record,
and then reads the record:
(1) write,
(2) test or debug, and
(3) successfully run programs.
Third: Due to the early bad experiences the creators of UNIX (Thompson
and Ritchie) of being kicked off of many a system, they resolved to be
able to easily maintain the entire UNIX source code. This fact is more
important than it might seem. Because all source programs were always
available and easily modified on-line, everyone could revise and rewrite
the system and its software when new ideas were thrown up, modified,
added or discovered by others.
Given the requirement that all programs should be usable with any file or
device as input or output, it is desirable to push device-dependence into
the operating system itself. Which is what happened and the rest is
history!
I will end this answer by sharing this with you - It was originally RH
Canaday of the CSTR at Bell Labs, who suggested (and helped
implement) to Ritchie and Thomson everything with a file like simple
structure, since
Part- B
*0 System Halt
*1 Single user
*2 Full multi-user mode (Default)
* 3-5 Same as 2
*6 System Reboot
When run levels are discussed they are referred to as 'moving into', or 'going
into' a certain run level. The inference is that you came from somewhere.
With the exception of booting up, a system always transitions from one
runlevel to another in response to certain conditions.
Run level 0 is the system halt condition. Nearly all modern X86 computers
will power off automatically when run level 0 is reached. Older X86
computers, and various different architectures will remain powered on and
display a message referring to the halt condition.
Run Level 1 is known as 'single user' mode. A more apt description would
be 'rescue', or 'trouble-shooting' mode. In run level 1, no daemons (services)
are started. Hopefully single user mode will allow you to fix whatever made
the transition to rescue mode necessary.
(You can boot into single user mode typically by using your boot loader, lilo
or grub, to add the word 'single' to the end of the kernel command line).
Run levels 2 through 5 are full multi-user mode and are the same in a default
UserLinux (Debian) system. It is a common practise in other Linux
distributions to use run level 3 for a text console login and run level 5 for a
graphical login.
Run level 6 is used to signal system reboot. This is just like run level 0
except a reboot is issued at the end of the sequence instead of a power off
Secondly Make sure both computers are on the same workgroup. TO do this
Right click on My computer, Properties, go to the Computer Name Tab, See
what is written in Workgroup. Change one computer by clicking on change
and then type in the name of the other computer in the workgroup space
down the bottom. Do not make the computer part of a domain. You want
Workgroup.
Under the heading "This connection uses the following items, Find Internet
Protocol (TCP/IP)
Highlight it, Make sure you don't untick the box, and click on properties
Under the heading Use the following IP Address ENter in the Following on
ONE Computer.
IPAddress 192.168.0.10
Subnet Mask 255.255.255.0
Default Gateway LEave Blank
Under the Heading Obtain DNS Serveraddress automatically
Set this to Automatic. Don't enter anything in.
• Ethernet
• ISDN
• modem
• xDSL
• token ring
• CIPE
• wireless devices
To use the Network Administration Tool, you must have root privileges.
To start the application, go to the Main Menu Button (on the Panel)
=> System Settings => Network, or type the command redhat-config-
network at a shell prompt (for example, in an XTerm or a GNOME
terminal). If you type the command, the graphical version is displayed if X
is running, otherwise, the text-based version is displayed. To force the text-
based version to run, use the redhat-config-network-tui command.
Figure 12-1. Network Administration Tool