Introduction
This book is the first-hand drive development materials summarized by the author based on years of work and study experience. This book is more about experience, and some small discoveries and accidents in practice add color to the content of the book. One of the characteristics of this book is to make more cuts into the WDF framework.
This book is the first-hand drive development information summarized by the author based on years of work and learning experience. This book is more about experience, and some small discoveries and accidents in practice add color to the content of the book.
One of the characteristics of this book is to make more cuts into the WDF framework. The first main content of this book is (Chapters 3-7) discussing WDF, with different focuses. Chapter 3 takes the framework as the center of discussion; Chapters 4 and 5 use WDF framework to develop USB and 1394 drivers; Chapter 6 describes the kernel C++ programming, and also uses the WDF framework as a model; Chapter 7 describes the testing and debugging of WDF drivers .
The second main content is about audio and video driver development (Chapters 10 to 11). Audio and video drivers include the AVStream architecture, which is explained in more detail in this book. Chapter 10 describes the use of the AVStream portlet architecture, and Chapter 11 describes the development of ASIO audio drivers.
The third main content is about device driver installation (Chapters 12 to 14). Chapter 12 talks about the system installation module, explaining how the system and device drivers work well together from an overall perspective; Chapter 13 describes the details of the INF installation file, including the role of each domain, and the use of many installation instructions. Chapter 14 talks about how to write driver installation software.
The remaining chapters are about driver introduction (Chapters 1 and 2), Windbg debugging commands (Chapter 8), and kernel synchronization (Chapter 9).
This book is suitable for general entry-level kernel programmers who are interested in WDF and are preparing to develop USB or 1394 device drivers. This book is especially useful. This book also has a certain reference value for programmers who have been in the industry for a long time and are experienced.
Media Recommendation
This book "The Path of the Bamboo Forest-Understanding Windows Driver Development" is the latest masterpiece of the three authors Zhang Pei, Ma Yong and Dong Jianyuan. They put themselves in practice The accumulated experience is organized into a book, in the hope that scholars can avoid detours and shorten the learning path of Windows driver development. This book focuses on the development of KMDF, USB/1394 and audio drivers, as well as the distribution and installation of device drivers. Readers who have a certain foundation in Windows driver development are recommended to take a look at this book, especially if you are planning to use KMDF, or are engaged in programming work related to USB/1394 or audio drivers, then this book is A valuable practical guide.
——Pan Aimin, author of "Windows Kernel Principles and Implementation"
I am very happy to see that another original driver development book will be published soon, although there are already some books in this area. , But there are still many topics that have not been covered. This book discusses in detail the use of C++ development drivers, audio drivers, kernel streams and other topics that are rarely covered by other books. It fills the gaps in these areas and is hereby recommended! p>
——The author of Zhang Yinkui's "Software Debugging"
Zhang Pei is my good friend in the circle of "drive development", he is also one of the earliest programmers I know of doing WDF driver programs in China One, we often discuss the knowledge of driving development. Windows driver development belongs to low-level development, so the changes have not been too big. However, the change from WDM framework to WDF framework is the most "violent". Now the drivers of well-known manufacturers have migrated from the WDM framework to the WDF framework. This book should be the first book in China that introduces the WDF framework in detail. When I read the first draft for the first time, I really had the joy of enlightenment. I hope this book can lead more driver enthusiasts into this field.
——Zhang Fan, author of "Detailed Explanation of Windows Driven Development Technology"
About the author
Zhang Pei, born in 1982 in Yangzhong, Jiangzhong Island, Jiangsu, has been working since Engaged in kernel driver development. It is quite difficult to learn at first, and I still hesitate to this day. During the learning process, I got a lot of selfless help from my friends. After I have learned something, I am also willing to write and comment to spread to more fans-this book comes from this. Currently working at AMD Shanghai R&D Center.
Ma Yong, screen name znsoft, founder of Drive Development Network. Focus on file system drive research, good at document transparent encryption related technology and software architecture design. Engaged in drive development and R&D management for more than ten years, currently working in Kaixin Security Laboratory.
Dong Jianyuan, C/C++, assembly programmer. Born in Shandong in 1986. After graduating from university, he is engaged in the development and design of various system software. Currently engaged in the development of Windows kernel in Jinan. I love reading, literature, Go and martial arts, and I am particularly obsessed with writing operating systems. I was fortunate to participate in the compilation of some of the basic chapters of this book.
Recommendation 1
I always think that writing a program is a wonderful thing, it can bring the desire to create and control. Whenever I read or write a piece of code, I naturally imagine how this piece of code completes the predetermined logic. When faced with an unfamiliar development environment or a new basic platform, you must first understand how the environment or platform works and what functions it provides. The code itself may be very complex or even mysterious, but in general, the truly beautiful high-quality code is often simple and easy to understand. For code writers or maintainers, the real kung fu is not in the code itself, but in the understanding and control of the underlying development platform, which may be commonly known as "internal strength."
This view applies to both application software programmers and system software programmers. For application software programmers, low-level application development platforms are the basis for supporting application development, for example, Windows applications are developed based on the Windows SDK. Then, it is necessary for the programmer to understand the basic elements in the Windows SDK, such as the message distribution mechanism and various graphics functions. In this case, reading some typical example program codes can often lead to a quick start. Similarly, if C/C++ programmers are limited to the C/C++ language itself, it is difficult to write high-quality utility programs. They must not only master the usage of functions and types in the C/C++ runtime, but also understand the implementation mechanism of these functions and types. Even libraries at the source code level, such as STL (C++ Standard Template Library), need to understand their code implementation in order to use these libraries flexibly (such as various container data structures, iterators or algorithms in STL).
So, what is "internal strength" for system software programmers? System software refers to the operating system itself or software attached to the operating system to provide services for application software. The system software may have the opportunity to directly deal with the hardware, which gives programmers stronger control ability, they have the opportunity to intervene in the behavioral logic of the operating system, and even change the behavioral characteristics of the operating system. But with it comes higher requirements for the system software code. Modern operating systems provide application software with strong fault tolerance. The failure of application programs usually does not affect the stability of the operating system itself, but the operating system’s fault tolerance to system software is relatively limited. After all, the system software may run. It is integrated into the execution logic of the operating system and becomes a part of the operating system. Therefore, understanding and mastering the operating mechanism of the operating system has become the basic prerequisite for system programmers to write correct and efficient system software. The so-called "internal strength" is here.
Developing software on the Windows platform, writing the Windows kernel driver is the most test of the programmer's "internal strength". The amount of code of the kernel driver is usually not large, but any function in the driver framework, or even any line of code in these functions, may contain complex logic or implicit requirements and assumptions. Even if the driver writer is in a purely self-defined function, he must carefully pay attention to some environment-related factors, such as whether the code can be interrupted, whether it can be reentered, or whether the referenced memory is swapped to external memory. On the other hand, many concepts in application software development, such as address space, memory management, exception handling, and multithreaded concurrency, may require different understanding methods in driver development. In addition, the commonly used C runtime library functions are basically no longer suitable for drivers, and driver writers must face a new underlying environment and support platform. Therefore, to write a driver that can run correctly, the programmer must not only clearly understand the target device or function (which may include various characteristics of the hardware device) that the driver is aimed at, but also master how the Windows kernel interacts with the driver , And many management and operation mechanisms in the kernel, especially memory management, thread scheduling and concurrency control.
When the Windows kernel drivers are loaded into the kernel and started, they become a part of the Windows kernel. The interface functions in the driver are called by the kernel at the right time. This is the Windows driver's Basic working method. Microsoft defines WDM (Windows Driver Model) to specify the structure of the driver and how the Windows kernel interacts with WDM drivers. WDM not only includes the driver framework defined by the I/O manager, but also defines how to support PnP (Plug and Play), power management and WMI (Windows Management Instrumentation) in the driver. Therefore, if you want to write a driver that fully supports WDM, you also need to understand the various core components involved in WDM.
The close relationship between the Windows kernel driver and the kernel makes the debugging of the driver extremely inconvenient. In a sense, the debugging of the driver is equivalent to the debugging of the Windows kernel. Moreover, for some specific logic errors, the kernel debugger is even powerless. For this reason, the code of the kernel driver should be as streamlined as possible. From the perspective of software design, the function code should be put into the application to the greatest extent, leaving only the most necessary function logic in the driver. This design can also make the Windows kernel be implicated by incorrect driver code and cause stability problems.
In order to facilitate the development of Windows drivers, Microsoft has defined a driver framework called WDF (Windows Driver Foundation), and the part for the kernel driver is called KMDF (Kernel-Mode Driver Framework). KMDF is actually a library, which encapsulates some basic code logic in WDM, so that programmers can write WDM drivers more conveniently. KMDF can partially simplify the task of developing the Windows kernel driver, but in essence it does not reduce the complexity of the kernel driver, and even requires programmers to pay extra learning efforts.
In short, as a system programmer, you need to have insight into the various components of the target operating system that interact with your software, and you must also know very clearly how the development tools you rely on can help you do it. At this point. System programmers often face a longer learning curve than application programmers. However, the fun that system programmers get from writing programs is also difficult to experience at the application layer. I believe that when you find that the software module you have written has been integrated with the operating system kernel, at that moment you must feel that you are holding an operating system in your palm-the operating system is under your control.
This book "The Path of the Bamboo Forest-Explaining Windows Driver Development in a Simple Way" is the latest masterpiece of three authors Zhang Pei, Ma Yong and Dong Jianyuan. They have compiled their accumulated experience in practice into a book. It is hoped that later scholars can avoid detours and shorten the learning path of Windows driver development. This book focuses on the development of KMDF, USB/1394 and audio drivers, as well as the distribution and installation of device drivers. Readers who have a certain foundation in Windows driver development are recommended to take a look at this book, especially if you are planning to use KMDF, or are engaged in programming work related to USB/1394 or audio drivers, then this book is A valuable practical guide.
Pan Aimin
December 5, 2010 in Xierqi, Beijing
Recommend Preface II
I know a shareware The author has been developing his virtual CD-ROM software for the past ten years, adding something new to this software from time to time. I felt very strange about this, and told him, I think the virtual CD-ROM drive is a very simple thing. Use an image file to hold the data on the CD, and develop a set of drive interface to make the system think it is a CD drive. Download the open source code online, it should not exceed 5000 lines. Why did he spend so many years on this?
He cited an example: Daemon, a well-known virtual CD-ROM drive abroad, has its strength in compatibility. Almost any software can use its virtual CD-ROM drive normally and access it as a real CD-ROM drive. Many common open source virtual CD-ROM drives are not supported.
He once found a game that required the user to insert a CD. It is always impossible to simulate with a virtual CD-ROM drive written by him. The same image file, everything is OK if you change Daemon. This surprised him greatly. In such a situation, it is impossible for him to search the Internet for the silly question "Why does my virtual CD-ROM drive not support certain games", and it is impossible for him to find a copy of a piece of code somewhere to solve it. He must find the essence of the problem in order to find a countermeasure.
It took a long time, and the final analysis result is that because the game wants every user to buy a genuine CD, it uses a special strategy to analyze whether the user is using real Optical drive. Everyone knows that the read speed of a hard disk is generally faster, and in fact it is more stable. The speed of CD-ROM reading is relatively slower than that of hard disk, and the speed of reading data has certain instability. For example, the rate of data reading may fluctuate following the curve defined by a certain mathematical model. And this software checks based on the degree of matching of this instability. If the data provided by the virtual CD-ROM does not match this feature, it simply prohibits the game from continuing.
Daemon inserts such an analog function inside, deliberately processing various delays on the data readout, making it look very similar to the data read by a real CD-ROM drive.
In short, what he developed is a good thing that is close to the world's top quality. Of course the price is sweat and time.
I can imagine that in the absence of any public code, or the experience guidelines of the predecessors, to delve into the difficulties of discovering and solving these problems by myself. The problem that can find a solution on the Internet will certainly not be a key problem in software technology. On the contrary, it is such a headless case that constitutes the so-called "core technology" of programmers.
I have different opinions from some people. I don't think that the lower the technology, the more "core" it is. Some people always think that the system is more "core" than the software. And the chip is lower than the program, and the chip is more "core". In fact, silicon wafers are lower than chips, and sand is lower than silicon wafers. Is sand the core technology?
I think that in any field, you can conduct persistent research. When most people choose to give up, and you still persevere in learning, researching, and solving practical problems one after another, you can master the core Technology. In short, being good at grasping the knowledge you can master, and continuously deepening and expanding the field of knowledge, this is the real way of learning, but also the way to achieve the core technology of individuals and teams.
I have met some people who have worked for many years and they are very characteristic. There is a kind that claims to have no interest in technology and prefer to do management, but in fact, there are not so many opportunities for management, or there are real opportunities, and the performance is not ideal; there is a kind of bragging to support the veteran qualification in front of novices , The actual programming is still a mess. I never make false comments on others, but in terms of technical learning, they are all considered homeless.
"Bamboo Path-Explain the Windows Driver Development in a Simple Way" is finally published. As far as I know, Zhang Peiyin wrote this book and worked at home for half a year. He writes with great enthusiasm and conviction, otherwise even the loss of salary is worth regretting. As far as this book is concerned, it is commendable for the author's sincerity and writing spirit without considering the depth of the content in the book and the technicality.
Cattles don’t eat big in one day. The young calves must continue to eat nourishment to become big cows. Niu people must have Niu technology, Niu technology is the core technology. I hope that every reader of this book, whether you are doing application development or kernel programming now or in the future, whether you use C++, Java, or .NET, will have perseverance and excellence in the process of work and study. Spirit, even the most novice novice, can gradually form its own core technology after years of accumulation and precipitation. Only by mastering one's own core technology can one enter the free world of programmers.
This article is for the preface to the readers of "Bamboo Path-Explaining Windows Driver Development in a Simple Way".
Tan Wen
December 10, 2010
Book Catalog
Say to the kernel world: hello, here I am. If you are a beginner and are full of curiosity about the world, please start from this chapter and let us say hello together~
Chapter 1 Hello World Driver 1
1.1 From Hello World start 2
1.1.1 HelloDRIVER 4
1.1.2 Code explanation 8
1.1.3 Driver compilation and installation 11
< p>1.1.4 View our drivers 141.2 Virtual environment 15
1.2.1 Use virtual environment for driver development 15
1.2.2 Use VMware Virtual machine 15
1.2.3 Target machine settings 16
1.2.4 Virtual PC virtual machine 18
1.3 Summary 19
How to In a regulated business environment, develop successful and effective driver software? The leader of the drive website, Yong Ma (ZnSoft), will talk to you. You will learn these things: establishing a simple and effective development and debugging environment; kernel programming skills in a 64-bit environment; how to release your driver software.
Chapter 2 Commercial Driven Development Technology 20
2.1 Establishing a development and debugging environment 21
2.1.1 SVN environment 21
2.1. 2 Create a project and import SVN 23
2.1.3 Establish a symbol server 25
2.1.4 Debug with symbols 27
2.2 64-bit driver development technology 34< /p>
2.2.1 64-bit driver writing technology 35
2.2.2 32-bit application and 64-bit driver mixed mode 36
2.3 driver release and testing 42
2.3.1 Driver signature 42
2.3.2 Driver test 46
2.3.3 WHQL 49
2.4 Summary 50
WDF is currently the latest driver programming framework. When many kernel programmers still cling to the huge buddha feet of WDM, we must remember that WDF is the general trend. This chapter introduces the most important concepts of WDF, and conducts a certain degree of in-depth exploration. This chapter focuses on the three core models of the WDF framework: object model, event model, and PNP/Power model.
Chapter 3 Overview of WDF 51
3.1 Main features 52
3.2 Frame view 53
3.3 Compatibility 55
3.4 Object model 56
3.4.1 Object and handle 59
3.4.2 Reference count 60
3.4.3 Context space 61
3.4.4 PME interface 67
3.4.5 DDI interface 69
3.4.6 Parent-child relationship 76
3.4.7 Object synchronization 77< /p>
3.5 Drive Object and Device Object 78
3.5.1 Drive Object 78
3.5.2 Drive Entry DriverEntry 81
3.5.3 Device object 84
3.5.4 Create device object 85
3.5.5 Device stack 86
3.6 IO model 88
3.6. 1 IO target object 88
3.6.2 Details of IO target object 90
3.6.3 Safe buffer 93
3.6.4 Memory object (1 ) 96
3.6.5 Memory Objects (2) 98
3.6.6 Framework and IO Request 102
3.6.7 More detailed processing flow 103< /p>
3.6.8 IO request parameters 105
3.6.9 Queue 107
3.6.10 Create IO request 110
3.7 PNP and power Model 112
3.8 Summary 115
Using the WDF framework to develop USB drivers is convenient and simple. This chapter first introduces USB related knowledge points from the two aspects of hardware and software, including the electrical characteristics of the device, bus structure, USB drive type and class drive. In terms of programming, it is explained thoroughly and informatively from the aspects of USB device initialization, data operation and device control.
Chapter 4 WDF USB Device Driver Development 116
4.1 USB Device Hardware Structure 117
4.1.1 Master-Slave Structure 117
4.1.2 Hardware topology 118
4.1.3 USB interrupt 119
4.2 USB software structure 120
4.2.1 Bus driver 120
4.2.2 System driver 121
4.2.3 Function driver 122
4.2.4 Parent driver and hybrid device 122
4.2.5 Filter driver 125
4.2.6 USB driver stack, device stack 125
4.3 Kernel development 127
4.3.1 Device driver 127
4.3. 2 Entry function 128
4.3.3 USB descriptor 129
4.3.4 Descriptor introduction 130
4.3.5 Summary example 133
< p>4.3.6 Read Descriptor 1354.3.7 Initialize 137
4.3.8 Device initialization function 138
4.3.9 Create device object 141
4.3.10 Device naming, symbolic link 143
4.3.11 Start device 147
4.3.12 Create queue 156
4.3 .13 Stop device/deinitialize 158
4.4 Data I/O operation 160
4.4.1 USB control command 160
4.4.2 Construct and send control Command 162
4.4.3 Read USB interrupt port 163
4.4.4 Continuous read operation 165
4.4.5 Data processing function 166
< p>4.4.6 The efficiency of interrupt port 1674.4.7 Read/write bulk port 168
4.5 Device control 171
4.5.1 About I/ O Target object 171
4.5.2 Get USB version 172
4.5.3 Pipe reset 174
4.5.4 Device reset 176
4.5.5 Pipeline termination and termination 177
4.6 User program 179
4.6.1 Kernel read/write 179
4.6.2 Control commands 179
4.7 Summary 180
p>1394 is commonly known as FireWire. The most common place for everyone to contact it is probably during the kernel debugging, with the help of 1394 cards for dual-computer interconnection. This chapter first introduces the knowledge of 1394 from the aspect of hardware. Its bus structure is very special and extremely scalable. It can easily establish data links between various types of 1394 devices. In terms of kernel programming, this chapter focuses on data communication related knowledge, which is divided into asynchronous communication and synchronous communication. It is quite complicated and relatively difficult to master, but the routines are readily available and there are not many changes. Practice makes perfect. At the end of this chapter, the principle of 1394 dual computer interconnection is introduced, and interested readers can refer to it.
Chapter 5 WDF 1394 driver development 181
5.1 1394 talk 182
5.1.1 version status 183
5.1.2 Power characteristics 183
5.1.3 1394 card 183
5.1.4 Bus topology 184
5.2 Send request 186
5.2.1 Synchronous mode 187
5.2.2 Asynchronous mode 189
5.2.3 Memories of WDM 191
5.3 Bus reset and counting 193
< p>5.3.1 Bus reset 1935.3.2 Set reset callback 193
5.3.3 Count update 194
5.4 PNP operation 195
p>5.5 Asynchronous communication 196
5.5.1 Address range 197
5.5.2 Asynchronous read 200
5.5.3 Asynchronous write 201
p>5.5.4 Asynchronous lock request 202
5.5.5 Data stream 203
5.6 Isochronous communication 204
5.6.1 Request bandwidth 205
5.6.2 Release bandwidth 206
5.6.3 Isochronous channel 206
5.6.4 Resource handle 207
5.6.5 Buffer mount 210
5.6.6 Buffer unmount 211
5.6.7 Start transmission 211
5.6.8 Stop transmission 212
5.6.9 Other isochronous operations 213
5.7 Other operations 213
5.7.1 Device configuration 213
5.7.2 Obtaining controller information 214
5.7.3 Speed information 215
5.7.4 Manufacturer custom commands 216
5.8 Installation and testing 216
5.8.1 1394 Virtual Device 216
5.8.2 Create Virtual Device 218
5.8.3 Sample Code 219
5.8.4 Installation and Test 221
< p>5.9 Summary 222The kernel is naturally suitable for C language programming, but there are more and more kernel projects with a scale of tens of thousands. In this case, people can't help but turn their attention to the elegant C++ language. Generally speaking, C and C++ are close relatives and friends. There shouldn't be any major problems with using C++ in the kernel, but there are a few hidden reefs that have been lurking for a long time. If you are not careful, you should never get on the reef.
Chapter 6 Kernel Driver C++ Programming 223
6.1 Class 224 in the driver
6.1.1 A simple example 224
6.1.2 new/delete 225
6.1.3 extern "C" 227
6.1.4 global/static variables 228
6.1.5 worries about the stack 230
6.2-type packaged driver 233
6.2.1 Find a suitable storage place 233
6.2.2 Class methods and event functions 235
6.2.3 KMDF driver implementation 236
6.2.4 WDM driver implementation 237
6.3 Polymorphic 238
6.3.1 Base class, subclass Class 238
6.3.2 Implementation of polymorphism 239
6.3.3 Test 241
6.4 Summary 241
Written using the WDF framework Drivers have special tools for testing and debugging. This chapter introduces the three currently known, they are: Windbg extended debugging command, WDFTester test tool, WDFVerifier test tool. This chapter will introduce the use of these tools with examples.
Chapter 7 WDF driver test 242
7.1 WDF error 243
7.1.1 Example analysis 245
7.1.2 USB error 246
7.2 WDF extended debugging commands 247
7.3 WDFTester 254
7.3.1 WDFFiTester 254
7.3.2 Use 256
p>7.3.3 WDFCallTracer 260
7.4 WDFVerifier 263
7.4.1 Identify KMDF driver 263
7.4.2 Use and introduction 265
p>7.5 Summary 266
After SoftIce drifted away, Windbg became the number one weapon for kernel debugging. The biggest difficulty in using Windbg is that there are many commands and complex parameters. This chapter introduces several major types of debugging commands that the author often uses in his work in the form of summary and induction, and introduces them one by one in the form of examples. The author's classification based on personal experience is not complete, but it can be guaranteed that all examples are informative and reliable, and can be used as credible references.
Chapter 8 Detailed Explanation of Debugging Commands 267
8.1 Overview 268
8.1.1 Seek help 269
8.1.2 DML language 270
8.1.3 Basic information 271
8.1.4 Basic settings 272
8.1.5 Format display 273
8.1.6 Start debugging 273
8.2 Symbols and source code 276
8.2.1 Module list 277
8.2.2 Module information 279
8.2. 3 Symbol path 280
8.2.4 Symbol loading 283
8.2.5 Symbol search 285
8.2.6 Source command 287
8.3 Process and thread 289
8.3.1 Process command 289
8.3.2 Thread command 292
8.3.3 Exceptions and events 296
< p>8.3.4 Local variable 3008.3.5 Display type 301
8.4 Breakpoint 301
8.4.1 Software breakpoint 301
8.4.2 Hardware breakpoint 303
8.4.3 Other operations 303
8.5 Memory command 304
8.5.1 View memory 304
8.5.2 Memory information 307
8.5.3 Other commands 311
8.6 Summary 312
I believe most people are learning kernel development when , Have asked such a question: how does the kernel driver send messages to the user program, or how to call Win32 functions. The synchronization of user program and kernel is a basic and important knowledge. This chapter introduces three main ways of implementation. As for whether the kernel can call Win32 functions, read the beginning of this chapter and you will have the answer.
Chapter 9 Kernel Synchronization 313
9.1 About Kernel Synchronization 314
9.2 Kernel Event Synchronization 316
9.2.1 Principle 316< /p>
9.2.2 User program 318
9.2.3 Kernel implementation 319
9.3 IRP synchronization 320
9.3.1 User program 321< /p>
9.3.2 Kernel implementation 323
9.4 WMI synchronization 325
9.5 Data buffer synchronization 326
9.6 Reverse call 328
p>9.7 Summary 330
Microsoft’s latest audio and video programming framework is the AVStream framework. No matter what, audio and video programming is a very small field. The AVStream framework is extremely complex, and my personal opinion is that it is more difficult to master than WDF. This chapter introduces various basic knowledge points of the AVStream framework, and uses examples to explain how a kernel audio filter works in the system.
Chapter 10 Audio Driver Development 331
10.1 Introduction 332
10.1.1 Audio Module Architecture 332
10.1.2 In the system Audio device 334
10.2 AVStream object 338
10.2.1 Device object 339
10.2.2 Filter factory and Filter object 340
10.2.3 Pin Factory and Pin Object 342
10.2.4 Node Object and Connection Structure 343
10.3 AVStream Descriptor 346
10.3.1 Description Introduction 346
10.3.2 Descriptor example 347
10.3.3 Distribution function table 349
10.3.4 Self-control table 349
10.3.5 Self-control table example 351
10.4 Code explanation 355
10.4.1 Entry function 355
10.4.2 Device distribution function 357
10.4.3 Filter and Pin distribution functions 358
10.4.4 Create and delete 359
10.4.5 Data processing 360
10.4.6 Data Format 362
10.5 Self-control table function 364
10.5.1 Event function 364
10.5.2 Property function 366
10.5.3 Method function 367
10.5.4 User interface 367
10.6 Hardware operation 370
10.6.1 Data DMA 370
10.6.2 Implementation of DMA in AVStream 371
10.6.3 Talk about ISR 374
10.7 Installation and testing 376
10.7.1 Installation 376
10.7.2 Test tool 376
10.8 Summary 379
ASIO audio driver has two very bright advantages: low latency and multi-channel. The low latency can reach a few milliseconds, making it difficult for even the most sensitive ears to detect; multi-channel allows the usual two-channel, 6.1-channel, etc. to rest together, and it can easily make up to a dozen or dozens of sounds. All channels work at the same time, which is very important when doing advanced audio editing.
Chapter 11 ASIO Virtual Sound Card 380
11.1 Introduction 381
11.2 About ASIO 383
11.3 ASIO User Driver 384
11.3.1 COM interface 384
11.3.2 Installation and uninstallation 386
11.3.3 IASIO interface 387
11.3.4 Technology core 390
11.3.5 Calculation delay 392
11.4 Kernel driver implementation 393
11.4.1 Synchronization 393
11.4.2 Principle 393< /p>
11.4.3 Realization 396
11.5 ASIO Audio Software 396
11.6 Summary 397
From the beginning of this chapter, the three chapters will talk about It's all about the topic of "drive installation". In this chapter, various system modules related to driver installation in the system are introduced. After reading this chapter, readers can at least master these two basic knowledge: how the system recognizes an old device and loads a suitable driver file for it; how the system finds a new device and completes the driver installation.
Chapter 12 Getting Started with Device Driver Installation 399
12.1 Introduction to Basic Knowledge 400
12.1.1 Device Type 400
12.1. 2 Device instance ID 401
12.1.3 Driver loading and installation 403
12.2 Installing module 404
12.2.1 Kernel PNP manager 405
12.2.2 User PNP manager 406
12.2.3 Installation interface function (Setup API) 408
12.2.4 Configuration manager interface (CfgMgr API) 410
p>12.2.5 Class Installers 410
12.2.6 Class Co-Installers 410
12.2.7 Equipment Co-Installers (Device Co-Installers) 411
12.2.8 Driver Package (Driver Package) 412
12.2.9 Driver Store (Driver Store) 413
12.2 .10 Device Manager 414
12.2.11 Setup 415
12.2.12 New Device Wizard 416
12.2.13 Add Hardware Wizard 416
12.2.14 Driver Installer 416
12.3 Important issues 417
12.3.1 Finding and selecting 417
12.3.2 32-bit and 64-bit systems are compatible with 418
12.3.3 System restart 419
12.4 Installation mode 420
12.4.1 Example 1: Client End mode 421
12.4.2 Example 2: Server mode 423
12.5 Installer programming 424
12.5.1 DIF code 424
12.5.2 Processing flow 427
12.5.3 Project example 429
12.5.4 Registration 430
12.6 Summary 431
INF The file is the "installation file" of the driver, which contains various instruction information related to the driver installation. Through the INF file, the system knows how to deal with each file in the driver package and makes an accurate record in the system registry. This chapter mainly explains from the two aspects of instruction and domain.
Chapter 13 In-depth analysis of INF file 432
13.1 Overview 433
13.1.1 Domain 433
13.1.2 Command 434< /p>
13.1.3 Multi-system 435
13.2 Registry command 436
13.2.1 Abbreviation root key 436
13.2.2 Software key 437
13.2.3 Hardware key 437
13.2.4 AddReg 438
13.2.5 DelReg 440
13.2.6 BitReg 441
13.3 File operation instruction 441
13.3.1 CopyFiles 441
13.3.2 DelFiles 443
13.3.3 RenFiles 443
p>13.4 Service instruction 444
13.4.1 AddService 444
13.4.2 DelService 445
13.5 Basic domain 446
13.5.1 version domain 446
13.5.2 file domain 447
13.5.3 default installation domain 451
13.5.4 control domain 454
13.5.5 String domain 457
13.6 Device class installation domain 458
13.6.1 Main domain 459
13.6.2 Service subdomain 461
13.7 接口类安装域461
13.8 厂商/产品域462
13.8.1 厂商域463
13.8.2产品域464
13.9 设备安装域464
13.9.1 硬件子域466
13.9.2 协安装器子域467
< p>13.9.3 接口子域46813.9.4 厂商默认配置子域469
13.9.5 逻辑优先配置子域470
13.10 ChkInf介绍471
13.11 小结472
驱动安装程序让你的驱动软件显得更加专业，所以，放弃手动安装驱动的做法吧，你的驱动将显得更靓。本章的示例软件MyDrvInst，可以作为读者设计更漂亮的安装软件的开始。
第14章 设计驱动安装程序 473
14.1 驱动包 474
14.1.1 安装方式 474
14.1.2 安装驱动包 475
14.1.3 卸载驱动包 476
14.2 驱动更新 477
14.2.1 设备已连接 477
14.2.2 设备未连接 478
14.2.3 枚举系统设备 481
14.3 分析INF文件 484
14.3.1 函数介绍 484
14.3.2 打印设备ID 486
14.4 MyDrvInst介绍 487
14.5 制作软件安装包 490
14.5.1 视图介绍 490
14.5.2 我们的工程 492
14.5.3 编译执行 493
14.6 小结 494
附录A CY001 USB开发板 495
附录B VisualKD + VMWare实现单机内核调试 501