I’m trying to figure out how to write a virtual HID (human interface device) driver for Windows. By virtual, I mean a device that I’ll be able to control from userspace; for example, by feeding it packets received from network. Since I’m rather slowish in this endeavor, and there’s very little sensible documentation on the internet on how to do this, I’ll document my exploration of the WDK (Windows Driver Kit). This will hopefully help me understand things better.
Don’t use this as a documentation, and perhaps not even as an explanation of WDK; I’m just typing down what I currently believe about the subject.
So first of all, there are many suggestions to take a look at the sample “hidusbfx2”. This is located in /src/hid/hidusbfx2. This is a driver for a generic USB-teaching device. This device does not present itself as a HID-class USB device, or else Windows’ built in drivers would take place.
HID-class devices are mouses, keyboards, et cetera. I believe that when docs speak of “HID-class Device Driver” , they mean a generic driver for handling any sort of mouse, keyboard, et cetera. These drivers, I believe, don’t actually know how to speak with the hardware. In case of USB-based HID-class devices, the most common kind, Windows do that automatically. They use their own “HID minidriver”.
So what we need to do is implement a HID minidriver. HIDUSBFX2 is, I’m sure, a pretty good example in case you want to write a driver for something that actually connects to a USB port. I don’t have the cash to afford the board used, and I don’t want to develop a driver for an actual device, anyway. As a beginner, I don’t really know how to separate the hardware layer from the software layer. Hence, this is not such a good example for my purposes.
Luckily, one of the rarest gems I ever dug out from the Internet is vmulti by Daniel Newton. This is a virtual HID driver just like one I’m trying to write, but this one is specialized for implementing multitouch on Windows 7. By its folder structure, it is so obviously derived from HIDUSBFX2 that comparing these two might even yield some results. I didn’t yet do this, however.
I have immediately attempted to build and install vmulti. Unfortunately, its documentation is quite scarce, and there isn’t an explanation on how to build it and install it, and not even a documentation on how to use it. There is a test program however; that’s something I’ll have to take a look later on.
vmulti is a KMDF driver (a kernel-mode driver, but higher-level compared to the old WDM model). Windows, due to architecture of WDF (Windows Driver Foundation) do not support HID class drivers on KMDF level. That’s why Microsoft wrote a “HID mapper”; a thin layer written in WDM to allow KMDF HID-class minidrivers. This is called “hidkmdf”; for Windows 7, you don’t even need to compile it and ship it with your driver since it comes under name “mshidkmdf”. This is what WDM actually thinks the driver is; but, in reality, it’s just a stub, and we write our “filter driver” (HID minidriver) which contains the actual driver code.
So I went and tried to build vmulti, all of its components: Microsoft-provided hidmapper/ folder (containing hidkmdf), vmulti’s sys/ (containing vmulti) and vmulti’s test/ (containing a test tool). I cd’ed into its folder, and I ran command “BLD”, as recommended by Microsoft.
This is where I’m stuck: Windows XP’s Add New Hardware claims there is no information about my hardware when I go to the folder where I put vmulti.inf, and both vmulti.sys and hidkmdf.sys. The alternative I dug out is called “devcon”; it ships with WDK in
Last I’ve tried is a modification of Microsoft’s example how to use devcon/ that came with “echo” example:devcon install vmulti.inf "root\vmulti"
This is where I’m stuck:
Tomorrow is another day! I want to figure this out, and Microsoft did not make it easy, that’s for sure. I’m in a documentation hell; they wrote so much of it, but so little of it is useful.
I’ve switched to WordPress for hosting my blog. This means I’ll perhaps be able to use my blog as my primary web site as well (a presentation of my projects).
I didn’t know I’m supposed to switch off the RSS footer before doing so, hence every imported post contains my RSS feed’s footer. I’m also wondering how much havoc will this wreak on search engine ranking, but we’ll see.
Importing itself was tricky; apparently WordPress people don’t maintain the publicly available Blogger import plugin as much as they should. The one installed on their hosted service, WordPress.com, sports both importing by authenticating with your data, as well as allowing you to upload exported Blogger data.
Publicly available plugin allows only importing by authentication… which fails. I’ve attempted to import from a subfolder on my ivan.vucica.net domain (while waiting for the DNS people to switch the entry for the blog.vucica.net hostname). That is, I’ve installed into http://ivan.vucica.net/wp/ and I can only guess that this is what is causing Google’s AuthSub service to raise hands in disgust and give up.
On the other hand, WordPress.com not only manages to log me in (possibly because http://ivucica.wordpress.com/ is not a subfolder), but it would allow me to upload the data exported from Blogger.
All in all, Blogger people did their work superbly, as did WordPress.com people… WordPress.org people did not. Let’s hope publicly available plugin does not become abandonware, for the sake of future importers. Otherwise, people will have to create temporary blogs on WordPress.com, import from Blogger, and then import into their local installations. And having to do two imports sucks.
If you are looking for an iPhone application to make calls to Google Talk users (and all others who use Jingle extension for XMPP, or XEP-0166), check out Talkonaut. App is currently free on the app store, but I wouldn’t be surprised if that changed; in fact, I’d love it if the developers made extra money by doing so. I’d give back the free version and give a few bucks for the paid version. It’s worth it.
It even contains Jingle-to-SIP conversion; that is, you can use the XMPP connection to establish a SIP connection. SIP is a “more traditional” VOIP protocol, while Jingle is what Google Talk uses.
They also have partnered with many SIP-to-PSTN providers (where PSTN is regular telephony, such as landlines and cellphone), enabling you to make GTalk-to-phone calls for apparently very low prices. At the moment I have no need for such a service, but it might be a good way to pay back for the free app. I’m not getting paid to say all this — as a developer, I can appreciate the numerous hours that went into this project.
After thinking a bit about what I need open-source, and what I’m capable of implementing but too time constrained, here’s a short list. If I had enough cash and if I didn’t have to study, I’d go now and work on some of these.
And I don’t mean just a game browser and installer. I mean the full deal: friends, shop CMS, patching, DRM, DLC, ingame overlay. Friends could work with XMPP, and when I think about it, so could everything else. How about login with OpenID, Facebook Connect, XMPP?
I want a login manager where I can easily write a GUI in OpenGL or whatever I want, and just plug it in with the backend code that’ll handle the login itself.
I started writing that, but then I got a Mac.
I’m sort of obsessed with in-game overlays, right? But that’s what I want to have: a way to talk to my google-talking buddies from in-game. Steam’s in-game browser is NOT a solution. I’ve tried looking around for something like this; I found some open source code for in-game overlays (Mumble VOIP has one), but nothing simple enough for me to fork and add XMPP code and a simple GUI (perhaps using my GLICT or my company’s AprilUI) to be able to have a proper in-game IM experience.
This is not something I can fix even with a lot of time. I try to structure my code well, but that’s about it.
I’ve been through too much OSS code lately that wasn’t commented well. In fact, I know of one instance where I was studying implementation of in-game overlays, and the already-confusing code didn’t have a single useful comment in it. I’ll do an evil namedrop and mention this was, again, Mumble. I want to make it clear: it’s an excellent project, with lots and lots of cool ideas, well implemented tricks such as positioning audio according to the position in the game the speaker and listener are playing, et cetera. But, simply put, when I looked at the code they had in SVN, I found something I couldn’t put my head around.
Functions and classes were oddly named, not to mention files. Platform-specific code was all mixed up and was not separated; while there were attempts to be modular, separation of platform-specific stuff (and when it’s about in-game overlays, you know it’s VERY platform-specific) was done very clumsily. I couldn’t find where the code initializes system-wide monitoring for the launch of a game, and where the overlay is initialized. I gave up.
But this is what defeats the purpose of open source. Why bother releasing it as FLOSS if people can’t learn anything from it? I wrote a lot of code over the years, but if it isn’t instructional or useful, why would I release it as FLOSS? One goal may be to get it into Debian which has a social contract to ship only free software, but if that’s the entire point, then say so.
Don’t insert assembler blobs without commenting them (oh yes, that too).
What do YOU want from open-source community that you can’t find? Or, can you imagine a financing model for developing the above? Tell me your thoughts!
In Xcode 3.2.4, it’s trivial to create same project for iOS and Mac OS X. Just add a new target into your existing project; if your project is for OS X, then create a new Cocoa Touch Application target. If your project is for iPhone, obviously, craete a new Cocoa Application target. Then do a Get Info on your new target, and choose the appropriate Base SDK. For simplicity, let’s presume you’re adding an OS X target to an iPhone project.
However, after doing this, you’ll quite probably find that despite the choice of Base SDK in your target (you used Get Info on it, didn’t you?), Xcode has locked the target SDK onto whatever your project originally used. That is, now you’ll find it locked onto iPhone, despite switching to the OS X target using the Overview dropdown (in the top left of your Xcode project).
So how do you actually switched the now-locked SDK? Quite simple. Hold the option key while clicking in the Overview box. Instead of only two-entries device list (if you have an iPhone target selected), and then Active Configuration, Active Target, Active Executable and Active Architecture, by holding the option key while clicking on Overview you’ll also find the Active SDKs list. By switching it to the appropriate OS, you’ll be able to compile the application.
Of course, now comes the hard part: actually porting the code to the new platform.
E49PEQSG669E
