Case study of Windows

Prepared by:

Dave Dhruval (Ict-005) Patel Tarana (Ict-002) Bhatt Madhuri(Ict-006) Bhadania Nirali(Ict-004) Patel Bhumika(Ict-007) Shah Flora (Ict-001)

Case study : WINDOWS

INPUT/OUTPUT IN WINDOWS

FILE SYSTEM IN WINDOWS

SECURITY IN WINDOWS

Input/output in Windows
The goals of Windows I/O manager is to provide a

fundamentally extensive & flexible frame work to handle wide variety of I/O devices. It also supports automatic device discovery & driver installation. For a large no. of common devices it is not even necessary to install a driver because it is already supported by the Windows OS.

Fundamental concept of I/O

Windows uses the concept of layers in the design of

drivers. The driver supports consist of many layers of PLUG & PLAY Manager. It is the primary component involved in supporting the ability of Windows to recognize & adapt to change in hardware configuration. It sends a request to each slot & ask the device there to be identify itself.

 An interesting feature of Windows is its support for

dynamic disks. These disks consists of multiple partitions & even multiple disks and reconfigured without having reboot. A very convenient way for recovering files which are deleted accidentally by Volume Shadow Copies- the filter driver. It creates the snapshots of the volume which can represent a volume at a previous point in time.

Input/output API calls

API-Application Programming Interface is a one kind

of system calls which provides plug & play and power operations, operations of setting parameters, flushing system buffers. API are wrapped by interfaces that provide higher level operations specific to a particular devices. To perform variety of operations no. of distinct API calls are used.

API Calls performing I/O

Implementation of I/O
Microsoft has defined the WDM(Windows Driver

Model) that device drivers are conform with. WDF(Windows Driver Foundation) that runs on top of WDM and simplifies common requirements. WDF includes the UMDF(User Mode Driver Frame Work) for writing drivers as services that execute in processes.

Device Drivers

File system in Windows

Windows support SDFS,UDF,FAT 12, FAT 16, NTFS file

formats. NTFS is the standard file system of Windows NT which supports all versions of Windows. NTFS improved support for metadata and the use of advance data structure to improve performance, reliability and disk space utilization. The NTFS file system set permissions for individual user or group of users.

Mechanisms of NTFS
NTFS supports : Storage Allocation File compression Journaling File Encryption

 Storage Allocation:Every files in NTFS is described by one or more records in an array stored in a special file called as MFT(Master File Table). Each file on an NTFS volume has a unique ID called a file reference. 64-bit quantity that consists of a 48-bit file number and a 16-bit sequence number Can be used to perform internal consistency checks

 File Compression:NTFS supports transparent file compression. A file can be created in compressed mode which means that NTFS automatically tries to compress the blocks as they are returned to disk and decompresses them when they are read back. Processes that read or write compressed files are completely unaware of the fact that compression and decompression are going on.

 Journaling:-

NTFS keeps a list of all the changed records for directories and files on the volume in the special file. The journal file is normally very large and entries will be reused before they can be examined.

 File Encryption:-

The normal way to use windows encryption is to mark the directories as encrypted. The adding of new files moved to them and editing of existing files are also encrypted as well. The actual encryption management is supported by a driver called EFS(Encryption File System) which registers callbacks with NTFS. The encryption facility provided in the windows is called BITLOCKER which encrypts almost all the data on the volume.

Security in Windows
Every Windows user is identified by a SID(Security ID) SIDs are binary no. with a short header followed by a

long random component. Each SID is intended to be unique world wide. When a user starts up a process, the process and its threads run under the users SID. Each process has an access token that specifies an SID and other properties. Each object can be accessed only by threads with authorized SIDs.

 Another basic concept is the security descriptor. Every object has a security descriptor associated with it

that tells who can perform which operations on it. It is specified when the objects are created. A security descriptor consists of a header followed by a DACL with one or more ACEs(Access Control Entries). The two main kinds of elements are Allow and Deny. An Allow element specifies an SID and a bitmap that specifies which operations processes that SID may perform on the object. A deny element works the same way, except a match means the caller may not perform the operation.