Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Mobile operating system wikipedia , lookup
Library (computing) wikipedia , lookup
Copland (operating system) wikipedia , lookup
Microsoft Windows wikipedia , lookup
Windows Mobile wikipedia , lookup
Windows Phone wikipedia , lookup
Criticism of Windows Vista wikipedia , lookup
Windows NT startup process wikipedia , lookup
Windows Phone 8.1 wikipedia , lookup
COVER STORY Operating Systems Your Next OS Architectural Review Low-level design features explain why OS/2 Warp, Windows 95, Windows NT, and Windows 3.1 differ so significantly. By Thomas Mace Today, it’s easy to find fault with the Microsoft Windows 3.x architecture, which was laid down when 286 processors and small amounts of RAM were the norm. But it’s also worth recalling what Windows 3.x brought to the PC: a sophisticated GUI, transparent memory management, scaleable fonts and a unified imaging model, multitasking, and 32-bit virtual device drivers (VxDs)—just to name the most important contributions. Here, we look at the architectural pros and cons of Windows 3.1x and the 32-bit operating systems poised to succeed it. WINDOWS 3.1 X Fundamentally, Windows 3.1x has a 16bit design. Its kernel, most major system components, and native applications are largely implemented in 16-bit code. (Its little-used Win32s API supports 32-bit apps, but it doesn’t support threading.) All native Windows 3.1x applications and all of Windows’ own system DLLs are mapped into a common segmented virtual address space, 4GB in size. All these components are visible to (and often writable by) each other. At the bottom of this address space, usually below the 1MB mark, are the real-mode device drivers that provide an interface to peripheral subsystems such as video cards or printers. Windows 3.11 does use VxDs for the file system, providing a protected-mode path to disk. This stripped-down design provides a very small working set, (the application and system code that must be loaded for any given task), so Windows 3.1x can run well on systems with limited RAM. It also allows for very efficient code execution, since programs can call API functions from within their own memory space. Its drawback is a lack of protection when something goes wrong. Since programs and system components are visible to each other, a buggy program can easily overwrite memory belonging to another process. While Win- COVER STORY Operating Systems dows 3.1x is capable of recovering from some of these general protection faults (GPFs), the outcome is often a systemwide crash. Windows 3.1x runs multiple applications through a simple scheduling mechanism called cooperative multitasking. Under this system, each application is responsible for voluntarily giving up control when it checks its message queue and finds it empty. But if an application fails to check its message queue, either because it is busy or because it hangs, other applications are kept from their share of OS resources. Another frustration Windows 3.1x users have long faced is the limited size of GDI and USER resources. These constraints are due to the fact that the GDI and USER system DLLs use several 64K heaps for storing a variety of arcane data structures created by running applications. When these small heaps fill up, you see an out-of-memory error even with plenty of free memory left. WINDOWS 95 Windows 95 represents an evolutionary development of Windows 3.1x rather than a clean break with the past. While it Comparative OS Architectures: The memory model of each operating WINDOWS 3.1 WINDOWS 95 Windows 3.1 embodies trade-offs between performance and protection that hark back to the days of the 286. While it provides good performance for Win16 applications, DOS applications, real-mode device drivers, and virtual device drivers (VxDs), it offers almost no protection against badly behaved applications. Windows 95 strikes a balance among performance, compatibility, and robustness. It offers fast execution of Win32, Win16, and DOS applications, and it can use realmode device drivers. While it offers better crash protection than Windows 3.1, it remains vulnerable on several fronts. The segmented memory space of a Win16 application is visible to and addressable by all other Win16 applications. Operating-system kernel DLLs and VxDs are also visible to all applications. This design, where a single pool of memory is shared among applications and the OS, provides fast performance as API calls to system DLLs do not entail ring transitions or context switches. The clear disadvantage is that any application can scribble on memory belonging to other applications or operatingsystem components, potentially bringing down the whole system. Win16 applications are cooperatively multitasked. Under this system, the application, rather than the operating system, is responsible for giving up control to the next application. A crashed or misbehaving program can keep all others from receiving system resources. Addresses between 2GB and 4GB are mapped into the address space of each Win32 application and are shared by all processes. Addresses between 3GB and 4GB contain the Ring 0 components, including virtual device drivers (VxDs), the virtual machine management subsystem, and the file management subsystem. This memory area is visible to and writable by Win32 apps. Addresses between 2GB and 3GB contain all Ring 3 Windows system DLLs, such as Kernel, GDI, and User, as well as any Win16 applications. All 16-bit Windows applications run here in a shared address space, where they are cooperatively multitasked. This virtual 16-bit Windows machine is subject to the same vulnerabilities as Windows 3.1. Between 4MB and 2GB, each Win32 app sees a private flat address space; it cannot see any other Win32 processes. Errors occurring here can usually be trapped without bringing down the operating system. Addresses from 0 bytes to 4MB are shared by all processes. This is required for compatibility with real-mode device drivers, TSRs, and some 16-bit Windows applications, but makes it possible for any process to corrupt components residing in those addresses. While the first 64K is not addressable by Win32 applications, it can be addressed and potentially corrupted by 16-bit applications. system a rating COVER STORY Operating Systems brings many significant changes to the 16bit Windows architecture, it also keeps some of its essential features. The result is a hybrid OS, one that can run 16-bit Windows and DOS legacy apps and older real-mode device drivers while supporting true 32-bit applications and 32-bit VxDs. The most important improvements Windows 95 brings include native sup- port for 32-bit multithreaded applications, protected address spaces, preemptive multitasking, far more extensive and efficient use of VxDs, and increased use of 32-bit heaps for storing systemresource data structures. Its most significant drawback is that it is still relatively unprotected from badly behaved applications. Each native Windows 95 application sees a flat 4GB address space containing itself plus the Windows 95 system code and drivers. As far as each 32-bit application is concerned, it is the only application on the PC. The application code loads into this address space from the 4MB to the 2GB mark. Although 32-bit apps can’t see each other, they can pass data to each other via the Clipboard, DDE, and OLE. All 32-bit applications system as seen from the application’s point of view. OS/2 WARP OS/2 Warp offers good performance of native OS/2, 16-bit Windows, and DOS applications while delivering better crash protection than either Windows 95 or Windows 3.1. Because of this, however, it is not compatible with DOS and Windows device drivers. It does not support Win32 applications. OS/2 system code is mapped into the address range between 512MB and 4GB. As in Windows 95, this address space is mapped into and shared by all 32-bit processes. The advantage is that many API calls can be serviced by system code without a costly context switch. The disadvantage is that some system components are exposed to overwriting by malicious applications, causing a systemwide crash. Each native 32-bit OS/2 application sees a flat address space from 0 bytes to 4GB; the application itself is mapped into the first 512MB. An application does not see other 32bit OS/2 applications, although it can communicate with them via cut-and-paste or OS/2 DDE. Native applications and system components are preemptively multitasked at the thread level. Win16 applications can run either in separate Windows VMs or in a common Windows VM. Depending on the version of Warp, the Windows code is provided as system DLLs or by an actual copy of Microsoft Windows 3.1. Separate Windows sessions are preemptively multitasked with other applications. Win16 applications in the common Windows VM are cooperatively multitasked and are unprotected from each other, as in Windows 3.1. OS/2 sees Windows VMs as native 32-bit processes. WINDOWS NT Windows NT’s client/server architecture offers significantly better crash protection than OS/2 or Windows 95. But you’ll need a powerful PC with ample memory to get acceptable performance. Windows NT supports Win16 and DOS applications but does not support real-mode device drivers. Windows NT preemptively multitasks Win32 apps at the thread level. It can execute Win16 applications cooperatively in a shared memory space or preemptively in separate memory spaces for better protection. The address space from 2GB to 4GB contains low-level Ring 0 system kernel code. System pages are not visible to applications. Each Win32 application sees a flat 2GB address space. The app itself is mapped into the region between 64K and 2GB. The first 64K of memory is nonaddressable. The upper region of this application space contains what appear to the application as the Ring 3 system DLLs. These are in fact proxy stub forwarders called client-side DLLs. When the application calls an API function, the client-side DLL passes the call to a separate system-server process. The system server runs in an address space that is invisible to the Win32 application. Here the call parameters are validated and the true system code executes. This design results in a high degree of security, but the ring transitions and context switches required create significant overhead. COVER STORY Operating Systems are preemptively multitasked on a perthread basis. The thread scheduler, a part of the virtual memory management (VMM) system, distributes system time among the pool of current threads based on each thread’s priority level and readiness to run. Preemptive scheduling offers far smoother and more robust multitasking than the cooperative method used in Windows 3.1x. The Windows 95 system code resides above the 2GB mark. In the range of 2GB to 3GB are the Ring 3 system DLLs and any DLLs that are used by multiple programs. (Intel 32-bit processors offer four hardware-enforced protection levels named Ring 0 through Ring 3. Ring 0 is the most privileged.) Windows 95’s Ring 0 components are mapped from 3GB to 4GB. These important, highly privileged pieces of code include the VMM subsystem, the file system, and VxDs. The area of memory from 2GB to 4GB is mapped into the memory space of every 32-bit application so it is shared by all 32bit apps on your PC. This design allows API calls to be serviced directly within the application’s address space, and it limits the size of the working set. The downside is compromised robustness. There is nothing to stop a buggy application from scribbling on addresses belonging to system DLLs, crashing the entire show. The area from 2GB to 3GB also contains any 16-bit Windows applications you may be running. For compatibility reasons, these execute in a shared address space, where they can corrupt each other just as they can in Windows 3.1x. The memory addresses below 4MB are also mapped into the address space of each application and are shared by all processes. This makes compatibility with existing real-mode device drivers possible, since they require access to those addresses. It also opens up another area of the memory map to malicious scribbling. The very bottom 64K of this address space is not addressable by 32bit applications, in order to catch faulty pointers, but it is addressable by potentially buggy 16-bit applications. Some Windows 95 system DLLs, USER and GDI in particular, still con- 1/2 horizontal ad tain 16-bit code. One unfortunate result of this is that USER’s and GDI’s 64K local heaps and their attendant systemresource limitations are still with us. Fortunately, Windows 95 did move a number of data structures into 32-bit heaps, making it far harder to run out of system resources than under Windows 3.1x. Another problem raised by 16-bit system code is the Win16Mutex effect. Since 16bit system code is nonreentrant, only one thread can access 16-bit DLL functions at a time, potentially hobbling other processes that need access to the DLL in question. OS/2 WARP OS/2 Warp Connect 3.0 is architecturally similar to Windows 95 in many ways, though its design philosophy makes fewer compromises with 16-bit legacy code. The result is a better-protected OS than Windows 95 that can run OS/2, Win16, and DOS programs, but that is incompatible with 16-bit Windows device drivers. OS/2 Warp doesn’t support 32-bit Windows apps. Native 32-bit OS/2 applications see a COVER STORY Operating Systems 4GB private address space. Application code is mapped into the range from 0 to 512MB while the OS/2 system code is mapped from 512MB to 4GB. This system code area is shared by all processes. Executing 32-bit apps do not see each other although they can communicate via cut-and-paste or OS/2 DDE. OS/2 Warp preemptively multitasks native applications on a per-thread basis. This design provides many of the same benefits and drawbacks found in Windows 95. System resources are allocated smoothly, and calls to system APIs can be serviced without costly overhead, since the system DLLs are in the same address space as the calling application. The working set is also kept to a reasonable size, since multiple instances of system DLLs are not required. But protection is not guaranteed because badly behaved applications can still overwrite important system areas. OS/2 Warp does go beyond Windows 95 in important ways, however. Problems with system-resource limitations are unknown, since OS/2 Warp does not use 64K heaps to store system DLL data structures. It also provides several services unknown to Windows including the System Object Model (SOM) and REXX, a powerful batch language used on a wide variety of IBM platforms. In addition to hosting native OS/2 applications, OS/2 Warp can run 16-bit Windows apps. Depending on which version you buy, OS/2 Warp does this either by running a copy of Microsoft Windows 3.1 as a process under OS/2 or by running its own Win-OS/2 libraries. With either, you have the choice of running a Windows session for each Windows program or running all Windows programs in a shared address space. The latter approach may offer better compatibility but promises less stability, since it functions essentially like Windows 3.1x. OS/2 Warp can also run DOS applications in highly configurable, preemptively multitasked DOS virtual machines. OS/2 was not architected to support real-mode device drivers, so your hardware devices must be natively supported by OS/2 drivers. The advantage to this ap- 1/2 horizontal ad proach is that OS/2 can fully protect the first 4MB of the application memory map, an area where Windows 95 remains vulnerable to crashes. WINDOWS NT WORKSTATION Windows NT Workstation 3.51 is essentially a server operating system optimized for workstation use. This explains an architecture where absolute protection of applications and data take precedence over speed and compatibility considerations. Windows NT’s extreme robustness comes at the price of high system overhead, so a fast CPU and at least 16MB of RAM are needed for acceptable performance. Like OS/2 Warp, Windows NT achieves low-memory security at the price of being incompatible with realmode device drivers. Windows NT runs native 32-bit NT applications and most Windows 95 applications, too. Like Windows 95 and OS/2 Warp, Windows NT can also host 16-bit Windows and DOS applications. The design of Windows NT’s memory map is strikingly different from those of COVER STORY Operating Systems Windows 95 and OS/2 Warp. Native applications see a private 2GB address space running from 64K to 2GB (the first 64K is fully nonaddressable). Applications are invisible to each other, though they can communicate via the Clipboard, DDE, and OLE. At the top of each 2GB application space are what appear to the application as Ring 3 system DLLs. In fact, these are merely proxy stub forwarders called client-side DLLs. When the application calls most API functions, the client-side DLL issues a Local Process Communication (LPC), which passes the call and associated parameters to an entirely separate address space that contains the true system code. This server process performs parameter validation, executes the requested function, and passes the results back into the application’s memory space. Although the server process itself is an application-level process, it is fully protected from and invisible to the application that called it. From the 2GB to the 4GB mark are Windows NT’s low-level Ring 0 system components including the kernel, thread scheduling, and the virtual memory manager. System pages in this region are marked with Supervisor privileges that are physically enforced by the processor’s ring protection scheme. This keeps lowlevel system code from being visible to or writable by application-level code—and exacts a performance penalty when ring transitions occur. Windows NT provides Windows on Windows (WOW) sessions for running 16-bit Windows applications. As with OS/2 Warp, Windows NT can run 16-bit Windows programs individually in private memory spaces or together in a shared address space. In almost all cases, 16-bit and 32-bit Windows applications can intercommunicate freely using OLE (via thunks when needed), regardless of whether they run in private or shared memory. Native applications and WOW sessions are preemptively multitasked on a per-thread basis. Multiple 16-bit Windows applications in a single WOW session are cooperatively multitasked. Windows NT can also multitask multiple DOS sessions. Because Windows NT is a fully 32-bit design, there are no theoretical limits to GDI and USER resources.