My application needs to behave as a virtual joystick (imagine dragging a square with the mouse and translating that to the output of an analog joystick) and send some keystrokes over the network to another computer where the driver would receive that input.
I only need to support XP, Vista and Win7.
Maybe it can be done without writing a driver. I tried sending keystrokes with SendKey() which seemed to work but don't know how to emulate an analog joystick.
I've downloaded the VDK and been reading everything I can find on the subject but there are lots of things I still don't understand. Can you please point me in the right direction?
Should I build a kernel-mode or user-mode driver?
Can my driver act as a server for an app on the network?
Do you know good tutorials / books / samples that can help me with this.
Thanks
First of all you will have to have some kind of interface between your computer (or the network) and the joystick device that is being controlled.
If it involves making custom hardware to control the analog joystick (like it controls pneumatics or hydraulics or something, not just a pc game joystick type thing), then yes, you will almost certainly need a driver to allow a network app to move (the robot arm, or whatever) will move that joystick.
If you are able to remove the physical joystick from the equation, maybe you can write software that emulates the input of wherever the joystick used to plug into (a joystick/serial port?), or emulates it completely (a reasonably simple driver could do this). You could do it completely without writing a driver if the joystick used a standard communication interface (like RS232) because libraries exist that will handle all that and you can set up virtual COM ports that will be indistinguishable to whatever you are trying to communicate with.
The best book you can buy on driver development at the moment is Developing Drivers with the Windows Driver Foundation
Rootkits: Subverting the Windows Kernel is another great book, but doesn't cover a lot of the newer WDF stuff. It has more of a security focus but has a few awesome chapters on device drivers with fully spoonfed examples, breaking it down in a really accessible way.
If it is only over the network, probably simple socket programming should be enough.
Related
I have just begun a new project. I'd like to make my own simplistic computer mouse, since i'd like to learn how to program hardwear drivers and understand the protocols the hardwear uses. I have experience in both desktop and microcontroller programming. However, I haven't got a clue about how to write drivers. I'm working on a mac with OS X and the mouse only needs to be able to talk with OS X. I expect to use a MSP430 microcontroller from TI. I intend to connect my mouse via USB. I simply want to be directed in the right direction not specific help with the coding, yet. :)
I therefor have a couple of questions:
Should I write my own driver or is it possible to use a standard one?
If yes, what kind of driver should be written and where do you begin?
What kind of data should be sent to the mac to say, "Hey, I'm a computer mouse"?
Which protocols should I read about?
You can check USB HID articles for OSX side and if there exists for MSP430.
I think that you can use any other driver, if you emulate same behavior of the target device on your MSP side.
I've been on a little adventure learning about how Windows platforms deal with sounds. Now I know a couple of things from taking an Operating System class and reading this:
IO devices such as a sound card communicate with the OS through a device driver. Microsoft supplies a standard so that in kernel mode the OS can make certain system calls (in this case Win32 api calls) to make an I/O device do something. Bytes or characters are streamed to over buses to whatever port the I/O device resides in. These are interpreted by the device controller as instructions for the physical hardware.
There are OS calls to prepare audio devices and stream data to them. Actually for some reason their are 2 ways to do this: MMSystem and DirectSound. I think the reason there are 2 has something to do with gaming? Like DIrectSound was more geared toward that while MMsystem was more standard apps that need audio?
Beyond that their are also other audio APIs NOT written by microsoft for the Win32 platform. ASIO and GSIF.
How can these non Microsoft standards exist on the Windows platform? How can they possibly communicate with hardware or the OS? With something like openGL(something else I toy with), a version of Windows supports a version openGL standard and so does you GPU. BAM, easy-peasy no problems, everything checks out.
How I see it can be is:
MMsystem and/or DirectSound are not part of Win32, but there is some even lower level windows kernel driver everyone is keeping a secret because it's really ugly or
These other driver API's are built on top of the Microsoft supplied ones
Can someone please clarify? Where am I mistaken, I am missing something. I own my old OS textbook still(Modern Operating Systems 3rd Ed. by Tanenbaum) so if you want to point at something in there, go for it.
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.
I need some advice on windows programming, MIDI and WDM. I am trying to write a small application that will sit in the sys tray and be advertised to the system as a MIDI In/Out device so that MIDI programs can send to it and it will convert the messages into a different format. I have been reading Cant's WDM book and scouring for information about writing device drivers, but don't know if I'm going down the right path.
I don't see yet how to:-
a) register my driver as MIDI capable (do I stick a ref to it in the registery and let the OS direct MIDI calls to the functionality in a dll?)
b) direct MIDI data through the my driver to my app, which is probably going to be too large to be a driver itself.
Any advice on where to start would be much appreciated.
thanks,
Pete
Windows MIDI drivers do not need to be implemented in the kernel, they can be implemented entirely in userspace as DLLs.
MSDN has some information about the functions you need to implement -
Audio Device Messages for MIDI - unfortunately it is somewhat lacking.
There used to be sample code for this kind of driver, as part of the NT4 DDK, but more recent releases of the DDK / WDK unfortunately don't include it any more.
Some better (though older) documentation and sample code can still be found after some searching:
Introduction to Multimedia Drivers (From NT4 DDK)
Sample MIDI Wine Driver for Mac OS X
Devices are enumerated (or simulated) by device drivers, not applications. What you see in the sys tray is an application icon. Hence, you will need to have both a driver and an app - you can't have one bit of compiled code acting as both.
On the driver side, you probably want to have a peek at the MSDN docs. This will answer part (a) of yopur question.
Assuming that you still would like to continue, (b) is best don by letting your application pull the data from the driver. That's far easier than the other way around - an application can trivially find a driver, but a driver has big problems finding a specific app (process)
If you are looking for a bit easier way to get started, there is a MIDI loopback driver out there, and the folks that make it also offer (or used to offer) a version of it that allows your program to communicate directly with the driver. This gives you the behavior you are looking for, where a program appears as a MIDI device. The loopback driver is at http://nerds.de/en/loopbe1.html. I don't see the developer page anymore, but if you contact them, you might be able to purchase a license to a driver that you can access directly without the loopback.
I know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.