{"id":497,"date":"2010-08-27T16:45:04","date_gmt":"2010-08-27T16:45:04","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2010\/08\/27\/what-to-read-to-write-windows-drivers\/"},"modified":"2026-07-31T19:28:00","modified_gmt":"2026-07-31T19:28:00","slug":"what-to-read-to-write-windows-drivers","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2010\/08\/27\/what-to-read-to-write-windows-drivers\/","title":{"rendered":"What to Read to Write Windows Drivers"},"content":{"rendered":"
\"\"<\/a><\/div>\n

A question I am always asked is about which books one needs to read in order to be able to develop drivers for Windows. This is a subject I considered too obvious to have a post about, but over time I came to realize that this subject is not so obvious for those who are starting from scratch. For some, writing drivers is something unattainable — no matter how much they read or try to learn, it will never be enough information to start getting their hands dirty. For others, writing drivers is not so complicated — that, just as they learned to write applications with Visual Basic, a few clicks would be more than enough to generate the driver they need. In an attempt to give an idea of the path and the difficulties to be faced in this new undertaking, I am going to list some books that I consider to be a good path to follow for writing drivers.<\/p>\n

They don’t teach this at college<\/h3>\n

Among the many times this question was asked of me, once I was asked whether this is taught in the Computer Engineering course, which was the course I was taking at the time. I don’t know if everyone here knows, but Computer Engineering is a course that sits between Computer Science and Electronic Engineering. Trying to bring together the main subjects of both degrees, the course does not give as much emphasis to software or to electronics. Despite studying hardware, microprocessors, C language and operating systems, we don’t come anywhere near the subject of drivers. We know they exist and what their function is, but nothing that comes anywhere near the simplest example on this blog<\/a>.<\/p>\n

\n

Come on Fernando, since a driver is software, then the Computer Science course must teach drivers.<\/p>\n<\/blockquote>\n

Actually, the subjects seen in Computer Science deal with higher-level solutions, with more detail on specific algorithms for complex problems. The fact is that this course is more distant from basic software development. In a master’s degree this becomes even rarer in the software area.<\/p>\n

A driver is low-level software, but don’t overdo it<\/h3>\n

I have a friend who always liked to study everything down to the smallest details. It’s fine if a person is passionate about a certain subject and wants to understand it completely, but if the goal is to write drivers, I believe it is better to study only what is necessary for a quick start, and then go deeper into each subject as needed. I have already seen some people say that before studying the C language, they would like to completely study the assembly language, or even start studying the Intel processor datasheet to have complete mastery of the subject. Hold on there, folks!<\/p>\n

\"\"I learned to program in the C language during my technical high school; I don’t know the main references on the subject, but the book I read is simple and, regarding the C language, comprehensive enough to program. That is why I recommend the book Treinamento em Linguagem C<\/a>. You won’t need to buy real bibles on the subject that discuss the best way to compile a certain algorithm.<\/p>\n

The vast majority of the drivers I have seen in these nearly 10 years of Kernel experience are written in C, not in C++. The C language is transparent and reliable. I am not saying that you shouldn’t trust C++, but that over time you look at code in C language and manage to imagine what the assembly generated by it would be like. This helps a lot when you need to debug systems where the sources don’t match perfectly with the version you have, or even in trying to understand situations where you don’t have the source. C++ has its traps with operator overloading, templates and classes. Looking at the source it becomes hard to imagine what will really happen when that line is executed. I myself have already developed drivers in C++ and have given a course at a company where Walter Oney left his sources of a driver all in C++. I think it’s a personal choice, but the fact is that you don’t need to study C++ to write drivers.<\/p>\n

I have also heard people say “First I’m going to learn C++ completely and then start studying the Kernel”<\/em>. I think I don’t need to say that this is completely unnecessary. Not to mention that I still don’t know whether it is humanly possible to learn C++ completely.<\/p>\n

Do I need to read Charles Petzold?<\/h3>\n

\"\"In the course I offer on driver development, one of the prerequisites is basic Windows API. When I say basic, I am referring to the manipulation of system objects, such as files, events, threads, processes, virtual memory and the like. I did not want to enter the universe of message loops, MFC<\/a>, WTL<\/a> and countless User-Mode concepts that will not be used in Kernel.<\/p>\n

An excellent book about the system’s internal architecture is described in great detail in the book Windows Internals 5th Edition<\/a>. The only problem is that the book has more than a thousand pages and that is a real brake pedal for someone who is all excited to go off writing drivers. A viable alternative is the temporary replacement of this book by Inside Windows NT 2nd Edition<\/a>. A book that is half the size of Windows Internals and that brings the most important concepts about the system that are still used in Windows 7. When you are more comfortable, then you can read Windows Internals, and who knows, even take a certification<\/a> on the subject.<\/p>\n

Legacy Model<\/h3>\n

\"\"After understanding a little about the Windows architecture, you will already be able to start studying the key subject. But for that, you must choose what type of driver you intend to develop. The oldest model is Legacy, which despite having started in Windows NT 3.51, still runs on Windows 7. This model does not interact with the Plug-And-Play Manager, but it is still the model used in the development of File Systems<\/em> to this day. All the rules used in the Legacy model are also used in the WDM model. This way, studying the Legacy model is a great introduction to studying WDM or File System drivers. The book I recommend for Legacy development is Windows NT Device Driver Development<\/a>. Studying the Legacy model gives the reader the opportunity to go deeper into basic and essential concepts in Kernel Mode development. Because it is a simpler model, the reader’s brain manages to absorb with better quality questions such as: IRP handling, virtual memory, thread execution levels, synchronization mechanics, system objects and so on.<\/p>\n

The reader who studies the Legacy model will be much better prepared to deal with the WDM model, which has its own rules that will be applied using the concepts already acquired in the Legacy model. The same can be said regarding the development of File System drivers. Although File System drivers are developed in Legacy, it does not mean that by learning the Legacy model, one learns File Systems automagically. This is also a subject that requires dedicated study.<\/p>\n

Windows Driver Model (WDM)<\/h3>\n

\"\"If your target model is WDM, then a good book to start with is the Windows 2000 Device Driver Book<\/a>. That’s because the big problem with driver-development books is that a lot of theory is necessary to make a driver. In the WDM model things get even more loaded. This is not the best WDM book I know, and I have already seen comments on discussion lists saying that this book is known for its errors. The fact is that it gives a simplified presentation, and the best of all is that the author creates a basic driver at the beginning of the book and then goes putting more concepts into practice. With this the reader will write an example driver before dying mad with so much theory.<\/p>\n

After having a base in WDM, then you will already be ready to read a grown-up’s book, and I am not referring to nudity magazines. The book Programming the Windows Driver Model 2nd Edition<\/a> is really very good. I myself have already read it some three times, but as I mentioned before, many pages are necessary for the reader to be able to start seeing things as a whole. All this theory tires and confuses a reader who is starting out on the subject.<\/p>\n

File System Drivers<\/h3>\n

\"\"If you are one of the few living beings on this planet who need to develop or support File System drivers, then studying the Legacy model was a breeze. Some ask me: “What is so complicated about writing File System drivers?”<\/em> The problem is that besides the concepts of the Legacy model, you need to deal with the very concepts used in integrating File System drivers with other system components. I am talking about their inseparable friends Memory Manager<\/em> and Cache Manager<\/em>. Several structures and rules are imposed by the system so that this component can fulfill its role in a stable and efficient way. The lack of books on the subject adds some adrenaline to the learning process. The book Windows NT File Systems Internals<\/a> is the only book that deals with the subject for Windows. It is hoped that OSR<\/a>, the company that currently holds the rights to this book, can release an updated version of it, but since the target audience is restricted, perhaps there is not enough incentive to make this happen.<\/p>\n

Writing File System drivers is complicated and one might even imagine that this is the most complicated type of driver there is to write, but according to OSR and other authorities on the subject, that position of most complex driver is occupied by File System filters. That is because besides having to know the rules that File System drivers need to follow, the filters still do not<\/strong> receive all the notifications that the driver itself receives. Writing this type of filter is being between two black boxes that talk with high intensity and intimacy, and still add value to this service. When I did my File System Drivers course at OSR<\/a>, Tony Mason<\/a> said that things get really interesting with the arrival of transactional NTFS.<\/p>\n

Faced with so much difficulty, Microsoft created the class of drivers called MiniFilters, which is a kind of Miniport driver for File System filters. Unfortunately there are still no books that deal with this subject. You will have to face this topic on the MSDN site<\/a>. The detail here is that minifilter drivers are modules loaded by the Filter Manager<\/a>, which from the system’s point of view is just another Legacy File System filter. This way, knowing the Legacy model is a great help when it comes to debugging all this.<\/p>\n

Windows Driver Foundation (WDF)<\/h3>\n

\"\"That the WDM model is complex and laborious, I think we all agree. In order to avoid so much complexity when writing drivers, Microsoft created a new model that leans on WDM to implement all the standard behaviors of a driver by default. This means that you can write a device driver and let the framework do most of the work regarding plug-and-play, power management and countless concepts that are the same for the vast majority of drivers. If you want a special behavior in a certain situation, just register the callback routine and be happy (or not). WDF brings two frameworks, the Kernel-Mode Driver Framework<\/strong> (KMDF) and the User-Mode Driver Framework<\/strong> (UMDF). Developing drivers in KMDF brings a few restrictions compared to WDM, but it is worth writing a new driver in WDF. User-Mode drivers bring greater restrictions, mainly regarding the bus your device is on and how fast the driver needs to be. The book Developing Drivers with the Windows Driver Foundation<\/a> is still the only one that deals with this subject. Once again, a lot of theory is presented until a practical example appears. Another interesting characteristic about this book is that both frameworks are presented simultaneously. Thus, you learn to develop drivers in KMDF and UMDF at the same time. Depending on the reader, this might even give a buzz.<\/p>\n

If what you really want is to develop a driver in User-Mode, then let’s rethink the C++ question. Since a UMDF driver must be implemented in COM<\/a>, some C++ features are now basic requirements for comfortable development. Once again I am going to recommend a book by Viviane, Treinamento em Linguagem C++<\/a>, which from my point of view is sufficient for writing drivers as far as the language is concerned. Later you can become a ninja master with Boost<\/a>, STL<\/a> and other things I can’t even imagine.<\/p>\n

After C++, a good dose of COM<\/strong> goes well. The book that my friend Strauss<\/a> lent me, which went straight to the point in a clear and simple way, is Essential COM<\/a> by Don Box.<\/p>\n

All this theoretical base will give you the background to be able to choose a type of driver and go deeper into it. Even within the Kernel subject, there are still countless driver specialties. Don’t think that you will be able to learn this subject completely before going off developing, so choose your book already and get your hands dirty.<\/p>\n

See you! \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"

A question I am always asked is about which books one needs to read in order to be able to develop drivers for Windows. This is a subject I considered too obvious to have a post about, but over time I came to realize that this subject is not so obvious for those who are […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-497","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/497","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=497"}],"version-history":[{"count":1,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/497\/revisions"}],"predecessor-version":[{"id":498,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/497\/revisions\/498"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=497"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=497"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=497"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}