0

I'm playing around with the winapi crate, but it doesn't seem to me to add safety to the Windows API - it seems merely to provide the types and signatures and allows us to program in mostly the same unsafe paradigms, but using Rust syntax.

Is it possible to, say, subdivide the native types further in the Rust FFI to encode the implicit lifetime information so that winapi programming is actually safer? When the winapi allocates to a pointer or a handle which must be deallocated/released with some call, can we attach the correct Drop behavior for that value? Is Rust expressive enough?

Of course we could completely wrap the winapi calls with safer objects that map between caller and the winapi, but that incurs a runtime hit during the copy/mapping and that's no fun.

(Perhaps it's clear, but I'm new to Rust and to the WinApi and even to native programming.)

I realize that string data would usually have to be converted to Rust's UTF-8. But then I wonder if it would be possible to automatically wrap a native string in a memoizing struct where the string doesn't get converted to UTF-8 (transparently) unless it's needed in Rust code (vs just being passed back to the WinApi as the same format).

Handles and pointers though wouldn't need any conversion, they just need the right lifetimes. But there are many kinds of pointers and many kinds of handles and those type differences ought to be preserved in Rust. But then to encode the library-specific free() with a Drop trait impl I think there would be many permutations and then we'd need overloads for other winapi functions which don't care who allocated it. Right?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Jason Kleban
  • 20,024
  • 18
  • 75
  • 125
  • Your question is **extremely broad** and is likely to be closed. I see 4 distinct question marks and there's a handful of other implicit questions as well, with topics ranging from lifetimes to string manipulation, custom drop implementations and memoization. Each individual question has the potential to *itself* be overly broad. Stack Overflow is better suited to concise problems. Perhaps you'd have better luck on [the users forum](https://users.rust-lang.org/) or [the subreddit](https://www.reddit.com/r/rust). Your questions might be suited to SO after being split up and heavily edited. – Shepmaster Jun 15 '16 at 02:57
  • The question isn't about the specifics of these examples - it's about my probable misunderstanding of the big picture. I'm asking what Rust might be able to do for actually adding safety to the winapi vs things that can't be done (because they require something stronger than lifetimes which haven't been invented, or because the winapi has dynamic behaviors which would affect lifetimes in ways that couldn't be known at compile time (?), or whatever) or things that can't be done *in Rust*. – Jason Kleban Jun 15 '16 at 03:28
  • I mention that there are strings, pointers, handles just to mention a few considerations of data that seem to me to require special treatment (as opposed to structure values which seem rather straightforward). – Jason Kleban Jun 15 '16 at 03:31
  • @Shepmaster Do you think http://programmers.stackexchange.com/help/on-topic is a good place for this question? Maybe move it there? – ArtemGr Jun 15 '16 at 11:55
  • 1
    @ArtemGr maybe, but I don't hang out on Programmers enough to be confident about it. The "no specific tools" bullet point would be a bit worrying. Also, I don't know how many Rust folk hang out on Programmers. The great thing about [the users forum](https://users.rust-lang.org/) or [the subreddit](https://www.reddit.com/r/rust) is that OP is very likely to get an answer from the maintainer of the winapi crates :-D – Shepmaster Jun 15 '16 at 12:39
  • @ArtemGr the question rambles a bit making it a little unclear, so it would be best to improve it _before_ migrating it anywhere. It _sounds_ like it might be within the guardrails of "on-topic" at Programmers, but again, see my previous point (I have 20k+ rep at Programmers and have a hard time determining if it is on-topic). That being said, I think Shepmaster has a good point. We don't have much in the way of Rust expertise over at Programmers. –  Jun 15 '16 at 21:56
  • 1
    Usually the way FFI packages work in Rust is that you have an `x-sys` crate which provides the raw FFI bindings for lib `x` and then you have an `x` crate which uses the `x-sys` crate and provides a rust-y version of the api. For example [libudev-sys](https://crates.io/crates/libudev-sys) and [libudev](https://crates.io/crates/libudev). I'm not super familiar with `winapi` but it look to me like it's the raw bindings and not a rust-y version of the Windows api. – Wesley Wiser Jun 16 '16 at 14:43
  • @WesleyWiser's comment is in the right direction to be an answer! – Jason Kleban Jun 16 '16 at 22:46

0 Answers0