7. Windows

Windows

• Windows

• MS-DOS

• MS-DOS-based Windows

• NT-based Windows

• Modern Windows

Windows 858 CASE STUDY 2: WINDOWS 8 CHAP. 11

Year MS−DOS NotesMS-DOSbasedWindows

NT-basedWindows

ModernWindows

1981 1.0 Initial release for IBM PC1983 2.0 Suppor t for PC/XT1984 3.0 Suppor t for PC/AT1990 3.0 Ten million copies in 2 years1991 5.0 Added memory management1992 3.1 Ran only on 286 and later1993 NT 3.11995 7.0 95 MS-DOS embedded in Win 951996 NT 4.01998 982000 8.0 Me 2000 Win Me was infer ior to Win 982001 XP Replaced Win 982006 Vista Vista could not supplant XP2009 7 Significantly improved upon Vista2012 8 First Modern version2013 8.1 Microsoft moved to rapid releases

Figure 11-1. Major releases in the history of Microsoft operating systems fordesktop PCs.

11.1.1 1980s: MS-DOS

In the early 1980s IBM, at the time the biggest and most powerful computercompany in the world, was developing a personal computer based the Intel 8088microprocessor. Since the mid-1970s, Microsoft had become the leading providerof the BASIC programming language for 8-bit microcomputers based on the 8080and Z-80. When IBM approached Microsoft about licensing BASIC for the newIBM PC, Microsoft readily agreed and suggested that IBM contact Digital Re-search to license its CP/M operating system, since Microsoft was not then in theoperating system business. IBM did that, but the president of Digital Research,Gary Kildall, was too busy to meet with IBM. This was probably the worst blun-der in all of business history, since had he licensed CP/M to IBM, Kildall wouldprobably have become the richest man on the planet. Rebuffed by Kildall, IBMcame back to Bill Gates, the cofounder of Microsoft, and asked for help again.Within a short time, Microsoft bought a CP/M clone from a local company, SeattleComputer Products, ported it to the IBM PC, and licensed it to IBM. It was thenrenamed MS-DOS 1.0 (MicroSoft Disk Operating System) and shipped with thefirst IBM PC in 1981.

Windows 1980s: MS-DOS

• IBM ==> Microsoft: BASIC

• IBM —>CP/M, Gary Kildall

• IBM ==> MS-DOS 1.0

Windows MS-DOS-based Windows

• GUI: Doug Engelbart @ Stanford Research Institute

• Xerox PARC

• Apple Lisa

• Apple Macintosh

• Windows (1985, 1987)

• Windows 3.0 ——1,000,000 copies in 6 months

• Windows 95, 98, Me

Windows MS-DOS-based Windows

• 3.0

Windows MS-DOS-based Windows

• 95

Windows MS-DOS-based Windows

• 98

Windows NT-based Windows

•

• desktop, workstation, enterprise-server

• Intel V.S. RISC

• OS/2, NT OS/2

• NT: New Technology

• CPU

• Windows NT 3.1 Windows 3.0, 95, 98

• 32 32

• Windows NT 4.0, 1996

Windows NT-based Windows

SEC. 11.1 HISTORY OF WINDOWS THROUGH WINDOWS 8.1 861

NT did meet its portability goals, with additional releases in 1994 and 1995adding support for (little-endian) MIPS and PowerPC architectures. The firstmajor upgrade to NT came with Windows NT 4.0 in 1996. This system had thepower, security, and reliability of NT, but also sported the same user interface asthe by-then very popular Windows 95.

Figure 11-3 shows the relationship of the Win32 API to Windows. Having acommon API across both the MS-DOS-based and NT-based Windows was impor-tant to the success of NT.

This compatibility made it much easier for users to migrate from Windows 95to NT, and the operating system became a strong player in the high-end desktopmarket as well as servers. However, customers were not as willing to adopt otherprocessor architectures, and of the four architectures Windows NT 4.0 supported in1996 (the DEC Alpha was added in that release), only the x86 (i.e., Pentium fam-ily) was still actively supported by the time of the next major release, Windows2000.

Win32 application program

Win32 application programming interface

Windows3.0/3.1

Windows95/98/98SE/Me

WindowsNT/2000/Vista/7

Windows8/8.1

Win32s

Figure 11-3. The Win32 API allows programs to run on almost all versions ofWindows.

Windows 2000 represented a significant evolution for NT. The key technolo-gies added were plug-and-play (for consumers who installed a new PCI card, elim-inating the need to fiddle with jumpers), network directory services (for enterprisecustomers), improved power management (for notebook computers), and an im-proved GUI (for everyone).

The technical success of Windows 2000 led Microsoft to push toward the dep-recation of Windows 98 by enhancing the application and device compatibility ofthe next NT release, Windows XP. Windows XP included a friendlier new look-and-feel to the graphical interface, bolstering Microsoft’s strategy of hooking con-sumers and reaping the benefit as they pressured their employers to adopt systemswith which they were already familiar. The strategy was overwhelmingly suc-cessful, with Windows XP being installed on hundreds of millions of PCs over itsfirst few years, allowing Microsoft to achieve its goal of effectively ending the eraof MS-DOS-based Windows.

Windows NT-based Windows

• Windows 2000

• plug-and-play

• network directory services

• improved power management

• improved GUI

Windows NT-based Windows

• 2000

Windows NT-based Windows

• Windows XP

•

•

Windows NT-based Windows

• XP

Windows NT-based Windows

• Windows Vista

• Windows 7

Windows Modern Windows

• Windows 8

•

• WinRT set

• Modern Software Development Kit

Windows Modern Windows

• Windows 8

Windows 8

• —>

• API

• ANSI Unicode

• ——

• App Store…

• Sandbox

Windows 8 SEC. 11.2 PROGRAMMING WINDOWS 865

Hardware abstraction layer (hal.dll)

Hypervisor (hvix, hvax)

Drivers: devices, file systems, network

NTOS executive layer (ntoskrnl.exe)

GUI driver (Win32k.sys)

NTOS kernel layer (ntoskrnl.exe)Kernel mode

User modeNative NT API, C/C++ run-time (ntdll.dll)

NT services: smss, lsass, services, winlogon,

Win32 subsystem process (csrss.exe)

Modern broker processes

Windows Services Windows Desktop AppsModern Windows Apps

Process lifetime mgr

AppContainer

COM

WinRT: .NET/C++, WWA/JS

Modern app mgr

Subsystem API (kernel32)

Dynamic libraries (ole, rpc)

GUI (shell32, user32, gdi32)

[.NET: base classes, GC]

Desktop mgr(explorer)

Figure 11-4. The programming layers in Modern Windows.

of the functions in the WinFX Base Class Library are simply wrappers aroundWin32 APIs. The advantages of WinFX have to do with the richness of the objecttypes supported, the simplified consistent interfaces, and use of the .NET CommonLanguage Run-time (CLR), including garbage collection (GC).

The Modern versions of Windows begin with Windows 8, which introducedthe new WinRT set of APIs. Windows 8 deprecated the traditional Win32 desktopexperience in favor of running a single application at a time on the full screen withan emphasis on touch over use of the mouse. Microsoft saw this as a necessarystep as part of the transition to a single operating system that would work withphones, tablets, and game consoles, as well as traditional PCs and servers. TheGUI changes necessary to support this new model require that applications berewritten to a new API model, the Modern Software Dev elopment Kit, which in-cludes the WinRT APIs. The WinRT APIs are carefully curated to produce a moreconsistent set of behaviors and interfaces. These APIs have versions available forC++ and .NET programs but also JavaScript for applications hosted in a brow-ser-like environment wwa.exe (Windows Web Application).

In addition to WinRT APIs, many of the existing Win32 APIs were included inthe MSDK (Microsoft Development Kit). The initially available WinRT APIswere not sufficient to write many programs. Some of the included Win32 APIswere chosen to limit the behavior of applications. For example, applications can-not create threads directly with the MSDK, but must rely on the Win32 thread poolto run concurrent activities within a process. This is because Modern Windows is

Windows 8 : native NT

• handle

SEC. 11.2 PROGRAMMING WINDOWS 869

access requested. When handles are duplicated between processes, new accessrestrictions can be added that are specific to the duplicated handle. Thus, a processcan duplicate a read-write handle and turn it into a read-only version in the targetprocess.

Not all system-created data structures are objects and not all objects are kernel-mode objects. The only ones that are true kernel-mode objects are those that needto be named, protected, or shared in some way. Usually, they represent some kindof programming abstraction implemented in the kernel. Every kernel-mode objecthas a system-defined type, has well-defined operations on it, and occupies storagein kernel memory. Although user-mode programs can perform the operations (bymaking system calls), they cannot get at the data directly.

Figure 11-7 shows a sampling of the native APIs, all of which use explicithandles to manipulate kernel-mode objects such as processes, threads, IPC ports,and sections (which are used to describe memory objects that can be mapped intoaddress spaces). NtCreateProcess returns a handle to a newly created process ob-ject, representing an executing instance of the program represented by the Section-Handle. DebugPor tHandle is used to communicate with a debugger when giving itcontrol of the process after an exception (e.g., dividing by zero or accessing invalidmemory). ExceptPor tHandle is used to communicate with a subsystem processwhen errors occur and are not handled by an attached debugger.

NtCreateProcess(&ProcHandle, Access, SectionHandle, DebugPor tHandle, ExceptPor tHandle, ...)NtCreateThread(&ThreadHandle, ProcHandle, Access, ThreadContext, CreateSuspended, ...)NtAllocateVir tualMemory(ProcHandle, Addr, Size, Type, Protection, ...)NtMapViewOfSection(SectHandle, ProcHandle, Addr, Size, Protection, ...)NtReadVir tualMemory(ProcHandle, Addr, Size, ...)NtWr iteVirtualMemor y(ProcHandle, Addr, Size, ...)NtCreateFile(&FileHandle, FileNameDescr iptor, Access, ...)NtDuplicateObject(srcProcHandle, srcObjHandle, dstProcHandle, dstObjHandle, ...)

Figure 11-7. Examples of native NT API calls that use handles to manipulate ob-jects across process boundaries.

NtCreateThread takes ProcHandle because it can create a thread in any processfor which the calling process has a handle (with sufficient access rights). Simi-larly, NtAllocateVir tualMemory, NtMapViewOfSection, NtReadVir tualMemory, andNtWr iteVirtualMemor y allow one process not only to operate on its own addressspace, but also to allocate virtual addresses, map sections, and read or write virtualmemory in other processes. NtCreateFile is the native API call for creating a newfile or opening an existing one. NtDuplicateObject is the API call for duplicatinghandles from one process to another.

Kernel-mode objects are, of course, not unique to Windows. UNIX systemsalso support a variety of kernel-mode objects, such as files, network sockets, pipes,

Windows 8 Win32872 CASE STUDY 2: WINDOWS 8 CHAP. 11

Win32 call Native NT API callCreateProcess NtCreateProcessCreateThread NtCreateThreadSuspendThread NtSuspendThreadCreateSemaphore NtCreateSemaphoreReadFile NtReadFileDeleteFile NtSetInfor mationFileCreateFileMapping NtCreateSectionVir tualAlloc NtAllocateVir tualMemoryMapViewOfFile NtMapViewOfSectionDuplicateHandle NtDuplicateObjectCloseHandle NtClose

Figure 11-8. Examples of Win32 API calls and the native NT API calls that theywrap.

Since few changes are made to the existing Win32 interfaces in each release ofWindows, in theory the binary programs that ran correctly on any previous releasewill continue to run correctly on a new release. In practice, there are often manycompatibility problems with new releases. Windows is so complex that a fewseemingly inconsequential changes can cause application failures. And applica-tions themselves are often to blame, since they frequently make explicit checks forspecific operating system versions or fall victim to their own latent bugs that areexposed when they run on a new release. Nevertheless, Microsoft makes an effortin every release to test a wide variety of applications to find incompatibilities andeither correct them or provide application-specific workarounds.

Windows supports two special execution environments both called WOW(Windows-on-Windows). WOW32 is used on 32-bit x86 systems to run 16-bitWindows 3.x applications by mapping the system calls and parameters between the16-bit and 32-bit worlds. Similarly, WOW64 allows 32-bit Windows applicationsto run on x64 systems.

The Windows API philosophy is very different from the UNIX philosophy. Inthe latter, the operating system functions are simple, with few parameters and fewplaces where there are multiple ways to perform the same operation. Win32 pro-vides very comprehensive interfaces with many parameters, often with three orfour ways of doing the same thing, and mixing together low-level and high-levelfunctions, like CreateFile and CopyFile.

This means Win32 provides a very rich set of interfaces, but it also introducesmuch complexity due to the poor layering of a system that intermixes both high-level and low-level functions in the same API. For our study of operating systems,only the low-level functions of the Win32 API that wrap the native NT API are rel-evant, so those are what we will focus on.

Windows 8 Windows

876 CASE STUDY 2: WINDOWS 8 CHAP. 11

Hive file Mounted name UseSYSTEM HKLM \SYSTEM OS configuration infor mation, used by ker nelHARDWARE HKLM \HARDWARE In-memory hive recording hardware detectedBCD HKLM \BCD* Boot Configuration DatabaseSAM HKLM \SAM Local user account infor mationSECURITY HKLM \SECURITY lsass’ account and other security infor mationDEFAULT HKEY USERS \.DEFAULT Default hive for new usersNTUSER.DAT HKEY USERS \<user id> User-specific hive, kept in home directorySOFTWARE HKLM \SOFTWARE Application classes registered by COMCOMPONENTS HKLM \COMPONENTS Manifests and dependencies for sys. components

Figure 11-9. The registry hives in Windows. HKLM is a shorthand forHKEY LOCAL MACHINE.

configuration information should be arranged, and many applications take an adhoc approach. Most users, applications, and all drivers run with full privileges andfrequently modify system parameters in the registry directly—sometimes interfer-ing with each other and destabilizing the system.

The registry is a strange cross between a file system and a database, and yetreally unlike either. Entire books have been written describing the registry (Born,1998; Hipson, 2002; and Ivens, 1998), and many companies have sprung up to sellspecial software just to manage the complexity of the registry.

To explore the registry Windows has a GUI program called regedit that allowsyou to open and explore the directories (called keys) and data items (called values).Microsoft’s Po werShell scripting language can also be useful for walking throughthe keys and values of the registry as if they were directories and files. A more in-teresting tool to use is procmon, which is available from Microsoft’s tools’ Web-site: www.microsoft.com/technet/sysinternals.

Procmon watches all the registry accesses that take place in the system and isvery illuminating. Some programs will access the same key over and over tens ofthousands of times.

As the name implies, regedit allows users to edit the registry—but be verycareful if you ever do. It is very easy to render your system unable to boot, ordamage the installation of applications so that you cannot fix them without a lot ofwizardry. Microsoft has promised to clean up the registry in future releases, butfor now it is a huge mess—far more complicated than the configuration infor-mation maintained in UNIX. The complexity and fragility of the registry led de-signers of new operating systems—in particular—iOS and Android—to avoid any-thing like it.

The registry is accessible to the Win32 programmer. There are calls to createand delete keys, look up values within keys, and more. Some of the more usefulones are listed in Fig. 11-10.