> Microsoft has only kept the documentation for the DX8 version of EnumDevices left online
This saddens me. Who knows how much valuable info has been lost. I recall back in the days of MSDN, we had docs back to early Windows, and it was a wonderful historical record. Today's Docs site seems to keep info only for a few versions.
AFAIK they are all backed up. For the blogpost I used the DX5 SDK docs, DX7 SDK docs, and the MSDN Library from VS2005 (last version to include 9x information).
The VS2008 version purged all API information regarding pre-Windows 2000.
Oh geez, I have them, probably from the 00's. I tried to get into Windows programming, but it was all over my head.
Incredible that a few decades after thinking "All the world's knowledge will be online", we probably have to return to physical libraries to find the knowledge that ended up not being online anymore.
That's only kind of true; Wine itself supports older versions of DirectX with the target API being OpenGL instead of Vulkan. It's just not quite super performant and kinda buggy. That said, there's other wrappers you can use to convert older DirectX versions into new ones, and if you can get to DirectX 8 or 9, now you've got DXVK.
I have had very bad success rate with my old Windows CDROM/DVD era games. Pretty much all of them either have some kind of DRM or they run but with bugs.
When available I just buy the GOG versions instead, but even those versions sadly often have issues.
Meanwhile slightly older games from the DOS era works perfectly everywhere thanks to DOSBox. I would love to see something like that for old Windows. Merge DOSBox with WINE, someone?
Its interesting to see how bad assumptions that almost certainly held up at the time really don't any more and that leads to this bug being exposed. Modern machines have a lot more addressable devices and a failure to properly filter and using a vector ultimately leads to a bug that on the surface feels like since it works on Win98 must be caused by Windows but isn't.
I mean that's just a bad assumption no matter how anyone looks at it - if you created an array for 8 devices then just stop adding to it when you reach 8. The "a user will never have more than 8 gamepads" is a bad assumption because the logical question then is "what if they do" and the answer even back in the day would have been "the game will crash" which isn't how any code should be written. Stop processing at 8 if you are so sure there will never be more than 8, but have the most basic sanity checks.
Back in the days of manually setting IRQs enough of them were used by the system that no, you couldn't use 8 gamepads. Assuming you could even connect them.
(I think this game is probably past those times but not by much)
I specifically checked if DirectInput from DirectX 5 already supports/provides USB HID devices, and it does! Granted, even then it was unlikely to encounter 8 USB devices, let alone HID devices in particular.
I was quite interested in the patch -- am I right in thinking the DirectX library only exports a single function and _everything_ else is through DX interfaces?
I expected to see significantly more code, pass-through to the original DLL.
The cool part of this adventure is that the author was able to write this DLL patch purely in rust! Good testament of how far it has come. Can't wait to see more C code ported to either Golang or Rust!
This is pretty amazing, and I'm surprised in a sense by how few workarounds you've had to implement. It makes me wonder what Windows would look like if we had Win2K or Win7 with today's system APIs (for high DPI, increased security etc.)
I know Windows has made great strides in security, but I deeply miss the old Windows and this really hits home about how _little_ has fundamentally changed, or rather, how much the continuance of these APIs means today's Windows could be like old Windows, if MS wanted.
I came across Windhawk a couple of days ago here on HN, a system to patch Windows to look and behave more old-style; wow.
Because I felt like it :) Also works for multiple versions/patchlevels.
But yeah, with the info provided it should be patchable. It's a `push esi` though, where esi has to stay 0 for a few further usages, so it's a bit more than a one-byte patch. It also wouldn't fully resolve the OOB write in the rare case where you _do_ have 9+ game controllers connected.
I feel like this is a cleaner solution. As a user you don't have to faff around running a whole application just to change 3 bytes. Just drop this file in and go.
> Microsoft has only kept the documentation for the DX8 version of EnumDevices left online
This saddens me. Who knows how much valuable info has been lost. I recall back in the days of MSDN, we had docs back to early Windows, and it was a wonderful historical record. Today's Docs site seems to keep info only for a few versions.
Anybody who still has MSDN Library CDs from the 90s, archive them at archive.org NOW!
AFAIK they are all backed up. For the blogpost I used the DX5 SDK docs, DX7 SDK docs, and the MSDN Library from VS2005 (last version to include 9x information).
The VS2008 version purged all API information regarding pre-Windows 2000.
Oh geez, I have them, probably from the 00's. I tried to get into Windows programming, but it was all over my head.
Incredible that a few decades after thinking "All the world's knowledge will be online", we probably have to return to physical libraries to find the knowledge that ended up not being online anymore.
Also of note Valve's Proton only goes back to DX8. Versions prior to that were considered not worth it.
That's only kind of true; Wine itself supports older versions of DirectX with the target API being OpenGL instead of Vulkan. It's just not quite super performant and kinda buggy. That said, there's other wrappers you can use to convert older DirectX versions into new ones, and if you can get to DirectX 8 or 9, now you've got DXVK.
Another good reason to support independent internet archives
Why share something which you can sell for exorbitant prices? /s
They are not selling it either.
Then, where are the docs if they are not publicly available?
I have had very bad success rate with my old Windows CDROM/DVD era games. Pretty much all of them either have some kind of DRM or they run but with bugs.
When available I just buy the GOG versions instead, but even those versions sadly often have issues.
Meanwhile slightly older games from the DOS era works perfectly everywhere thanks to DOSBox. I would love to see something like that for old Windows. Merge DOSBox with WINE, someone?
Usually dgVoodoo handles most of the games (that don't have actual bugs like this game) fairly well.
Otherwise, 86Box is a pretty good full-system emulator for everything up to the early 3D era.
As for DRM, there's various ways around it of course :)
You can run Windows 95 in DOSBox. You could also just run WINE which runs most old games.
You can use WineD3D for Windows.
Its interesting to see how bad assumptions that almost certainly held up at the time really don't any more and that leads to this bug being exposed. Modern machines have a lot more addressable devices and a failure to properly filter and using a vector ultimately leads to a bug that on the surface feels like since it works on Win98 must be caused by Windows but isn't.
I mean that's just a bad assumption no matter how anyone looks at it - if you created an array for 8 devices then just stop adding to it when you reach 8. The "a user will never have more than 8 gamepads" is a bad assumption because the logical question then is "what if they do" and the answer even back in the day would have been "the game will crash" which isn't how any code should be written. Stop processing at 8 if you are so sure there will never be more than 8, but have the most basic sanity checks.
Back in the days of manually setting IRQs enough of them were used by the system that no, you couldn't use 8 gamepads. Assuming you could even connect them.
(I think this game is probably past those times but not by much)
I specifically checked if DirectInput from DirectX 5 already supports/provides USB HID devices, and it does! Granted, even then it was unlikely to encounter 8 USB devices, let alone HID devices in particular.
I was quite interested in the patch -- am I right in thinking the DirectX library only exports a single function and _everything_ else is through DX interfaces?
I expected to see significantly more code, pass-through to the original DLL.
> am I right in thinking the DirectX library only exports a single function and _everything_ else is through DX interfaces
Yup! That's why I didn't have to create a gazillion passthrough functions.
The original DLL in my modern Windows installation has these 8 exports:
The game only calls DirectInputCreateA, and the rest happens via the COM object that that function creates.The author linked to the repo and the code is at https://github.com/seritools/castrol-honda-dinput-fix/blob/m...
Seems pretty straightforward. They hook DirectInputCreateA() and pass their own device enumeration wrapper with the offending flag removed.
The flag DIDEVTYPE_JOYSTICK was added by this fix not removed.
The idea is, rather than handle up to 8 devices, otherwise UB and usually crash, handle up to 8 "joysticks" and disregard any beyond that.
I'd just use WineD3D in this case; I'm sure there's dinput.dll too ported to Wine for Windows.
Apologies, that's what I meant to say. I blame that on my lack of coffee today, my bad.
The cool part of this adventure is that the author was able to write this DLL patch purely in rust! Good testament of how far it has come. Can't wait to see more C code ported to either Golang or Rust!
I chuckled at the callout to Rust9x. Neat to see it pop up randomly.
Author here -- given that r9x is also my project it wasn't entirely random :^)
This is pretty amazing, and I'm surprised in a sense by how few workarounds you've had to implement. It makes me wonder what Windows would look like if we had Win2K or Win7 with today's system APIs (for high DPI, increased security etc.)
I know Windows has made great strides in security, but I deeply miss the old Windows and this really hits home about how _little_ has fundamentally changed, or rather, how much the continuance of these APIs means today's Windows could be like old Windows, if MS wanted.
I came across Windhawk a couple of days ago here on HN, a system to patch Windows to look and behave more old-style; wow.
I appreciated the footnote on filesize optimization as someone who's constantly trying to compulsively generate the smallest binaries possible.
Interesting article, thank you.
Nice write-up. Reminds me that debugging is the most fun part of programming!
I love hard-core deep debugging for stuff like this. Great work!!
Why an extra DLL instead of just patching the game executable? With some luck it is a one byte patch (from push 0 to push 4).
Because I felt like it :) Also works for multiple versions/patchlevels.
But yeah, with the info provided it should be patchable. It's a `push esi` though, where esi has to stay 0 for a few further usages, so it's a bit more than a one-byte patch. It also wouldn't fully resolve the OOB write in the rare case where you _do_ have 9+ game controllers connected.
I feel like this is a cleaner solution. As a user you don't have to faff around running a whole application just to change 3 bytes. Just drop this file in and go.
Thanks for the flashback :)