Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Developing Drivers Where to start 2

Status
Not open for further replies.

cyberbiker

Programmer
Mar 16, 2001
431
US
I do not know this is not the proper forum for this, but this is my best guess as to where to start so please aim me the right direction if I am wrong about where to post.

(I an cross posting in the VB6 and VB.Net forums alsso)

I need to write what would IN EFFECT be a mouse driver for a USB mouse in that I would be inputting the same basic input as does a mouse.

I have never done anything remotely like this and have no idea where to start.

I would like to use VB6, but could also use VB.net or C++ if I need to.

Sample code for a mouse driver would be great if any body could aim me towards some.

Terry (cyberbiker)
 
I have a similar question but in regards to an older joystick I have (no XP driver and the company went out of business). All the google searches I did ended up at Linux sites or something totally unrelated.

My guess would be we'd need to use something "lower-level" than VB (C++ possibly with some assembly). Sorry that I don't have any answers for you, but if you find something out please post.
 
Will do.
I am strictly guessing here also, but I would think there should be some documentation somewhere from microsoft about this, but I have not had any luck with any searches and I have a time deadline to say "yes I can do this" or "You'll need to find a qualified person".

The basics are to capture the signals from the input device which is basically done already (previous project for this client) then to make the computer "think" that they are mouse clicks which will then be passed on.

Terry (cyberbiker)
 
Hi, cyberbiker. Actually writing a driver for any OS is not as simple as having some sample code for such. Windows works with the so called VxDs (VDDs under NT) or virtual device drivers. These are programs which operate in the ring 0 level of the OS which means they are allowed to do anything. User applications, on the other side, are restricted in doing a lot of things and one of these is the direct access to system hardware or peripherals. This is where the device drivers come into use. They are exploited as an interface for the user applications to call specific hardware or OS-specific functions. If you have written programs for DOS (where user programs and OS work in the same privileged CPU level), you should have pretty good knowledge of what a VxD can do - anything - interrupts, direct memory access, anything. That is why when writing a VxD you should be extremely careful because Windows cannot protect itself from poorly-written drivers and it can pretty easily just hang. Now something more specific: usually it is a good practice to write drivers in assembly or more rarely in C. It is inconvenient to write something low-level in a very high-level language. I think it's clear that you should very well understand the underlying hardware - in this case - your USB mouse. USB has a simple serial interface but actually a very complex communication protocol. It will be easier for you not to implement USB specific communication stuff but rather use Microsoft's drivers and using a high-level language to implement their USB interface. You can find the USB driver files by checking in Windows' device manager for the USB stuff. You should then try to find some documentation on the interface that specific driver provides for user apps but I am not sure if Microsoft publish things like these. Anyway - worth a try. I didn't say it's gonna be easy. Just easier. Otherwise, the VxD is like a dynamic library. The Win32 API provides functions which you can use to grant access to the VxD's services. Check DeviceIOControl API call. You have Win32 SDK Reference, don't you? If not - get MSDN. Also you'll need the Drivers Development Kit provided by Microsoft as well in their MSDN series. The DDK includes header files for C and assembly which you must use in your driver program in order to compile a working VxD. After writing the VxD you should probably make a user app to use it and configure it. And also I have seen USB-to-COM converter integrated circuits which you can use to translate between USB and common RS232 signals (one IC I've used is: PL2303 Prolific Design). They have accompanying drivers which provide you with a virtual COM port which is a whole lot easier to use than USB. I guess what I said is pretty general in nature but I hope it'll help in some way.

Best regards,
Ivan
 
Thanks to Dex an AirCon for your help as well as VB5programmer for pointing out that I should not have cross posted. (Sorry)

Air Con, I am looking over the Information on Microsofts site.
I swear I tried every search except DDK!

Dex,
Your answer cleared up a lot of what I "suspected".
I may need to walk away from this one. This client may have already been turned down by several other people before contacting me. I am not the best developer out there, but I will tackle projects no one else (locally) wants to do. So far, I have gotten by but this project may be more than I am capable of.



Terry (cyberbiker)
 
Terry,

I have to agree with dex1123. The sample provided in MSDN is just creating a simple VXD/SYS one. The hardest part is how you interface with the hardware itself. Having Assembly knowledge will indeed helpful.

If you still want to try to find more info about the USB itself, you won't find it at MSDN.

Intel site, USB EHCI Specification:

USB org, USB 2.0 Specification (USB 1.x as well):

Regards

-- AirCon --
 
A couple or three books that may help you decide are

Writing Windows Vxds and device drivers by Hazzah, R&D books.

Writing Windows Device Drivers by Daniel Norton, Addison Wesley. (Note this is Win3.1ish).

Systems Programming for Windows 95 by Oney, M$ Press, out of print & now expensive.

rgds
Zeit.
 
Hey, cyberbiker. I didn't mean to make you quit this task. Great regrets. You can always think it over. People learn new things constantly. Beginnings are always tense.

regards
Ivan
 
No problem Dex.
I actually never quit anything. When I run into a brick wall I generally "Beat my head against it until the wall gives up."

But in this case, I am working on something else I would have to back burner. I doubt my client will be willing to pay enough for me to make any money on this.

However, we may be looking at this the wrong way also.

I cannot give too many details as to what they are working on which makes it very difficult to ask an intelligent question. And honestly, I do not quite understand (yet) exactly what questions I really need to be asking.

So I am searching for the info. The information you guys gave me has been a big help. Perhaps even more than you realize.









Terry (cyberbiker)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top