Page 320 - DCAP403_Operating System

Unit 14: Windows 2000

may return 0, or it may return a special constant named INVALID HANDLE VALUE. A process Notes
can close any handle by calling the CloseHandle function, and the system may delete the object
if the count of processes using the object drops to 0.
Windows 2000 provides three ways to share objects between processes. The First way is for a
child process to inherit a handle to the object. When the parent calls the CreateXXX function,
the parent supplies a SECURITIES ATTRIBUTES structure with the bInheritHandle FIeld set to

TRUE. This field creates an inheritable handle. Then, the child process can be created, passing
a value of TRUE to the CreateProcess function’s bInheritHandle argument. Assuming that the
child process knows which handles are shared, the parent and child can achieve interprocess
communication through the shared objects.
The second way to share objects is for one process to give the object a name when that object is
created, and for the second process to open that name. This method has two drawbacks. One is
that Windows 2000 does not provide a way to check whether an object with the chosen name
already exists. A second drawback is that the object name space is global, without regard to the
object type. For instance, two applications may create an object named .pipe. when two distinct
(and possibly different) objects are desired.
Named objects have the advantage that unrelated processes can share them readily. The First
process would call one of the CreateXXX functions and supply a name in the lpszName parameter.
The second process can get a handle to share this object by calling OpenXXX (or CreateXXX) with
the same name,

The third way to share objects is via the DuplicateHandle function. This method requires some
other method of interprocess communication to pass the duplicated handle. Given a handle to a
process, and the value of a handle within that process, a second process can get a handle to the
same object, and thus share it.
In Windows 2000, a process is an executing instance of an application, and a thread is a unit
of code that can be scheduled by the operating system. Thus, a process contains one or more
threads. A process is started when some other process calls the CreateProcess routine. This routine
loads any dynamic link libraries that are used by the process, and creates a primary thread.
Additional threads can be created by the CreateThread function. Each thread is created with its

own stack, which defaults to one MB unless specified otherwise in an argument to CreateThread.
Because some C run-time functions maintain state in static variables, such as errno, a multithread
application needs to guard against unsynchronized access. The wrapper function beginthreadex
provides appropriate synchronization.
Every dynamic link library or executable file that is loaded into the address space of a process is

identified by an instance handle. The value of the instance handle is actually the virtual address
where the fi le is loaded. An application can get the handle to a module in its address space by
passing the name of the module to GetModuleHandle. If NULL is passed as the name, the base
address of the process is returned. The lowest 64 kilobytes of the address space are not used, so a
faulty program that tries to dereference a NULL pointer will get an access violation.

Priorities in the Win32 environment are based on the Windows 2000 scheduling model, but not
all priority values may be chosen. Win32 uses four priority classes: IDLE PRIORITY CLASS
(priority level 4), NORMAL PRIORITY CLASS (level 8), HIGH PRIORITY CLASS (level 13)
and REALTIME PRIORITY CLASS (level 24). Processes are typically members of the NORMAL
PRIORITY CLASS unless the parent of the process was of the IDLE PRIORITY CLASS, or another

class was specified when CreateProcess was called. The priority class of a process can be changed
with the SetPriorityClass function, or by an argument being passed to the START command. For
example, the command START/REALTIME observer.exe would run the observer program in
the REALTIME PRIORITY CLASS. Note that only users with the increase scheduling priority
privilege can move a process into the REALTIME PRIORITY CLASS.
Administrators and power users have this privilege by default.

LOVELY PROFESSIONAL UNIVERSITY 313