> 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.
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.
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.
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.
> 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.
Another good reason to support independent internet archives
Why share something which you can sell for exorbitant prices? /s
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.
Apologies, that's what I meant to say. I blame that on my lack of coffee today, my bad.
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 appreciated the footnote on filesize optimization as someone who's constantly trying to compulsively generate the smallest binaries possible.
Interesting article, thank you.
Thanks for the flashback :)
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.