From: faqserv,faqserv@bloom-picayune.MIT.EDU Newsgroup: comp.answers,news.answers,comp.os.ms-windows.programmer.drivers Receive-Date: Mittwoch, 15-Mär-95 13:59:54 Creation-Date: Sonntag, 12-Mär-95 16:57:21 Message-ID: windows/programming/device-drivers_795027290@rtfm.mit.edu Date: 12 Mar 1995 16:57:21 GMT Subject: comp.os.ms-windows.programmer.drivers Frequently Asked Questions (FAQ) Organization: Vireo Software, Inc. Followup-To: comp.os.ms-windows.programmer.drivers UserFlags: Old ReadAccess GlobalFlags: Exported Link HardLink Archive-name: windows/programming/device-drivers Posting-Frequency: bimonthly Last-modified: February 9, 1995 Frequently Asked Questions (FAQ) for comp.os.ms-windows.programmer.drivers Summary: This is a working document. Suggestions, questions, answers, are welcome. I will post this document near the beginning of each month. This FAQ is particularly thin on Windows NT driver information (that's a hint for you NT driver wizards out there to send in some info...). Thanks for help, comments, and answers from Lee Fisher, Michael Geary, Chris Marriott, Dan Norton, and especially Don Matthews. Edited by Steve Lewin-Berlin (Berlin@vireo.com) Questions: 1. Help, I need a driver for... 2. How do I access physical memory at from a Windows 3.1 application? 3. What are the differences between embedded, installable, and conventional device drivers? 4. I need to write a Windows device driver. Should it be a DLL or a VxD? 5. How do I handle interrupts in my VxD? 6. How do I access physical memory in my VxD? 7. How do I access memory from my application or DLL in my VxD? 8. Can I write device drivers in C/C++, or must I use assembly language? 9. What commercial products are available to help write drivers? 10. What books are available? 11. What on-line resources are available? 12. What other information is available? Answers: 1. Help, I need a driver for ... I'm afraid you've asked on the wrong group. This is a newsgroup for discussions of device driver programming, not for requesting drivers for particular devices. I'm sure you'll get help if you ask on the correct newsgroup, which is "comp.os.ms-windows.setup". 2. How do I access physical memory at from a Windows 3.1 application? This is very easy to do. Here is a sample program that references the VGA display buffer at A000:0000. You can use the same technique, except use _D000h instead of _A000h. KERNEL defines a whole set of these selectors for you covering the A000 through F000 range. #include "nojunk.h" #define STRICT #include typedef WORD SELECTOR; // __A000h is an absolute value; by declaring it as a NEAR variable // in our data segment we can take its "address" and get the // 16-bit absolute value. extern BYTE NEAR CDECL _A000h; SELECTOR selVGA = (SELECTOR)&_A000h; int PASCAL WinMain (HINSTANCE hinst, HINSTANCE hinstPrev, LPSTR lpszCmdLine, int cmdShow ) { WORD FAR * lpVGA = MAKELP( selVGA, 0 ); // Should put garbage pixels on top left of screen lpVGA[0] = 0x1234; lpVGA[1] = 0x5678; return 0; } 3. What are the differences between embedded, installable, and conventional device drivers? All of these terms can be used to describe 16-bit protected-mode DLLs. o An embedded device driver is a DLL that basically acts as an extension of a particular Windows application. It usually contains an interrupt handler, and it exports any set of services the author might choose to implement. o An installable device driver must conform to more rigid guidelines. This type of driver can be opened, closed, enabled, disabled, etc. by other applications or DLLs. It contains a DriverProc, which is like the WindowProc in a Windows application. The DriverProc responds to a standard set of messages sent by Windows and to custom messages sent by applications. This is the type of driver that can be installed using the Control Panel applet. o A conventional device driver (also sometimes called a "standard" device driver) interacts with a hardware device supported by the Windows API. For example, the display, keyboard, and printer are considered to be "standard" devices. These drivers are sometimes given a file extension of .DRV, and are usually installable drivers. They work with certain pre-defined data structures and provide certain pre-defined services. 4. I need to write a Windows device driver. Should it be a DLL or a VxD? This is the kind of question whose answer really depends on your application and your objectives. In general, a VxD is more difficult to develop, but yields higher performance when processing interrupts and accessing I/O ports. A VxD can also do things that aren't otherwise possible with a DLL. The first step is to determine what it is that your driver must do. If it must support a hardware device, then which of the following system resources are required by your hardware? a.) I/O ports b.) IRQ lines c.) Memory ranges d.) DMA channels If I/O ports are involved, then be aware that there are performance issues related to accessing I/O ports from ring 3, as you would in a DLL, as compared to accessing them from ring 0 in a VxD. There is overhead associated with accessing I/O ports from ring 3, perhaps as much as 100% or more (i.e. ring 3 accesses take twice as much time as ring 0 accesses). If IRQ lines are involved, then be aware that there is significantly more interrupt latency associated with an ISR running in ring 3 than in a DLL. Access to physical memory can be accomplished with DPMI services in a DLL, or VMM services in a VxD. Access to DMA channels should go through VDS (Virtual DMA Services). If you need to make your hardware appear to be shared by Windows applications and DOS applications running in separate DOS boxes, then you need to "virtualize" your hardware with a VxD. You also need to "virtualize" your hardware if you need to mediate access, or resolve contention for your device. 5. How do I handle interrupts in my VxD? You should use the services provided by the Virtual PIC Device (VPICD) to install an ISR for your hardware device. This involves creating a data structure in the locked data segment of your VxD of type VPICD_IRQ_Descriptor. In it, you specify the IRQ number and the address of your ISR, among other things. You then register your ISR by calling VPICD_Virtualize_IRQ. This returns an IRQ Handle, which you should save for future reference. Later, when an interrupt occurs, your ISR will be entered with minimal latency. The ISR should be in a locked code segment. The IRQ Handle that uniquely identifies this interrupt will be in EAX upon entry. You should call VPICD_Phys_EOI at the end of your ISR. Just before returning from your ISR, clear the carry flag if you successfully processed the interrupt. If the IRQ is sharable, you can pass the IRQ on to the next handler in the chain by setting the carry flag. Return from the ISR with a RET instruction, not IRET. Upon entry to the VID_Hw_Int_Proc (your ISR), interrupts are masked at the PIC for that particular interrupt, and an EOI has already been sent to the PIC for that same interrupt. The call to VPICD_Phys_EOI at the end of the ISR doesn't actually send an EOI to the physical PIC, as the name implies, but rather simply unmasks the interrupt at the PIC. The EOI was actually sent to the PIC before entering VID_Hw_Int_Proc. The name of the VPICD_Phys_EOI service is misleading. Check out the useful services provided by VPICD. 6. How do I access physical memory in my VxD? You should first convert the physical address to a linear address with the _MapPhysToLinear service. Then convert the linear address to either a protected-mode address in : form or a V86-mode address in : form with the Map_Lin_To_VM_Addr service. 7. How do I access memory from my application or DLL in my VxD? You should convert the protected-mode address to a linear address with the Map_Flat service. 8. Can I write device drivers in C/C++, or must I use assembly language? VxDs are 32-bit programs. You may use a 32-bit C/C++ compiler, but you must be careful about segmentation, calling conventions, and run time library routines that require initialization. Many of the interfaces provided by the Virtual Machine Manager have register-based calling conventions. Vireo Software sells a toolkit that allows you to use C or C++ to write VxDs. See below. 9. What commercial products are available to help write device drivers? MSDN level 1 (Microsoft) MSDN level 2 (Microsoft) Soft-ICE/W (Nu-Mega Technologies) VtoolsD (Vireo Software) MSDN level 1 Summary: Membership in level 1 of the Microsoft Developer Network gets you a CD 4 times per year. The CD is packed with documentation and on-line books, including articles about VxD development. Price: $195/ year Contact: Microsoft Developer Network mail: PO Box 10296, Des Moines, IA 50336 voice: (800) 759-5474 voice: (206) 936-8661 CIS: go MSDS MSDN level 2 Summary: Membership in level 2 of the Microsoft Developer Network gets you a set of CDs 4 times per year. The CDs include the level-1 CD (see above) plus operating systems, SDKs, and DDKs for a number of MS products. This includes the Windows Device Driver Kit (DDK), which includes utilities required to build device drivers, along with numerous examples. Price: $495/ year Contact: MSDN (see above) VtoolsD for Windows 3.1 Summary: VtoolsD is a toolkit that allows developers to build VxDs in C or C++ using the Microsoft 32-bit C/C++ compiler. VtoolsD includes a visual-programming VxD code generator, ANSI C run-time libraries, VMM/VxD service libraries, and a VxD Class Library. Compatible with Microsoft and Borland C/C++ compilers. Price: $495 Contact: Vireo Software mail: 385 Long Hill Road, Bolton, MA 01740 voice: (508) 779-8352 fax: (508) 779-8351 Email: Vireo@vireo.com VtoolsD for Windows 95 (Pre-release) Summary: The Windows 95 Pre-release allows developers to build VxDs that call new services available in Windows 95. Requires Windows 95 DDK. Price: $495 Contact: Vireo Software (see above) Soft-ICE/W Summary: Soft-ICE/W is a full-screen character-mode debugger that can be used to debug VxDs and applications. Soft-ICE/W can debug VxDs at the instruction level, or display ASM, C, or C++ source code. Price: $386 Contact: Nu-Mega Technologies, Inc. mail: PO Box 7780, Nashua, NH 03060 voice: (603) 889-2386 fax: (603) 889-1135 10. What books are available? Writing Windows Device Drivers (Daniel Norton) Writing Windows Virtual Device Drivers (Thielen and Woodruff) Title: Writing Windows Virtual Device Drivers Author: David Thielen and Bryan Woodruff Publisher: Addison Wesley ISBN: 0-201-62706-X Price: $39.95 Title: Writing Windows Device Drivers Author: Daniel Norton Publisher: Addison Wesley ISBN: 0-201-57795-X Price: $29.95 11. What on-line resources are available? CompuServe Internet Internet news groups comp.os.ms-windows.programmer.drivers Internet FTP site ftp.microsoft.com Developr/drg/developer-info/devinfo.zip This file contains a list of developer resources available from Microsoft; it is not driver specific. Developr/MSDN/ Developr/DRG/MSDN-Info/ These directories contain additional information about Microsoft Developer Network. CompuServe Microsoft operates several forums on CompuServe that may be of interest to device driver developers: Microsoft Developer Knowledge Base Service: MDKB The Microsoft Developer Knowledge Base is a reference tool containing technical information and articles about the Microsoft developer-specific products. This database is compiled and maintained by Microsoft Product Support and is full-text, keyword searchable. You will find Microsoft press releases and technical articles about product bugs, trouble-shooting and updates. Microsoft Developer Network Forum Service: MSDNLIB The Microsoft Developer Network (MSDN) Technical Library Forum offers software developers a quick and efficient way of obtaining technical information. The libraries contain a collection of technical articles in the Windows Help file format and sample code, which are available for downloading. Message sections enable you to discuss any of the files or codes with other users, as well as with Microsoft Representatives. Microsoft Knowledge Base Service: MSKB Microsoft Knowledge Base is a database which provides access to information about Microsoft products previously available only to the Microsoft support engineers. Search the database by product name, version or category. Or for immediate responses to your questions, perform a full-text search of all documents contained within database that contain the subject of your question. Also communicate directly with Microsoft by sending an electronic message to its Help Desk. Microsoft Service Request Service: MSR Microsoft offers the Service Request System as an optional, private (fee-based per incident) technical support service that offers to help solve complex development problems. Other avenues, such as the Microsoft Developer Support Forums and Microsoft Developer Knowlede Base, should be consulted prior to using the Service Request System. Microsoft Software Library Service: MSL The Microsoft Software Library is a collection of uploaded binary files, samples, technical notes and utilities about various Microsoft programs. The entire library is keyword searchable and the files can easily be downloaded to your computer. Microsoft Windows SDK Forum Service: WINSDK Developers using the Windows Software Development Kit [and DDK] will want to take advantage of the community of assistance and support available in the Windows SDK Forum. Help is available for subjects such as tools, accelerators, controls, dialogue boxes, memory management, fonts, palettes and color [and device drivers]. 12. What other information is available? The October 1992 Microsoft Windows NT Device Driver Developer's Conference video/audio tapes are still available. Contact: MobileTape Co. Inc. address: 25061 W. Stanford, Suite 70; Valencia, CA 91355, USA phone (orders): 800.369.5718 phone (info): 805.295.0504 fax: 805.295.8474 ask for the order form for the event: Microsoft Windows NT Device Driver Developer's Conference October 26-28, 1992 Anaheim, CA Solomon Software Technologies 20 Hunters Lante Nashua, NH 03063-2245 USA Phone: 1.800.492.4898 Phone: 1.603.595.9059 FAX: 1.603.595.9005 Email: 71561.3603@CompuServe.COM They offer various technical seminars by folks such as Richard Hale Shaw, Jamie Hanrahan, Jeffrey Richter, and David Solomon. Topics include Visual C++, OLE, MFC, Windows '95 ("Chicago"), Win32 programming, and Windows NT device drivers. One relevant seminar is "Windows NT Kernel-Mode Device Driver Programming". 99. Conflict of interest? The editor works for Vireo Software, Inc. and is one of the authors of the VtoolsD VxD toolkit mentioned in this document. I hope you find the information listed here to be useful. Please send comments, suggestions, questions, etc. -- Steve Lewin-Berlin Vireo Software Berlin@vireo.com