It may seem odd to put history in a technical book, but the history of both UNIX and Windows provides important clues about why they look the way they do today and why they have the system management quirks they do. This is of particular importance for the various UNIX incarnations.
At an abstract level, modern operating systems share several design concepts. Due to the size and complexity of modern operating systems, each consists of a layered design. A core part of the operating system forms the base of the design and directly interacts with the computer hardware. The core layer is usually loaded into memory when the computer boots and stays there throughout. A middle layer (or layers), made up of a suite of libraries and services, form an abstraction of the computer hardware and provide a connection to the core layer. Items in the middle layer may be loaded as needed. Riding on top of these middle layers comes the user shell (or Graphical User Interface - GUI) and the application programs themselves. The layers are protected from each other and connected to each other through specific Application Programming Interfaces (API's). This provides modularity, allowing individual components in a layer to be changed without effecting items in another layer. It also provides a framework for reliability and security through careful control of the interactions between layers.
Modern monolithic kernels extend their designs by allowing additional components, known as loadable modules, to be added to the kernel after it starts running. These loadable modules are used to provide additional features such as the code needed to control less commonly used devices, or 3 rd party software to control new devices. Since a loadable module functions as part of the kernel, care needs to be taken to assure that any module loaded into the kernel is secure. Systems requiring high security will need to disable the capability of loading modules and use a purely monolithic kernel to avoid the possibility of changes to the core functions of the operating system. Linux and Solaris are two examples of monolithic kernel designs that include loadable modules.
Note that the dynamically loaded libraries (DLLs) found in Windows differ significantly from the loadable kernel modules found in some UNIX variants. Loadable modules are specific to a given kernel and one generally cannot have multiple versions available at the same time. DLLs do allow for multiple versions often resulting in mismatched DLLs. These instances of incorrect versions for a DLL and a given operating system kernel or application program, is a common source of problems on Windows systems.
The application architecture is often stated more completely as a combination of the general hardware architecture and the operating system. You will frequently see application architectures described as Linux x86 or Solaris SPARC. Still more detailed specifications such as Linux x86 libc5 or Linux alpha 2.2.17 add the kernel version or libraries needed by the application to the description of the operating system and hardware architecture. The main purpose of these application architecture specifications is help match application binaries to the operating systems and hardware on which they will run.
One of the reasons for the numerous interconnections between branches in the history of UNIX has been the availability of the UNIX source code, either freely or under license, and the ethos of borrowing ideas and sharing modifications and fixes. From the start, UNIX was built by programmers for programmers, and the ability to hack on the operating system itself, fix bugs, add features and share those changes with others has been a core value of the world of UNIX.
UNIX System V evolved from the earlier UNIX System III. This version of UNIX had great influence over the later development of UNIX due the publication by AT&T of the System V Interface Definition (SVID), a complete description of what UNIX was and how it was to behave. With compatibility as their goal, nearly every major UNIX flavor picked up some or all of the features specified in the SVID. Sadly, the publication and acceptance of the SVID did not bring about the unified compatibility it might have. Most of the commercial UNIXes are System V-like (to varying degrees) depending on how closely the vendor followed the published specifications. The result is an annoying list of minor differences where these operating systems might have been more fully compatible Common System V style UNIXes include Solaris, HP-UX, IRIX and AIX. Sun's operating environment, in particular, made a very major switch in 1987 from being SunOS, a BSD-styled UNIX operating system to the System V style UNIX known as Solaris.
From a system administrator's viewpoint, a System V derived UNIX differs from a BSD derived UNIX in a couple of areas. Some command option flags and output are different. The run control files on a System V styled system are numerous, with each one starting just one service. They are stored in a separate directory and links from the files into directories named for the various run levels are used to specify which services to start at given level and the order to start them in. This is covered in greater detail in chapter 4, System Boot and Shutdown Procedures. Finally, System V derived UNIXes use a system of sub-directories and number-letter sequences to name disk and tape devices rather then the flat arrangement found on BSD derived systems.
Linux owes its birth in part to additional restrictions AT&T placed on the use of UNIX source code for teaching. These restrictions led to the development of MINIX, an implementation of UNIX written by Andy Tanenbaum for teaching purposes. MINIX provided the inspiration for Linus Torvalds to write his own implementation of UNIX. The Linux kernel developed by Linus was combined with a suite of UNIX programs, mostly written by the GNU project, into a Linux distribution. When someone talks about Linux, they are most often referring to a distribution, a combination of the Linux kernel and the associated GNU utility programs. Linux distributions are sometimes referred to as GNU/Linux to signify the marriage between the Linux kernel, and the GNU compilers, libraries, and tools. In this book when we refer to Linux, we are referring to a complete distribution, including both the Linux kernel and the GNU tools.
Figure 2-3 in the text shows a simplified history of the popular Windows operating system. While the shift from PC-DOS to Windows was a major event in this history, the more important event for system administrators is the split between Windows 9x and Windows NT. Rather then continuing to extend the PC-DOS based Windows 9x series, Windows NT and it's progeny, Windows 2000 and Windows XP, were built on an all new micro-kernel designed by a team led by David Cutler who had previously led the VMS design group at Digital Equipment Corporation. It should come as no surprise that many of the features one sees in Windows NT such as the user privilege system and access control lists for file access control look very similar to the features one finds in VMS. The Windows 9x series are considered “consumer” operating systems. Their lack of the key features of a modern operating system limit their ability to be effectively managed in a multiuser environment. In the remainder of this book, we will focus on the “comercial” versions of Windows, NT, 2000 & XP.
Windows NT adds Windows versions of several key features associated with UNIX and other modern, multi-user operating systems and not present in the PC-DOS based versions of Windows. These include full memory protection for the kernel and user programs, and facilities for networking and inter-process communications. Windows also adds a number of system services including a scripting engine shared by all applications. The main thing lacking in Windows NT at its initial release was the user interface enhancements and wide range of supported hardware found in the Windows 9x releases. The later history of Windows has been one of unification. With the release of Windows XP, the user interface enhancements and wide range of hardware support have been fully incorporated into the Windows NT based kernel and operating system. This integrated design is not without its problems for the system administrator. Some Windows design choices make the task of securing Windows more difficult. Shared resources such as the visual basic scripting engine, a part of the operating system that is available to every program, have been exploited in a wide number of ways to allow viruses, and other malware to spread widely on the Windows platform. Similarly, shared libraries and services on servers based on the Windows platform have had a poor history with regard to immunity to bugs that have resulted in network visible vulnerabilities. Web site defacements and break-ins are often the result of these vulnerabilities.
Macintosh occupies an import place in history as it served as the inspiration and model for graphical user interfaces that would follow, including Windows and the various X windows based desktops found on UNIX. However, the early versions of Mac OS like the Windows 9x series suffered from their lack of support for the key features of a modern operating system.
After Apple's acquisition of NeXT, the history of MacOS merges into the history of UNIX. The NeXT operating system, NeXTSTEP, is based on the work on Mach, a micro-kernel operating system written at Carnige-Mellon University. Apple developed MacOS X using the modern NeXTSTEP as its base. MacOS X has both the Macintosh user interface and the OpenBSD UNIX interface riding on top of the Mach kernel. From a system administrator's viewpoint, MacOS X appears much like NeXTSTEP. The specialized NeXT utilities such as netinfo are there for basic user, host and network configuration management. The familiar UNIX utilities are very much like they are on a OpenBSD UNIX system. However, there are two important exceptions. The Macintosh user interface is based on Apple's proprietary windowing system, not X windows as found on other UNIX systems. While X windows servers are available for MacOS X, the native window system is proprietary. The second notable difference is the filesystem. The default filesystem of Mac OS X is the Macintosh HFS+ filesystem. HFS+ does not provide all of the filesystem features expected by UNIX, in particular MacOS has differences in where it stores metadata (file permissions and ownerships), filename case sensitivity, and case preservation. These differences create some unexpected situations that can result in security problems.
![Chapter Objectives ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)