Operating systems Operating systems

Windows

PhD Damian Radziewicz

Wrocław 2017

Why Windows XP? It’s not about windows manager (graphical user interface)

Released by Microsoft in 2001, successor of NT family systems, including Windows 2000;

Integrator of ‘home’ (9x) and ‘office’ (NT) lines of Microsoft’s systems;

XP is short for „eXPerience” (enhanced user experience)

Popularity in August 2012: still popular OS in the world (25%), Win7: 55%, Windows family: almost 85%; Linux: 5.0%, Mac: 8.7% [www.w3schools.com]

Extended support for Windows XP would end on April 8, 2014

Base for Windows XP Embedded (ATMs, airport terminals, …) OS popularity (update 2016)

[wikipedia.org] OS popularity (update 2016)

http://www.techmynd.com/50-plus-blue-screen-of-death-displays-in-public/ NT family: short history

Project started in 1988 (NT3.1 1993, NT4.0 1996)

Microsoft claimed that NT will be ‘New Technology’ system as opposite to former Windows as well as UNIX systems. ‘Bad guys’ pronounced it ‘Not Today, Not Tomorrow, but Nice Try’ 

„...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly)” (by Matt Welsh)

Very complicated driver development for NT thus not so popular as 9x. Inside NT and XP OS Win32 is the main part of the system from the software developer’s point of view;

POSIX.1 subsystem is also available (however, today Microsoft offers SFU - Windows Services for UNIX)

OS/2 API was intended to be native environment, but finally Win32 won (mainly due to popularity of Windows 3.x). OS/2 was removed in XP. Interix (POSIX support)

POSIX: Portable Operating System Interface for Unix – a standard for API, system commands, shell. [$$!] The complete installation of Interix includes (at version 3.5): • Over 350 Unix utilities such as vi, ksh, csh, ls, cat, awk, grep, kill, etc. • A complete set of manual pages for utilities and APIs • GCC 3.3 compiler, includes and libraries • A cc/c89-like wrapper for Microsoft Visual Studio command-line C/C++ compiler • GNU Debugger • X11 client applications and libraries (no X server included though, you can use Xming for example) • Has Unix root capabilities (i.e. setuid files) • Has pthreads, shared libraries, DSOs, job control, signals, sockets, shared memory http://en.wikipedia.org/wiki/Interix XP OS sub-layers

Subsystems (i.e. POSIX, Win32) exist over kernel mode as user-mode subsystems extensibility (but XP natively supports Win32 only)

Processor (hardware) dependent code placed in HAL DLL (hardware abstraction layer) – potentially easier to port OS to different architectures, lower risk for bugs during porting. XP: some features

International support

With NLS API (national language support) it is very easy to use different languages even within the same system and to develop applications with multi-language support

UNICODE natively supported

Multiprocessing

The XP was designed especially for SMP (symmetrical multiprocessing). In fact, GUI responsiveness is acceptable only when at least HT technology is used…

Single-core hardware is not ‘responsive’ with Windows XP! XP: features (2)

Compatibility

Win32 subsystem provides backward compatibility with Win9x systems in most cases with respect to processes protection

Reliability

Comparing to win9x, better protection both on hardware and software resources. XP kernel (microkernel)

Kernel ::= Executive (kernel-mode) + subsystems (user-mode)

Object-oriented: each object (event, mutex, semaphore, thread, timer, interrupt, process, profile) has its own privileges

Microkernel is never preempted nor impacted by the paging (swapping) XP processes: virtual memory

Each process has its own virtual address space

Example: compile and run at least two instances of this code.

Both instances share the same code

In both cases address of ‘variable’ is the same

The value of ‘variable’ in both processes is different, the variable is physically stored in different places. However, virtual address (acquired with & operator) is the same in both cases. NTFS file system

Supersedes FAT and HPFS (used in OS/2)

ACL (Access List Control) based security

Journal of disk operations

Files represented by metadata rather than raw stream of bytes

Links and mounts supported

Volume: similar to logical disk, but can also span across multiple devices, RAIDs, … NTFS and ACLs

Each file or directory can inherit security attributes from parent, or can have its own attributes.

Note: this feature is not available in Home Edition. NTFS: additional security

Files and directories in NTFS can be compressed and AES encrypted (note: this feature is not available in Home Edition).

EFS (Encrypting File System) is transparent to the user.

The symmetric cryptography is used for securing the data, public-key cryptography is used to It is very difficult (nearly impossible) manage symmetric key. to decrypt the data without valid user key, so users must be very careful turning-on this feature! It is highly recommended to use SmartCard (Vista or 7 is required) to store backup certificates for EFS. NTFS vs. FAT FAT is very simple, and thus popular (cameras, memory cards, …). It is compatible with most OSes. FAT requires very low resources (CPU, RAM).

NTFS supports large files (>2/4 GiB), encryption, dynamic volumes, hard- and soft links and user rights (ACLs).

NTFS has journal and is resistant to power-fails.

NTFS has built-in mechanism against fragmentation Win32 subsystem and WinAPI Win32 is the main subsystem in WindowsNT architecture, other subsystems often call Win32 functions

Win32 API is backward compatible with older version of Windows (in most cases)

WinAPI is also supported in mobile / embedded environments

System objects are available as handles

Huge MSDN resources: API documentation, examples, …

Hundreds of functions and special data structures (baggage of backward compatibility)

Almost everything is possible with API functions… if you have enough time

WinAPI can be attractive for RDP applications development and for thin-clients. It does not require .NET frameworks nor even C/C++ libraries. Application can be executed on fresh copy of Windows. Windows programming in C (1) Application can create as many windows as it needs

User can register its own window classes

Message-driven communication between OS and window  this idea can be adopted to embedded OS or OS-like code for small devices

One callback function for processing of window messages

Most of API function prototypes placed in windows.h header file Windows application structure Typical window application consists of class registration, window creation, message loop and message processing function.

Code execution starts from WinMain() function rather than standard main().

Instance handle (HINSTANCE type) represents running process in the system, single EXE file can be executed many times creating multiple running processes in memory. Class registration in WinAPI

Each class is represented by string identifier (i.e. "MyClass")

Many classes already registered, including "BUTTON", "EDIT", …

Window-class is a receipt for easy creation of similar (same class) windows in the future. However, typically application creates exactly one main window. Message processing Message is an unique integer number with 2 optional parameters;

Hundreds of messages are already predefined, user can define own messages, too;

Messages are processed in user-defined callback function;

Minimum code for message processing includes calling PostQuitMessage() on WM_DESTROY and DefWindowProc() on the rest of messages. Message loop Message-is a placeholder for message translators and accelerators (key combinations which can help user navigate through application not only with mouse and menu system, but also with keyboard).

This loop finishes once PostQuitMessage() is executed.

PeekMessage() can be used to determine if a message is waiting in message queue or not, rather than waiting for it with GetMessage(). See many examples of OpenGL applications. Window creation Every window in ‘Windows’ is represented by the handle (HWND);

Every Window belongs to specified class, has initial set of attributes and screen position;

Specify WS_VISIBLE (or call ShowWindow() later) to make the window visible;

Almost every control in Windows (including buttons, menus, desktop) is a… window.

If a window belongs to other window, it is child window (WS_CHILD) Working example Message-driven application Easy-to-handle external events;

No polling mechanism no wasting CPU cycles;

Important assumption: message handler spends only short time in message processing, then returns control to the system;

Exactly one message can be processed at a time – no ‘multitasking related horrors’ (by default, an application is single-threaded);

Difficult to execute time-consuming background tasks within a typical window application;

Almost impossible to call blocking (i.e. I/O) functions inside event handler.

case WM_CREATE: for(;;); break;  'Houston, we have a problem' How to call blocking function within message handler? Try to use non-blocking version of function if possible 

If you really need to call this piece of code: for(;;); consider using threads.

Thread is very similar to process, but instead of being executed in its own, separate data memory area, it shares the same memory with the main process.

In C, thread is a function which is being executed independly on other functions (and possibly exactly at the same time).

This function can access program’s memory, for example global variables.

Remember of volatile modifier in this case! Do we need threads? Most of applications don’t need multiple threads;

Using of threads complicates code (hard or impossible to guess execution order);

Reentrant functions, critical sections, code synchronization is neededmuch more difficult application development;

Single-threaded process can use only one CPU core, while well designed, multi-threaded process can take advantage of using all cores/CPUs at the same time.

Native WinAPI thread functions can be used, but better use pthreads (POSIX threads) library, available for both Windows and Linux for better code portability between platforms. Using Win32 threads

With 4-core CPU, our process can use at most 25% of CPU resources:

It doesn’t mean the system always allocates the same core to the thread. The kernel (task scheduler) gives the process (thread) access to the CPU resources in short time periods. Task switching frequency is very high—user has impression that multiple tasks (applications) are running simultaneously. In fact, most message-driven application just wait for events and don’t use CPU resources. Using Win32 threads

The 5th thread is main process thread (in this case, it just sleeps for 60000ms) Threads and volatiles

In this case, subsequent substitutions are optimized, a=1 and a=2 are ignored by compiler and only a=3 can be observed. b is volatile so it is not optimized, you can observe its all (1, 2, 3) values. WinAPI in C#/.NET and DLLs .NET platform is placed over WinAPI. It is object-oriented overlay for a subset of WinAPI functions

Many WinAPI functions are not available by default, but can be dynamically imported in run-time.

This mechanism uses Dynamic Link Libraries (DLLs)

DLLs are supported by OS (similar mechanism exists in Linux). A process calls LoadLibrary and GetProcAddress functions. A code is loaded to the calling process address space and becomes a part of it until library is unloaded (FreeLibrary).

C# syntax is simple - .NET makes all ‘technical staff’ automatically

[DllImport("user32.dll", CharSet = CharSet.Unicode)] public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);

Now, MessageBox function can be used in C#. Why using DLLs?

Parts of code can be replaced in run-time (while main process is running)

Different languages can be mixed since DLLs is compiled code (C, C++, C#, Java, Matlab, …)

‘Foreign’ functions can be used without access to their source code (for example, commercial computing libraries)

Easy upgrade (patches), without changing (recompiling) main code – only DLL must be replaced. The End