Windows System Programming Third Edition [Electronic resources] نسخه متنی

64-Bit Architecture Overview

From a programmer's perspective, the major issue in migrating from 32-bit to 64-bit programming models is that pointers and system data types such as size_t and time_t can now be 64 bits long. Therefore, process virtual address space is no longer limited to 4GB (actually, only 3GB is directly available to applications). Thus, Win32 to Win64 migration can be regarded essentially as a "pointer and data stretch" and, within the Windows model, there is very little effect on user data.

The Need for 64-Bit Addressing

Many applications require the ability to access large address spaces. Examples, such as the following, are numerous.

• Imaging applications.
  A system with 4GB yields only about 20 seconds of high-definition television (HDTV) with true color.

• Mechanical and electronic computer-aided design (MCAD and ECAD).
  Part assemblies for complex components require more than 3GB to be represented, and chip design simulations are extremely memory-intensive.

• Databases and data warehousing.
  It is not uncommon to use files of hundreds of gigabytes, and similar amounts of virtual address space simplify the file processing.

Physical systems can now support this demand for large address spaces. For some time, 64-bit microprocessors have been available, and many systems support large physical memories at reasonable cost.

The same factors that make huge files (larger than 4GB) desirable and necessary also drive the need for 64-bit addressing, and now that sufficiently powerful Itanium, AMD64, and 64-bit extension microprocessors are available, it is only natural that Windows should evolve to meet this need. A 64-bit OS is essential if Windows is to play a significant role in enterprise and high-end computing.

Nonetheless, many 32-bit applications will continue to work well and will not require early migration. Personal productivity applications, such as Microsoft Office and Adobe FrameMaker, will probably not require 64-bit migration for some time. Consequently, Windows will support backward compatibility.

Current 64-bit processors frequently provide performance gains, as would be expected, but these gains do not directly impact programming at the source level.

The UNIX Experience

PC systems have always lagged behind mainframe and UNIX systems in terms of core functionality and scalability. The same is true of 64-bit architectures.

• Major UNIX vendors have provided 48-bit and 64-bit microprocessors since the early 1990s.

• The major UNIX vendors have supported 64-bit APIs during the same time period.

• The UNIX community has standardized on the so-called LP64 model, which is different from Win64's P64 model, as will be described later.

• Migrations from 32 to 64 bits have been relatively straightforward, if not always trivial, and the same can be expected of Win32 to Win64 migration.

The Windows 16-Bit to 32-Bit Experience

The Windows 16-bit to 32-bit migration started in the early 1990s with the introduction of Windows NT, and the migration picked up momentum when Windows 95 became commonplace. Although it is tempting to say that we will see a replay of the same history, there are differences.

• Windows NT and 95 were the first widely used "real" PC OSsthat is, these two systems supported demand paging, threads, preemptive scheduling, synchronization, and many other features described in Chapter 1.

• While Win32 greatly expanded the useful address space, as does Win64, the advance was more than that. Obsolete and awkward, but popular, extended memory models were replaced. Although Windows 2000 introduced one similar extended memory model (not described in this book), the overall change is not as significant.

• Win32 introduced extensive new functionality, whereas Win64 does not.

Are 64 Bits Enough?

Within the PC world where Windows originated, one could argue that the original 16-bit Intel x86 model (which actually provided 20 bits of address space) lasted for more than a decade and that the 32-bit architecture has already lasted as long. However, the move to Win64, and 64-bit programming in general, has been much slower than the move to 32 bits. In both cases, however, minicomputers and servers moved to the next level at least 10 years before PCs made the same move. It's now natural to ask if there will be a future move of servers or even PCs to 128 bits. I would contend that any such extension is more than 10 years into the future simply because of the sheer magnitude of a 64-bit address space.

Predictions are precarious, however, but we could, only half seriously, invoke the oft-quoted Moore's Law to the effect that cost/performance is halved every 18 months. In turn, speed and capacity approximately double every 18 months. Applying this argument to address space, we need one extra bit of address space every 18 months, implying that the 64-bit model should be good for 48 years (nearly as long as the history of modern computing). Whether or not this informal argument, which I have seen in a formal presentation, will hold remains to be seen. However, PC resource requirements in the past have grown faster than this argument would predict.