Prev: WDK 7600 missing x64 for XP??
Next: Can WinDbg script extract an EPROCESS address from command output?
From: Maxim S. Shatskih on 22 Sep 2009 14:19 Linux is good, but, for successful Windows driver development, one must know what are IRPs, MDLs and IRQLs. This is a must. Their Linux parallels ("cannot block" for DISPATCH_LEVEL, kiobuf for MDL) are _not_ 100% the same. >Use Firewire for debugging. Also, I would not use a 64 bit operating >system on either machine, specially on your target - and I may be >overconservative, but I would install Windows XP in the target if I >was a beginner. Target _must_ be multi-boot. It must be able to boot many Windows versions, 32 and 64 bit. Don't forget that, for this, you must install Windows versions in their release order - 2000, then XP 32, then 2003/XP 64, then Vista/2008, then Win7/R2. If VMs are targets - then this has its own advantages. The pipe emulation of COM port in Hyper-V is much faster then the real serial and is lesser issue-prone then 1394. >3. Download the latest WDK from Microsoft Depends on whether w2k support is a must. If yes - then 6001.18002 is a must, and not a Win7 WDK. >4. Download the Windows Debugging Tools - which includes the windbg >debugger - and install them in your host computer. Win7 WDK include them I think. >resulting .sys file placed. Learn how to ask for a .pdb file. Always generated by default in the same directory as .sys >and how to tell Windbg where your source code is. No need usually, this is embedded to the .pdb. >you will learn about INF files Starting with MS-provided INF from \windows\inf and customizing to your needs is the simplest. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Dannel on 24 Sep 2009 13:35 Thanks for all of the information everyone. I've actually been sick since the beginning of the week and have been using it as an opportunity to read Walter Oney's book (whenever I feel up to it). Lots of good info. I think I'm going to skip the Linux stuff though, only because I know that if I don't start working straight away on my driver, even if I make mistakes, I'll lose interest, especially after reading tons of information on the subject. I'd rather ride my enthusiasm and stumble along the way than give up halfway through. Oney's book is really great at explaining the driver stack and how things work. From what I can tell, Tim is definitely right about where drivers spend the bulk of their time, responding to events. When I look at it that way, it doesn't seem so bad, that is, until I open up some sample source code lol. Seriously though, it is starting to make sense to me. As far as target machines, my target is Vista 64, because the virtual driver I'm trying to replace (ppjoy) doesn't support it and has abandoned the project. I'm not that concerned about older versions of Windows, since ppjoy has them covered. The one decision I'm still unsure about is whether or not I can create the driver with UMDF. I know it can be done with KMDF, but I'd like to take advantage of UMDF, especially since I won't be talking to real hardware (it's a virtual joystick driver). From what I can tell I may be able to do the virtual joystick driver with UMDF and maybe have a KMDF bus driver to enumerate the virtual joysticks. Dannel "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:ehFBAF7OKHA.4244(a)TK2MSFTNGP06.phx.gbl... Linux is good, but, for successful Windows driver development, one must know what are IRPs, MDLs and IRQLs. This is a must. Their Linux parallels ("cannot block" for DISPATCH_LEVEL, kiobuf for MDL) are _not_ 100% the same. >Use Firewire for debugging. Also, I would not use a 64 bit operating >system on either machine, specially on your target - and I may be >overconservative, but I would install Windows XP in the target if I >was a beginner. Target _must_ be multi-boot. It must be able to boot many Windows versions, 32 and 64 bit. Don't forget that, for this, you must install Windows versions in their release order - 2000, then XP 32, then 2003/XP 64, then Vista/2008, then Win7/R2. If VMs are targets - then this has its own advantages. The pipe emulation of COM port in Hyper-V is much faster then the real serial and is lesser issue-prone then 1394. >3. Download the latest WDK from Microsoft Depends on whether w2k support is a must. If yes - then 6001.18002 is a must, and not a Win7 WDK. >4. Download the Windows Debugging Tools - which includes the windbg >debugger - and install them in your host computer. Win7 WDK include them I think. >resulting .sys file placed. Learn how to ask for a .pdb file. Always generated by default in the same directory as .sys >and how to tell Windbg where your source code is. No need usually, this is embedded to the .pdb. >you will learn about INF files Starting with MS-provided INF from \windows\inf and customizing to your needs is the simplest. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Tuse on 5 Oct 2009 09:11 Hi Dannel! I'm interesting about the program, which you want to write. I would like to use ppjoy or other application on my win 7 64 bit. Can you help me? Exist this applicaton? Thanks, Tuse "Dannel" wrote: > Thanks for all of the information everyone. > > I've actually been sick since the beginning of the week and have been using > it as an opportunity to read Walter Oney's book (whenever I feel up to it). > > Lots of good info. I think I'm going to skip the Linux stuff though, only > because I know that if I don't start working straight away on my driver, > even if I make mistakes, I'll lose interest, especially after reading tons > of information on the subject. I'd rather ride my enthusiasm and stumble > along the way than give up halfway through. > > Oney's book is really great at explaining the driver stack and how things > work. From what I can tell, Tim is definitely right about where drivers > spend the bulk of their time, responding to events. When I look at it that > way, it doesn't seem so bad, that is, until I open up some sample source > code lol. Seriously though, it is starting to make sense to me. > > As far as target machines, my target is Vista 64, because the virtual driver > I'm trying to replace (ppjoy) doesn't support it and has abandoned the > project. I'm not that concerned about older versions of Windows, since ppjoy > has them covered. > > The one decision I'm still unsure about is whether or not I can create the > driver with UMDF. I know it can be done with KMDF, but I'd like to take > advantage of UMDF, especially since I won't be talking to real hardware > (it's a virtual joystick driver). From what I can tell I may be able to do > the virtual joystick driver with UMDF and maybe have a KMDF bus driver to > enumerate the virtual joysticks. > > Dannel > > "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message > news:ehFBAF7OKHA.4244(a)TK2MSFTNGP06.phx.gbl... > Linux is good, but, for successful Windows driver development, one must > know what are IRPs, MDLs and IRQLs. This is a must. > > Their Linux parallels ("cannot block" for DISPATCH_LEVEL, kiobuf for > MDL) are _not_ 100% the same. > > >Use Firewire for debugging. Also, I would not use a 64 bit operating > >system on either machine, specially on your target - and I may be > >overconservative, but I would install Windows XP in the target if I > >was a beginner. > > Target _must_ be multi-boot. It must be able to boot many Windows versions, > 32 and 64 bit. Don't forget that, for this, you must install Windows > versions in their release order - 2000, then XP 32, then 2003/XP 64, then > Vista/2008, then Win7/R2. > > If VMs are targets - then this has its own advantages. The pipe emulation of > COM port in Hyper-V is much faster then the real serial and is lesser > issue-prone then 1394. > > >3. Download the latest WDK from Microsoft > > Depends on whether w2k support is a must. If yes - then 6001.18002 is a > must, and not a Win7 WDK. > > >4. Download the Windows Debugging Tools - which includes the windbg > >debugger - and install them in your host computer. > > Win7 WDK include them I think. > > >resulting .sys file placed. Learn how to ask for a .pdb file. > > Always generated by default in the same directory as .sys > > >and how to tell Windbg where your source code is. > > No need usually, this is embedded to the .pdb. > > >you will learn about INF files > > Starting with MS-provided INF from \windows\inf and customizing to your > needs is the simplest. > > -- > Maxim S. Shatskih > Windows DDK MVP > maxim(a)storagecraft.com > http://www.storagecraft.com >
First
|
Prev
|
Pages: 1 2 Prev: WDK 7600 missing x64 for XP?? Next: Can WinDbg script extract an EPROCESS address from command output? |