Table of Contents
| Acknowledgments | |
| Introduction | |
| Pt. I | Windows, Visual C++, and Application Framework Fundamentals | |
| Ch. 1 | Microsoft Windows and Visual C++ | 3 |
| Ch. 2 | The Microsoft Foundation Class Library Application Framework | 17 |
| Pt. II | The MFC Library View Class | |
| Ch. 3 | Getting Started with AppWizard - "Hello, world!" | 31 |
| Ch. 4 | Basic Event Handling, Mapping Modes, and a Scrolling View | 47 |
| Ch. 5 | The Graphics Device Interface, Colors, and Fonts | 75 |
| Ch. 6 | The Modal Dialog and Windows Common Controls | 103 |
| Ch. 7 | The Modeless Dialog and Windows Common Dialogs | 147 |
| Ch. 8 | Using ActiveX Controls | 165 |
| Ch. 9 | Internet Explorer 4 Common Controls | 195 |
| Ch. 10 | Win32 Memory Management | 217 |
| Ch. 11 | Bitmaps | 231 |
| Ch. 12 | Windows Message Processing and Multithreaded Programming | 267 |
| Pt. III | The Document-View Architecture | |
| Ch. 13 | Menus, Keyboard Accelerators, the Rich Edit Control, and Property Sheets | 287 |
| Ch. 14 | Toolbars and Status Bars | 323 |
| Ch. 15 | A Reusable Frame Window Base Class | 349 |
| Ch. 16 | Separating the Document from Its View | 367 |
| Ch. 17 | Reading and Writing Documents - SDI Applications | 413 |
| Ch. 18 | Reading and Writing Documents - MDI Applications | 445 |
| Ch. 19 | Printing and Print Preview | 469 |
| Ch. 20 | Splitter Windows and Multiple Views | 491 |
| Ch. 21 | Context-Sensitive Help | 505 |
| Ch. 22 | Dynamic Link Libraries | 527 |
| Ch. 23 | MFC Programs Without Document or View Classes | 557 |
| Pt. IV | Active X: Com, Automation, and Ole | |
| Ch. 24 | The Component Object Model | 569 |
| Ch. 25 | Automation | 613 |
| Ch. 26 | Uniform Data Transfer - Clipboard Transfer and OLE Drag and Drop | 687 |
| Ch. 27 | Structured Storage | 717 |
| Ch. 28 | OLE Embedded Components and Containers | 745 |
| Ch. 29 | Introducing the Active Template Library | 799 |
| Ch. 30 | ATL and ActiveX Controls | 849 |
| Pt. V | Database Management | |
| Ch. 31 | Database Management with Microsoft ODBC | 897 |
| Ch. 32 | Database Management with Microsoft Data Access Objects | 929 |
| Ch. 33 | The OLE DB Templates | 955 |
| Pt. VI | Programming for the Internet | |
| Ch. 34 | TCP/IP, Winsock, and WinInet | 985 |
| Ch. 35 | Programming the Microsoft Internet Information Server | 1029 |
| Ch. 36 | ActiveX Document Servers and the Internet | 1055 |
| Ch. 37 | Introducing Dynamic HTML | 1075 |
| Ch. 38 | Visual C++ for Windows CE | 1091 |
| App. A | Message Map Functions in the Microsoft Foundation Class Library | 1111 |
| App. B | MFC Library Runtime Class Identification and Dynamic Object Creation | 1119 |
| Index | 1125 |
Read an Excerpt
The Transmission Control ProtocolYou've learned about the limitations of UDP. What you really need is a protocol that supports error-free transmission of large blocks of data. Obviously, you want the receiving program to be able to reassemble the bytes in the exact sequence in which they are transmitted, even though the individual datagrams might arrive in the wrong sequence. TCP is that protocol, and it's the principal transport protocol for all Internet applications, including HTTP and File Transfer Protocol (FTP). Figure 34-6 shows the layout of a TCP segment. (It's not called a datagram.) The TCP segment fits inside an IP datagram, as shown in Figure 34-7.
The TCP protocol establishes a full-duplex, point-to-point connection between two computers, and a program at each end of this connection uses its own port. The combination of an IP address and a port number is called a socket. The connection is first established with a three-way handshake. The initiating program sends a segment with the SYN flag set, the responding program sends a segment with both the SYN and ACK flags set, and then the initiating program sends a segment with the ACK flag set.
After the connection is established, each program can send a stream of bytes to the other program. TCP uses the sequence number fields together with ACK flags to control this flow of bytes. The sending program doesn't wait for each segment to be acknowledged but instead sends a number of segments together and then waits for the first acknowledgment. If the receiving program has data to send back to the sending program, it can piggyback its acknowledgment and outbound data together in the same segments.
The sending program's sequence numbers are not segment indexes but rather indexes into the byte stream. The receiving program sends back the sequence numbers (in the acknowledgment number field) to the sending program, thereby ensuring that all bytes are received and assembled in sequence. The sending program resends unacknowledged segments.
Each program closes its end of the TCP connection by sending a segment with the FIN flag set, which must be acknowledged by the program on the other end. A program can no longer receive bytes on a connection that has been closed by the program on the other end.
Don't worry about the complexity of the TCP protocol. The Winsock and WinInet APIs hide most of the details, so you don't have to worry about ACK flags and sequence numbers. Your program calls a function to transmit a block of data, and Windows takes care of splitting the block into segments and stuffing them inside IP datagrams. Windows also takes care of delivering the bytes on the receiving end, but that gets tricky, as you'll see later in this chapter.
The Domain Name System
When you surf the Web, you don't use IP addresses. Instead, you use human-friendly names like microsoft.com or www.cnn.com. A significant portion of Internet resources is consumed when host names (such as microsoft.com) are translated into IP addresses that TCP/IP can use. A distributed network of name server (domain server) computers performs this translation by processing DNS queries. The entire Internet namespace is organized into domains, starting with an unnamed root domain. Under the root is a series of top-level domains such as com, edu, gov, and org.
Servers and Domain Names
Let's look at the server end first. Suppose a company named SlowSoft has two host computers connected to the Internet, one for World Wide Web (WWW) service and the other for FTP service. By convention, these host computers are named www.slowsoft.com and ftp.slowsoft.com, respectively, and both are members of the second-level domain slowsoft, which SlowSoft has registered with an organization called InterNIC. (See http://ds.internic.net.)
Now SlowSoft must designate two (or more) host computers as its name servers. The name servers for the com domain each have a database entry for the slowsoft domain, and that entry contains the names and IP addresses of SlowSoft's two name servers. Each of the two slowsoft name servers has database entries for both of SlowSoft's host computers. These servers might also have database entries for hosts in other domains, and they might have entries for name servers in third-level domains. Thus, if a name server can't provide a host's IP address directly, it can redirect the query to a lower-level name server. Figure 34-8 illustrates SlowSoft's domain configuration.
Clients and Domain Names
Now for the client side. A user types http://www.slowsoft.com in the browser. (The http:// prefix tells the browser to use the HTTP protocol when it eventually finds the host computer.) The browser must then resolve www.slowsoft.com into an IP address, so it uses TCP/IP to send a DNS query to the default gateway into an IP address for which TCP/IP is configured. This default gateway address identifies a local name server, which might have the needed host IP address in its cache. If not, the local name server relays the DNS query up to one of the root name servers. The root server looks up slowsoft in its database and sends the query back down to one of SlowSoft's designated name servers. In the process, the IP address for www.slowsoft.com will be cached for later use if it was not cached already. If you want to go the other way, name servers are also capable of converting an IP address to a name....
loading...