That doesn't bother me per-se - those all caps names are pretty much all directly from the standard C bindings, and it makes sense to preserve that naming for the sake of having that 1:1 mapping with the ground truth C definition.

The actual issue here is that this "simple driver in Rust" is having to touch those direct C bindings at all - if Microsoft is going to advertise that they have support for writing drivers in Rust, that should presumably mean an API surface that's native to the language.

I believe Rust has added the ability to mark FFI functions as safe to call at their definition site (https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-...)

That way functions can be marked as accurate/"ok" to call in safe code by the author of the bindings. They could absolutely not be safe; in that case, the binding author is in error marking it so.

> that should presumably mean an API surface that's native to the language.

It reads pretty naturally to me as referring to the implementation of the driver.

This is pretty normal for Rust code that FFIs to external libraries.

There's a lot more complexity in writing FFI code - you have to think very carefully about everything you do. Case convention is a triviality here.

In Delphi the Windows types are declared as-is, ie with all caps, but then most of them are aliased to more Pascal-like names.

So you can use TRect and TPoint and pass those to PtInRect[1] which expects RECT and POINT respectively.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...