DirectInput is the name of the library in Microsoft DirectX at provides direct access on Windows to input devices such as the mouse, keyboard, and game controllers. Well, except that for some time, there's been nothing "direct" about DirectInput at all. Ever since Windows NT, pretty much all of the functionality in DirectInput can be replicated by going straight to the Win32 APIs and using functionality such as low-level keyboard hooks and raw input messages. Once you learn this, some of the restrictions of DirectInput become clear, such as why you can't reliably intercept input from a full-screen application using your own low-level keyboard hook.
I found this passage in the DirectInput docs for EnumDevices() today, which I found especially amusing:
On Microsoft Windows XP, DirectInput enumerates only one mouse and one keyboard device, referred to as the system mouse and the system keyboard. These devices represent the combined output of all mice and keyboards respectively on a system. For information about how to read from multiple mice or keyboards individually on Windows XP, see the WM_INPUT documentation.
Not only is DirectInput not direct, but it's even less direct than the regular Win32 API....
(See also: "DirectSound" and "Windows Vista.")
I guess it's a much more common scenario for people to want multiple keyboards or mice to act identically than for a program to read them separately, but it seems like DirectInput would be the natural place to expose such functionality. There's so much API churn in Windows lately that I think Microsoft bought a blender.
Microsoft doesn't actually seemed to have so much DESIGNED their APIs (not since the early '90s anyway) as sort of tacked things on over time. The Windows API now resembles a building that has been added on to several times by different architects with different ideas about what it should look like.
What Microsoft really needs is a unified design for their products, something that's still very far from happening. I hope Windows 7 will have at least some improvements.
TechMage89 - 19 03 08 - 10:32
That's nothing. XP doesn't let you use more than 1 bluetooth (SP2 drivers) mouse at a time (even though they swore it is possible when I called support before buying 1 bluetooth desktop set + 1 bluetooth mouse with remote control abilities. Maybe they it also doesn't let you use two bluetooth keyboard at a time, but I only have one, so...
guest - 19 03 08 - 12:16
I remember a time when a friend came over only bringing his mouse to plug it into my amiga. Then we played The Settlers on one computer with two mice in split-screen-mode for hours...
Murmel - 21 03 08 - 05:33
I've seen some games that support split screen play with two mouses on Windows, but the only way to do it was using a serial mouse, with the game implementing the communication protocol itself.
John - 22 03 08 - 06:04
On the matter of DirectInput, keep in mind that it was originally designed for 9x, not NT.
Yuhong Bao - 23 03 08 - 16:35
@TechMage89: Thats exactly my opinion. Win32 ist very old and obviously nothing can be dropped because of compatibility. in contrast the .net framework is very consistently designed with only a few weak points that slipped through quality control. win32 is far from dead and will still be used in 10 years but i expect a continuous shift towards managed code. that is especially true considering the enormous investments by microsoft into the .net platform (including silverlight running on linux and mac). hopefully the necessity of using win32 will be over soon.
Tobias Rieper - 29 03 08 - 18:47
"hopefully the necessity of using win32 will be over soon."
I hope not. I like making compact apps using win32 that don't rely on huge .net installations to work and are slow to start. I agree with TechMage89's view of win32 though.
Barry - 29 03 08 - 20:36
I'm sorry, but I don't want to hear any fairy tales about how .NET is magically going to fix everything. It's good if you want to do business applications in C#. It kinda sucks other things, and the fact that Microsoft is moving so much API development towards it while integrating it into the OS means that it is gaining ground at the detriment of everything else. Explain to me again how you do real-time applications in an environment that uses a compacting garbage collector? The Windows Vista sound system is deliberately not managed for this reason. How do you implement full-fledged continuations when .NET is still heavily based on the same non-relocatable stack paradigm for control flow?
I'm tired of hearing how everything should switch over to .NET when it completely lacks all of the following: a sane hosting API, the ability to start the CLR more than once ever in a process, or any access to vector instructions or alignment support in the GC. Then let's proceed to the Framework, which still lacks a good collections library (System.Collections.Generic is still terrible), a binary writer that can actually write big endian, and a hardware accelerated drawing API. Or we can look at the flagship language C#, which still lacks a static optimizer that can do the most basic of optimizations and exacerbates JITting time, doesn't let you get to inverse P/Invoke to export DLL entry points, and which has a really broken project system which constantly unnecessarily rebuilds assemblies and doesn't let you use netmodules.
I don't know where this belief comes from that .NET is so incredibly good. Yeah, it's definitely better than Win32 -- low bar. It's probably better than Java 1.0 was. It still contains holes big enough to drive a truck through.
Phaeron - 29 03 08 - 21:32
every single point you mention is correct. but for every negative aspect you found i'll give you a large IList of things which make you more productive in managed code compared to native. by a factor of 5x. clearly, managed code can not be applied to all problems: drivers, heavy computation, low-level, realtime. but how many percent of all code depends on things in this list? i guess about 5% in total. no tool is perfect, but .net is well suited for most things. it has its disadvantages, for example in performance, but this is not a show stopper. look into your taskmanager and tell me, how many processes do you find consuming more than 5% cpu? dont cheat by turning on media player or sql server, as i already said that those are no good scenarios for managed code.
i am not interested in a religious war of languages and plattforms. i use the tool that makes me most productive. for virtual dub and the like, this is c++. for the rest, its managed code.
Tobias Rieper - 30 03 08 - 11:46
Managed code? .NET? God forbid! I'm an inveterate tinkerer and efficiency freak and those would be like tying an anchor to my applications. I don't like win32, but that's more because it has sloppy design. I like my low-level access.
TechMage89 - 30 03 08 - 14:38
You have a problem with your logic. Writing an application is not about YOUR productivity -- it is about the productivity of the END USER. I don't give a damn whether you can write 5x more code using .Net, ask any other end user and they will tell you the same thing.
Moreover, I don't have any advantage from you being more productive. I don't get 5x cheaper application. I don't get 5 good applications for the price of one. I don't get 5x faster or 5x easier to use application either.
The only benefit is that you have less work to do and I the end user have more. I have to download and install .Net Framework, download and install updates and when you migrate to newer version I have to download and install that too, and when I run out of disk space and RAM and CPU cycles I need to go shopping for a new PC. Rinse, repeat.
Finally, your percentage is screwed. There is considerably more than 5% of applications which need performance. From my point of view all 100% of them do. The problem is that everyone and their uncle want to "be more productive" as in "make pretty GUI faster" (VB Forms anyone?) while the basic functionality of the application still sucks big time.
So please, stop evangelizing .Net because you are in the wrong place. Here people know a thing or two about programming or they wouldn't be reading Avery's blog.
Igor Levicki (link) - 20 04 08 - 23:18