Case Study

On
Windows Operating System

In Partial Fulfillment of the

Requirements for the Subject
PLATFORM OS

Submitted to:

Mr. Aaron M. Macaludos

Instructor

Submitted by:

Rico D. Rillera
Melkert Semilla
Cleo Franchette Gutib
Emile Christian T. Cuevas
BSIT 2-1B

August 2019
INTRODUCTION

Windows is one of the best operating systems that people use. Like most
traditional operating systems, Windows offers a general-purpose time-sharing
multiprocessing and multiprogramming environment. However, windows being said had
lack of tools for efficient implementation of parallel applications.
In this study we will how the key goals in making the windows OS, its responsibility
for users capabilities and satisfactory. And further explain how information/data rums from
user to kernel by defining its tools..

BACKGROUND

PRE-HISTORY
Microsoft and IBM co-developed OS/2 — in hand-written 80286 assembly! As a result,
portability and maintainability weren't really strong features so in 1988 Microsoft decided
to develop a "new technology" portable OS supporting both OS/2 and POSIX APIs Goal:
A 32-bit preemptive multitasking operating system for modern microprocessors Originally,
NT was supposed to use the OS/2 API as its native environment, but during development
NT was changed to use the Win32 API, reflecting the popularity of Windows 3.0

HISTORY
 1988: gates approaches David Cutler(DEC)
 1993: WinNT Launched
 2000: Windows 2000(previously “NT5.0”)
 2001 Windows XP (build 2600)
 2003 Windows Server 2003

Key Goals
 Portability: hence written in C/C++ with the HAL to hide low-level details.
 Security: new uniform access model implemented via object manager, and
certified to US DOD level C2.
 Multiprocessor support: most small OS didn’t have this, and traditional kernel
schemes are less well suited.
  Extensibility: because, sometimes, we get this wrong; coupled with the above
point, most directly led to the use of micro-kernel design.
 International support: sell to a bigger market, meant adopting UNICODE as
fundamental internal naming scheme.
 Compatibility with MS-DOS/Windows: don’t want to lose customers, but
achieved partial compatibility only.
 Performance: within the constraints of the other design goals, the system should
be as fast and responsive as possible on each hardware platform.

KERNEL MODE

 Hardware Abstraction Layer (HAL): Layer of software (HAL.DELL) hiding

hardware details, e.g., interrupt mechanisms, DMA controllers, multiprocessor
communication mechanisms. Many implementations to the same interface.
 Kernel: Foundation for the executive and the subsystems, its execution is never
preempted (it can be interrupted, but will always resume)

Four main responsibilities:

1. CPU scheduling: hybrid dynamic/static priority scheduling

2. Interrupt and exception handling: kernel provides trap handling when
exceptions and interrupts are generated by hardware or software. If the trap
handler can't handle the exception, the kernel's exception dispatcher does. Handle
interrupts by either ISR or internal kernel routine.
3. Low-level processor synchronization: spin locks that reside in global memory
to achieve multiprocessor mutual exclusion, normally provided by HAL
4. Recovery after a power failure.

Services, Functions, and Routines

• Win32 API functions: – Documented, callable subroutines

– CreateProcess, CreateFile, GetMessage
• Windows system services (executive system services):
– Undocumented functions, callable from user space
– NtCreateProcess is used by CreateProcess as an internal service
• Windows internal routines:
– Subroutines inside the Windows executive, kernel, or HAL
– Callable from kernel mode only (device driver, NT OS components)
 – ExAllocatePool allocates memory on Windows system heap
• Windows services:
– Processes which are started by the Service Control Manager
– Example: The Schedule service supports the at-command
• DLL (dynamic link library)
– Subroutines in binary format contained in dynamically loadable files
– Examples:
MSVCRT.DLL – MS Visual C++ run-time library
KERNEL32.DLL – one of the Win32 API libraries

NTDLL.DLL
Support library for use of subsystem DLLs:
• System service dispatch stubs to NT executive system services
– NtCreateFile, NtSetEvent
– Most of them are accessible through Win32 Stubs call
servicedispatcher/kernel-mode service in NTOSKRNL.EXE
• Support functions used by subsystems
– Image loader (Ldr...)
– Heap manager
– Win32 subsyst. Comm. func. (Csr...)
– Runtime library func. (Rtl...)
– User-mode asynch. procedure call (APC) dispatcher, exception disp.
Win32 Subsystem
• Environment subsystem process (CSRSS.EXE):
– Console (text) windows
– Creating and deleting processes and threads
– Portions of the support for 16-bit virtual DOS machine (VDM)
– Other func: GetTempFile, DefineDosDevice, ExitWindowsEx
• kernel-mode device driver (WIN32K.SYS):
– Window manager: manages screen output;
– input from keyboard, mouse, and other devices
– user messages to applications
. – Graphical Device Interface (GDI)
• Subsystem DLLs (such as USER32.DLL, ADVAPI32.DLL, GDI32.DLL, and
KERNEL32.DLL)
 – Translate Win32 API functions into calls to NTOSKRNL.EXE and WIN32K.SYS.
• Graphics device drivers
– graphics display drivers, printer drivers, video miniport drivers.

Reference:
https://sritsense.weebly.com/uploads/5/7/2/7/57272303/windows_os.pdf

https://www.cl.cam.ac.uk/teaching/1516/OpSystems/pdf/12-Case-Study-WindowsNT.pdf

https://www.academia.edu/17392324/A_Portable_Kernel-Mode_Resource_Manager_on_Windows_2000_Platforms

http://www.dps.uibk.ac.at/~tf/lehre/ss04old/bs/vorlesungen/WindowsInternals1page.pdf