IntroductionDriver is a very important piece of software that provides a way for a particular hardware to interact with a particular Operating System. Development of device drivers is quite a daunting task. It is a complicated and fastidious activity that demands immense expertise and patience. Microsoft knew that drivers had to be writable in a higher-level language like C, in order to be code-compatible for different hardware systems. To meet these needs, Microsoft created the Windows Driver Model (WDM).WDM drivers are compiled using the DDK, they are written in C, and they follow exacting specifications that ensure they can be executed on any windows system. The Windows platform DDK comes with header files, library files, and a command-line compiler that can be used to write device drivers in C or C++. There is no graphical interface to the DDK compiler.
Windows Driver ArchitectureThe Windows driver architecture provides an extensible interface between the user and kernel layers called the Windows I/O manager. The I/O Manager API includes functions for communicating with device drivers using data structures called I/O Request Packets (IRPs).To improve portability, some implementations isolate the I/O Manager calls in a separate layer as illustrated below, while other implementations make I/O manager calls throughout the driver code.
The communication process between the user driver and the device driver includes the following steps:Step1- The user driver opens a reference to the device by using the Windows API function CreateFile.Step2- The user driver sends a control code (command) to the device driver through the Windows API function DeviceIOControl.Step3- The Windows I/O manager receives the control code, creates an IRP, and routes the IRP to the device driver.Step4- The device driver receives the IRP. Based on the control code, it performs the operation requested by the user-level driver. The device driver accesses the hardware to complete the requested operation. Any data returned by the device is inserted in the IRP and sent back to the user driver via the I/O manager.Step5- When the application is finished, it requests the user driver to close the device. The user driver closes the device reference by calling the Windows API function CloseHandle.In the Windows driver architecture, devices are treated as file resources, providing a common abstraction model for the user driver. Simple direct access to the device driver can be achieved by calling the Windows API functions ReadFile and WriteFile (instead of DeviceIOControl). There are many additional Windows API functions that can be used to communicate with device drivers.
Device Driver APIsWindows driver APIs are event-driven: the driver code executes only when some event happens: either when user applications want something from the device, or when the device has something to tell to the OS.a. InitializationOn Windows, drivers are represented by a DriverObject structure which is initialized during the execution of the DriverEntry function. This entry point also registers a number of callbacks to react to device addition and removal, driver unloading, and handling the incoming IRPs. Windows creates a device object when a device is connected, and this device object handles all application requests on behalf of the device driver.b. Naming and claiming devicesWindows device driver is notified about newly connected devices in its AddDevice callback. It then proceeds to create a device object used to identify this particular driver instance for the device. Depending on the driver kind, device object can be a Physical Device Object (PDO), Function Device Object (FDO), or a Filter Device Object (FIDO). Device objects can be stacked, with a PDO in the bottom. Device objects exist for the whole time the device is connected to the computer. DeviceExtension structure can be used to associate global data with a device object. Device objects can have names of the form \Device\DeviceName, which are used by the system to identify and locate them. An application opens a file with such name using CreateFile API function, obtaining a handle, which then can be used to interact with the device. However, usually only PDOs have distinct names. Unnamed devices can be accessed via device class interfaces. The device driver registers one or more interfaces identified by 128-bit globally unique identifiers (GUIDs). User applications can then obtain a handle to such device using known GUIDs.c. Exchanging dataWindows support three ways of transferring data between user-level applications and kernel-level drivers:
- Buffered Input-Output which uses buffers managed by the kernel. For write operations the kernel copies data from a user-space buffer into a kernel-allocated buffer, and passes it to the device driver. Reads are the same, with kernel copying data from a kernel buffer into the buffer provided by the application.
- Direct Input-Output which does not involve copying. Instead, the kernel pins a user-allocated buffer in physical memory so that it remains there without being swapped out while data transfer is in progress.
- Memory mapping can also be arranged by the kernel so that the kernel and user space applications can access the same pages of memory using distinct addresses.
Driver IO modes on WindowsSupport for Buffered IO is a built-in feature of WDM. The buffer is accessible to the device driver via the AssociatedIrp.SystemBuffer field of the IRP structure. The driver simply reads from or writes to this buffer when it needs to communicate with the userspace.Direct IO on Windows is mediated by memory descriptor lists (MDLs). These are semi-opaque structures accessible via MdlAddress field of the IRP. They are used to locate the physical address of the buffer allocated by the user application and pinned for the duration of the IO request.The third option for data transfer on Windows is called METHOD_NEITHER. In this case the kernel simply passes the virtual addresses of user-space input and output buffers to the driver, without validating them or ensuring that they are mapped into physical memory accessible by the device driver. The device driver is responsible for handling the details of the data transfer.
Windows Driver Development EnvironmentA. Windows Driver KitWindows is a closed-source operating system. Microsoft provides a Windows Driver Kit to facilitate Windows device driver development by non-Microsoft vendors. The kit contains all that is necessary to build, debug, verify, and package device drivers for Windows.Windows Driver Model defines a clean interface framework for device drivers. Windows maintains source and binary compatibility of these interfaces. Compiled WDM drivers are generally forward-compatible: that is, an older driver can run on a newer system as is, without being recompiled, but of course it will not have access to the new features provided by the OS. However, drivers are not guaranteed to be backward-compatible.B. Build system for device driversWindows Driver Kit adds driver development support for Microsoft Visual Studio, and includes a compiler used to build the driver code. Developing Windows device drivers is not much different from developing a user-space application in an IDE. Microsoft also provides an Enterprise Windows Driver Kit, which enables command-line build environment similar to the one of Linux.C. Documentation supportWindows has excellent documentation support for driver development. Windows Driver Kit includes documentation and sample driver code, abundant information about kernel interfaces is available via MSDN, and there exist numerous reference and guide books on driver development and Windows internals.D. Debugging supportWindows has logging facilities that can be used to trace-debug driver code. On Windows one would use DbgPrint function for this Windows supports interactive debugging via its kernel-level debugger WinDbg. This requires two machines connected via a serial port: a computer to run the debugged kernel, and another one to run the debugger and control the operating system being debugged. Windows Driver Kit includes debugging symbols for Windows kernel so Windows data structures will be partially visible in the debugger.
OdiTek’s Expertise on Device Driver DevelopmentOur expertise on developing and customizing Windows device drivers like Camera device drivers etc. has helped customers release custom solutions. Like Linux Device driver development, we have the core expertise to produce development solutions for Windows device drivers as well.We have an ideal mix of young talent complemented by a mature research group that undertakes the activity of developing device drivers. Based on precise understanding of how drivers interact with the operating system or kernel, our team develops drivers for Microsoft Windows and Linux.OdiTek also holds the ace when it comes to customizing the device drivers. We offer modifications and porting services for existing device drivers to be compatible with new operating or hardware platforms. We foster a dynamic development environment that follows stringent quality checks and source code integrity guidelines.We can also develop with speed the drivers that can be suitable for cameras, audio devices, printers, scanners, monitors, storage devices, keyboards, mouse, modems and network cards. Whether it is kernel level programming for embedded solutions or interfacing peripherals, OdiTek offers dedicated efforts that guarantee quality output. For more information on Windows device driver development & Customization, Please drop an email to- firstname.lastname@example.org
What Oditek offers
Refer our Skills page:
We had a tough deadline to launch our .Net based application that processes a lot of data, and got very frustrated with our development agency we hired. Fortunately we got Oditek, and they took over seamlessly the product development, launched the app & continued feature development. Just awesome!
They were very attentive to our needs as clients and went out of the way to make sure our projects were taken care of. They were always able to get projects done in the specifications we requested. They are passionate about getting things done; I would definitely recommend them to lead any IT projects.
OdiTek has been very impressive in delivering a C++ based network security product migration from Linux to Windows. Honestly, we didn’t expect the speed and competencies to get the migration project delivered absolutely on time as the existing product was complex. Technically team is very experienced.
I worked with OdiTek on few high profile banking application projects. They did a fantastic job with web applications & manual testing on the VAS apps for two leading banks of UK that included rigorous UAT phases. I recommend them for any application development where security matters.
OdiTek is our extended team who works on our key software projects. They are dependable, good in collaboration and technically very much to the level what we expect a global team should be. They had transformed our web applications, CRM and added mobility to existing business platforms here.
It's been more than 4 years now that we are working with OdiTek on our cloud based web product development. It's been amazing working together, they are very competent on designing scalable, high performance apps. Their technical support is outstanding to say the least, even at odd hours.
I am a fan of Team OdiTek since 2014 and have worked on many product development projects together. Specially worth mentioning their deliveries on VAS Banking web application development & manual testing services for Smarta, UK. They are highly skilled & a professional team to work with.
OdiTek has been working on our Integrated Web-scale Mobile Platform i.e. Optimal Health since 2014. They are very professional and takes care of the requirements meticulously. They are technically very sound and sincere in ensuring quality & performance. Wonderful working with them!
You can trust the team, with minimum supervision you get the work done. They are honest, professional & committed to schedule & quality. I had been successfully running 3 business applications designed, developed and maintained by Oditek developers. It’s been a pleasure working with them.
OdiTek has been working in custom software development, including services for test automation. Many of them have worked with me in 2009-10 when I was R&D Manager in NetHawk India. They have great enthusiasm & a passion to excel in bringing customer success. Their work has been very impressive.
It's amazing to see these guys are turning their experience into a global delivery excellence at OdiTek. I am sure their past large scale product development experience will be handy to product companies. I would always recommend Oditek for software development, especially performance-driven solutions.