Expand description

thindx - Thin DirectX wrappers

GitHub Build Status dependency status

crates.io docs.rs License

Thin DirectX wrappers for Rust.

Why not winapi directly?

  • This crate aims to make fns safe/sound/slightly rusty when possible
  • Attempts to verify API soundness through mass unit tests, even if they mostly test DirectX’s behavior.
  • Doc comments for one-stop intellisense, safety documentation, etc.

Why not <other graphics crate>?

  • Most other graphics crates focus on hiding the underlying graphics API as much as possible, improving application portability.
  • This crate surfaces the underlying graphics API as much as possible, improving the potential for interoperability with other graphics code / use in middleware applications.

❌ This crate is probably unsound! ❌

I’m exposing a huge legacy C++ API to Rust. Mistakes will happen.

That said, soundness is a very high priority goal. thindx will add things like extra bounds checks, parameter validation, extra init, etc. if need be in order to ensure soundness in safe fns whenever possible. When it’s not possible to validate unsoundness away, the fns in question should be marked unsafe. This crate strives to be sounder than whatever manual FFI you’d write yourself would be, and that’s a high bar.

But there are some practical limits to this. If a background driver thread invokes UB if it fails to allocate memory, without any direct correlation to specific API misuse like a large integer overflowing, that’s a bug I can’t sanely mitigate via safe fns. I mean, theoretically I could write a pure-software clone of the entire DirectX runtime… but no.

Additionally, while I’m seeking to validate my APIs via testing, older implementations of the APIs in question may have more bugs / unchecked parameters / ??? that I’ll fail to mitigate due to being unable to trigger them myself. While I’m happy to investigate, accept pull requests, expand test coverage, etc. it’s worth assuming this crate is unsound on older versions unless you’ve tested yourself.

⚠️ API major version churn ⚠️

Individual fns are likely to gain/lose unsafe, traits, etc. in a neverending attempt to make DirectX access sound. As such, thindx itself will likely always suffer from major version churn. This isn’t too much of a problem until two crates wish to share / pass thindx types between themselves. It might be possible to somewhat stabilize some types by exiling them into subcrates, but this has not yet been done. Additionally, individual extension traits / functions / methods will likely never get the same treatment (no need?)

Project Status

examplesheader coveragedocs.rslib.rscrates.io

d3dcompiler.dll✔️⚠️⚠️first goal to stabilize
xinput✔️✔️✔️*⚠️* Could use more testing on older Windows
Low Priority
d2dI prefer d3d wrappers?
dsoundprefer xaudio2? (might be needed for gamepad headset audio?)
dwriteconsider uniscribe?
Not PlannedFeel free to change my mind though! Maybe with $?
d3d10d3d11 is the same but saner, and just as portable?
d3dx10deprecated, saner to use less d3d specific stuff
d3dx11deprecated, saner to use less d3d specific stuff
d3dx9deprecated, saner to use less d3d specific stuff
ddrawprefer d2d, gdi, or other less ancient api?
dplayprefer steamworks, raw sockets, etc.?
xaudio1does this even exist? prefer xaudio2
APIAPI coverage seems mostly complete
TestsAPI has basic tests
SoundAPI has enough tests to convince me of it’s soundness
StableAPI seems stable enough to start giving semver treatment


Licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


pub extern crate abibool;
pub extern crate abistr;
pub use errors::*;


Revision history


Rust ⮀ C++ coverage information based on Windows SDK 10.0.19041.0

C ABI interop types

Direct3D related types and APIs used across multiple Direct3D versions.

[docs.microsoft.com] Direct3D 9 related types and APIs

[docs.microsoft.com] Direct3D 11 related types and APIs (including shader reflection APIs)

NOTE: Imported into crate root, no need to prefix errors::

[docs.microsoft.com] APIs for Xbox 360 style controllers


[docs.microsoft.com] A 128-bit identifier used for COM interfaces, COM class objects, and various other purpouses.

An error about some specific method returning an HRESULT

{ kind: ErrorKind, method, errors }

A safer/sounder alternative to HWND


Indicates this type can be treated as an HWND.

Allow conversion to/from raw (winapi) pointer types.