- Shopping Bag ( 0 items )
Experience Level: Intermediate/ Advanced
Programming in the Windows 95 32-bit environment is where it's at, and this is the book written for experienced 16-bit Windows programmers who want to make the switch and exploit the powerful ...
Ships from: Ossining, NY
Usually ships in 1-2 business days
Ships from: Friendswood, TX
Usually ships in 1-2 business days
Experience Level: Intermediate/ Advanced
Programming in the Windows 95 32-bit environment is where it's at, and this is the book written for experienced 16-bit Windows programmers who want to make the switch and exploit the powerful capabilities of the 32-bit API. You may remember author Richter from his classic Windows 3.1: A Developer's Guide, but even if you don't, this tour of the NT and 95 operating system will give you an inside view on how Windows NT and 95 work and how to use their features. Topics covered include processes, threads, and virtual memory. Also covered are DLLs, file I/O, and message crackers. Find out how the move to 32-bit affects threads and preemptive multitasking, virtual memory management, and memory-mapped files. One prolific programmer called this book "The definitive guide to low-level Win32 programming." Let's put it this way, if you're doing systems level programming, you simply can't do without Advanced Windows.
Now both Microsoft Windows 95 and Microsoft Windows NT have greatly enhanced 32-bit file support for managing the user's files and drives. In fact, both of these operating systems sport an installable file system that is capable of supporting multiple file systems-all of them simultaneously.
The main file system of Windows 95 is the File Allocation Table (FAT) file system. Windows NT also supports the FAT file system. The FAT file system supports file and directory names up to 255 characters long. These names are stored on the disk using Unicode. Using Unicode to store filenames means among other things that files will retain their names when they are copied to systems that use different languages. The FAT file system also associates three time stamps with each file: when the file was created, when the file was last accessed, and when the file was last modified.
In addition to the FAT file system, Windows NT supports the NT file system (NTFS). The NTFS file system offers all of the features of the FAT file system plus some additional ones. The most important feature of NTFS is a file system recovery scheme that allows for quick restoration of disk-based data after a system failure. Other features of NTFS allow you to manipulate extremely large storage media. Several security features, such as execute-only files (which make it far more difficult for a virus to attach itself to an application), have been added. For POSIX compatibility, NTFS supports file system features such as hard links, casesensitive filenames, and the ability to retain information regarding when a file was last opened.
NTFS was designed to be extended. Features that will be supported include transaction-based operations to support fault tolerant applications, user-controlled version numbers for files, multiple data streams per file, flexible options for file naming and file attributes, and support for the popular file servers. For security-minded installations, NTFS will certainly become the standard, and it should eventually replace the FAT file system standard.
The CD-ROM File System (CDFS) is used specifically for a CD-ROM drive, once considered a high-ticket peripheral for a personal computer. Today a CD-ROM drive is becoming more a necessity than a luxury. More and more software is available on CD-ROM-even Windows 95 and Windows NT are available on CD-ROM. In the future, more software programs will use CD-ROMs as their distribution medium because CDROMs offer several advantages:
Microsoft's having built CD-ROM support directly into Windows 95 and Windows NT will certainly help to promote the use and wide acceptance of CD-ROMs in the marketplace.
The best aspect of all these file systems is that they provide simultaneous operating system support. If you are using Windows NT, you can easily have one partition on your hard disk formatted for FAT and another formatted for NTFS. Then you can easily copy files from either of these partitions to a floppy disk formatted for the FAT file system.
Win32's Filename Conventions
So that Win32 can support several different file systems, all the file systems must observe some ground rules. The most important rule is that each file system must organize files into a hierarchical directory tree just as the FAT file system does. Directory names and filenames in the pathname must be separated by the backslash (\) character. In addition to the rules for constructing pathnames, there are rules for constructing directory names and filenames.
THE WIN32 API AND PLATFORMS THAT SUPPORT IT ..... 1
To Dream: The Win32 API ..... 1
Win32s ..... 2
Windows NT ..... 3
Windows 95 ..... 5
Windows CE ..... 5
The Reality: The Win32 API ..... 6
KERNEL OBJECTS ..... 9
What Is a Kernel Object? ..... 9
Usage Counting ..... 10
Security ..... 11
A Process's Kernel Object Handle Table ..... 13
Creating a Kernel Object ..... 14
Closing a Kernel Object ..... 15
Sharing Kernel Objects Across Process Boundaries ..... 16
Object Handle Inheritance ..... 17
Changing the Handles Flag ..... 20
Named Objects ..... 22
Duplicating Object Handles ..... 25
PROCESSES ..... 33
Writing Your First Win32 Application ..... 35
A Process's Instance Handle ..... 38
A Process's Previous Instance Handle ..... 41
A Process's Command Line ..... 42
A Process's Environment Variables ..... 43
A Process's Error Mode ..... 47
A Process's Current Drive and Directory ..... 48
The System Version ..... 50
The CreateProcess Function ..... 51
IpszApplicationName and IpszCommandLine ..... 52
IpsaProcess, IpsaThread, and finheritHandles ..... 54
fdwCreate ..... 56
IpvEnvironment ..... 59
IpszCurDir ..... 59
IpsiStartinfo ..... 59
IppiProcinfo ..... 65
Terminating a Process ..... 66
The ExitProcess Function ..... 67
The TerminateProcess Function ..... 67
All the Threads in the Process Die ..... 68
What Happens When a Process Terminates ..... 68
Child Processes ..... 69
Running Detached Child Processes ..... 71
THREADS ..... 73
When to Create a Thread ..... 73
When Not to Create a Thread ..... 75
Writing Your First Thread Function ..... 77
A Thread's Stack ..... 78
A Thread's CONTEXT Structure ..... 79
A Thread's Execution Times ..... 79
The CreateThread Function ..... 82
Ipsa ..... 83
cbStack ..... 83
IpStartAddr and IpvThreadParm ..... 84
fdwCreate ..... 84
IplDThread ..... 86
Terminating a Thread ..... 86
The ExitThread Function ..... 87
The TerminateThread Function ..... 87
The Process Terminates ..... 88
What Happens When a Thread Terminates ..... 88
Gaining a Sense of One's Own Identity ..... 89
How the System Schedules Threads ..... 92
How Priority Levels Are Assigned Using the Win32 API ..... 94
Altering a Process's Priority Class ..... 98
Setting a Thread's Relative Priority ..... 99
Suspending and Resuming Threads ..... 103
What's Going On in the System ..... 104
Processes, Threads, and the C Run-Time Library ..... 108
C Run-Time Functions to Avoid ..... 113
WIN32 MEMORY ARCHITECTURE ..... 115
A Virtual Address Space ..... 115
How Windows 95 Partitions a Process's Address Space ..... 116
How Windows NT Partitions a Process's Address Space ..... 119
Regions in an Address Space ..... 121
Committing Physical Storage Within a Region ..... 123
Physical Storage ..... 123
Physical Storage Not Maintained in the Paging File ..... 126
Protection Attributes ..... 128
Copy-On-Write Access ..... 129
Special Access Protection Attribute Flags ..... 130
Bringing It All Home ..... 130
Inside the Regions ..... 134
Address Space Differences for Windows 95 ..... 138
EXPLORING VIRTUAL MEMORY ..... 145
System Information ..... 145
The System Information Sample Application ..... 147
Virtual Memory Status ..... 157
The Virtual Memory Status Sample Application ..... 158
Determining the State of an Address Space ..... 166
The VMOuery Function ..... 167
The Virtual Memory Map Sample Application ..... 179
If you are already a 16-bit Windows programmer, you will find that you can start writing Win32 applications after learning just a few simple techniques for porting your existing code. However, these ported programs will not be taking advantage of the powerful and exciting features that the Win32 environments of Windows 95 and Windows NT now offer.
If you are moving from other operating systems (such as UNIX) to Windows NT, this book will explain how you can best take advantage of the features offered by this rich operating system. It is one thing to make an existing application work on Windows NT; it is another thing to create a native version of your application designed specifically for Windows NT. Windows NT has a lot to offer. If you simply make your existing application run on Windows NT, you will not be in a strong competitive position. However, if you rework some of your application to really benefit from Windows NT's features, you'll probably find that you can delete a lot of your existing code and reduce your application's memory requirements while making your application run faster.
After you have started working with Win32, you can begin incorporating more and more of its features into your applications. Many of the Win32 features make it much easier to write programs. And, as I soon discovered when porting some of myown code, I was able to delete large sections of code from my existing programs and replace them with calls to facilities offered by Win32.
These features are such a pleasure to use and work with that I now do Win32 programming exclusively and frequently speak at companies and conferences explaining how to develop effective Win32 applications. This book should help you get ready for developing applications for an environment that is destined to be the industry standard.About the Sample Applications
The purpose of the sample applications is to demonstrate with real code how to use the advanced features of Win32. You could never read enough text to replace the knowledge and experience that you gain by writing your own applications. This has certainly been true of my experience with Win32. Many of the sample applications presented throughout this book are direct descendants of experimental programs that I created in an effort to understand how the Win32 functions behave.Programs Written in C
When it came time to decide on a language for the sample applications, I was torn between C and C++. For large projects, I always use C++--but the fact of the matter is that most Windows programmers are not using C++ yet, and I didn't want to alienate my largest potential audience. So as you'll see, the sample applications are written in C.Message Cracker Macros
If you are not writing your Win32 application using C++ and a Windows class library (such as Microsoft's Foundation Classes), I highly recommend that you use the message cracker macros defined in the WINDOWSX.H header file. These macros make your programs easier to write, read, and maintain. I feel so strongly about the message cracker macros that I have included Appendix B in this book to explain why message crackers exist and how to use them effectively.
None of the programs presented in this book rely on extensive knowledge of 16-bit Windows programs, although experience with 16-bit Windows programming is definitely a plus. The sample programs do assume that you are familiar with the creation and manipulation of dialog boxes and their child controls. Very little knowledge of GDl and Kernel functions is required.
When presenting various topics in this book, I do make behavior comparisons between 16-bit Windows and Win32. If you already understand how 16-bit Windows behaves, you should have an easier time understanding how behaviors have changed in Win32.Running the Sample Applications Under Windows 95
Windows 95 is targeted to run on machines that have only 4 MB of RAM. To accomplish this, Microsoft had to cut some corners when creating Windows 95. For the software developer, this means that some Win32 functions do not have full implementations on Windows 95. With respect to my sample applications, this means that some of the applications have additional functionality when run under Windows NT.
Because of limitations in Windows 95, the following programs run only under Windows NT: ALERTIO.EXE (Chapter 15), IOCMPPRT.EXE (Chapter 15), TINJLIB.EXE (Chapter 18), and COUNTER.EXE (Appendix A). I explain the reasons for doing this when I introduce these programs in their respective chapters.Unrelated Code
I wanted to remove any code from the sample programs that was not directly related to the techniques I wanted to demonstrate. Unfortunately, this is not possible when writing any Windows program. For example, most Windows programming books repeat the code for registering window classes in every application presented in the book. I have done my best to reduce this type of nonrelevant code.
One way that I reduce nonrelevant code is by using techniques that are not always obvious to Windows programmers. For example, the user interface for most of the sample programs is a dialog box. In fact, most of the sample programs have a single line of code in WinMain that simply calls the DialogBox function. As a result, none of the sample programs initialize a WNDCLASS structure or call the RegisterClass function. In addition, only two sample applications--FileChng in Chapter 14 and Counter in Appendix A--have message loops in them.
I have tried to keep the sample applications independent from one another. For example, the memory-mapped files chapter (Chapter 8) is the only chapter containing memory-mapped file sample programs. Because I have structured the sample programs to be independent, feel free to skip earlier chapters and proceed to later chapters.
Occasionally you'll find a sample program that uses techniques or information presented in earlier chapters. For example, the SEHExcpt sample application, presented in the structured exception handling chapter (Chapter 16), demonstrates how to manipulate virtual memory.
I decided to mix these two topics in a single sample program because structured exception handling is a very useful mechanism for manipulating virtual memory. To fully understand this sample application, you should read Chapters 5, 6, and 7 before you examine the SEHExcpt sample application.
One sample application, however, has a little bit of everything: TInjLib, presented in Chapter 18. To fully understand this application, you must have a good understanding of kernel objects, virtual memory, processes, threads, thread synchronization, dynamic-link libraries, structured exception handling, and Unicode. I would say that understanding the TInjLib application qualifies you to go on an interview and say that you really understand Win32 programming.STRICT Compliance
All the sample programs have been compiled with the STRICT identifier defined, which catches frequent coding errors. For example, with the STRICT identifier defined, the passing of an incorrect handle type to a function is caught during compilation instead of at run time. For more information about using the STRICT identifier, refer to the Programming Techniques documentation included in the Win32 SDK.
Error checking should be an integral part of any software project. Unfortunately, proper error checking can make the size and complexity of a software project grow exponentially. To make the sample applications more understandable and less cluttered, I have not put much error checking code into them. If you use any of my code fragments and incorporate them into your own production code, I strongly encourage you to examine my code closely and add any appropriate error checking.
I would love to say that all the sample programs in this book are bug free. But, as with all software, it's only bug free until someone finds a bug. Of course, I have given my own code several walk-throughs in the hope of catching everything. If you do find a bug, I would appreciate your reporting it to me via my Internet address: firstname.lastname@example.org.Tested Platforms and Environments
The bulk of my research and development for this book has been on a machine with two Intel Pentium CPUs. I have also recompiled and tested all the sample programs on a MIPS machine, a DEC Alpha machine, and a PowerPC machine, using the compilers and linkers that come with Microsoft Visual C++ 4.0 for these platforms. All the programs have been tested under both Windows 95 and Windows NT.
Some of the applications use functions that are new to Windows NT 4. Since Visual C++ 4.x shipped prior to Windows NT 4, the Visual C++ header files are missing some of the new function prototypes. This will prevent some of the sample applications from building successfully. To resolve this problem, you must replace the header files that ship with Visual C++ with the header files that ship with the Win32 SDK.
For most of the sample programs, I use no vendor-specific compiler extentions. These programs should compile and link regardless of the machine on which you are running and regardless of which tools you are using to compile and link the sample programs.
However, several of the sample programs do take advantage of some compiler-specific features:
If you are using tools other than those included in Visual C++ 4.0, you will need to discover how your vendor exposes these features and modify the sample programs accordingly.Unicode
Originally I wrote all the sample programs so that they could compile natively using the ANSI character set only. Then, when I started writing the Unicode chapter, I became a very strong believer in Unicode and tried desperately to come up with a sample program for the Unicode chapter. Then the answer came to me: convert all the sample applications in the book so that they demonstrate Unicode. This conversion effort took only four hours and allows you to compile all the sample applications natively for both ANSI and Unicode.
The disadvantage of doing this is that you might see calls to unfamiliar functions that manipulate characters and strings within the sample applications. For the most part, you should be able to guess what that function does if you are familiar with the standard C run-time library functions for manipulating characters and strings. However, if you get stuck, you should refer to the Unicode chapter (Chapter 17). This chapter explains in much greater detail what I have done in the sample programs. It is my hope that you not be confused by the new character and string functions and that you see how easy it is to write your application code using Unicode.
The companion CD-ROM contains the source code for all the sample applications presented throughout this book. In addition, the EXE and DLL files for the x86, MIPS, Alpha AXP, and PowerPC versions of the sample programs are included. Because none of the files on the CD-ROM are compressed, you can simply insert the CD-ROM and load the source code files; you can also run the sample applications directly from the CD-ROM.
On the CD-ROM, the root directory contains the installation software and the CMNHDR.H header file discussed in Appendix C. The root directory also contains several subdirectories. Four of these subdirectories directories are called X86.BIN, MIPS.BIN, ALPHA BIN, and POWERPC.BIN. These subdirectories contain the EXE and the DLL files for their respective CPU platforms. If you are running Windows NT on a platform other than an x86, MIPS, Alpha, or PowerPC, you can still access the source code files, but you will not be able to execute any of the sample applications without building them yourself. This means you will need to install the source code files on your hard disk yourself.
The remaining subdirectories contain the source code files for the sample applications. Each sample application is in its own subdirectory. The eight-letter name of each subdirectory contains the name of the sample program.
If you are interested only in examining the source code or running the sample applications, you do not have to copy anything to your hard disk. However, if you want to modify, compile, or debug the sample applications, you will need to copy the files to your hard disk. The next section explains how to access the sample application files depending on whether you are running Windows 95 or Windows NT.The Accompanying CD-ROM Disc
On Windows NT 4 and Windows 95, inserting the CD-ROM into a drive causes the disc's Welcome application to run automatically. This application allows you to explore the contents of the CD-ROM
Using the application, you can select any of the buttons described in the following table:
Under Windows NT 3.51 and earlier, you must manually invoke the Welcome application by running the Welcome.bat file contained in the root directory of the CD-ROM.