Should this check the return value?

Yep, that definitely needs to be handled. In fact, I've just now done some work in that direction. I've decided to move some of the unsafe logic into a separate crate, winx. My plan with this crate is to essentially imitate nix crate (to a degree of course).

Anyhow, now the calls to close a raw Win handle check for errors, and so does duplicate and writing the IoVec to a handle. Anyhow, for the latter, have a look here.

Do you know if WSASend works on files? If not, should we iterate over the iovecs and call WriteFile on each individually?

That's an excellent question. I've been wondering about that myself as well. The short answer is, I'm not sure. However, the current implementation you've highlighted here is taken verbatim from Rust nightly's implementation. In Rust, a call to IoSlice write_vectored eventually resolves into default_write_vectored.

In Rust, IoSlice is also a wrapper around WSABUF, however, it seems it's reserved only for file operations which I'm guessing would exclude sockets? Anyhow, I think it might be prudent to have a closer look at WSASend as well as the general implementation advocated by Rust and see what's what, and what to use. For the moment, I'll leave it as is, however, I'll come back to it when I get the WASI tutorial working. Having said that though, if you come up with something, then please fire away!

Can the logic for determining if we need read and/or write here be factored into a utility function that can be shared with the unix impl?

Ah, a great question! With the winx crate, I think the hostcalls will start to share more and more code between *nix and Windows, so we'll definitely have some room for refactoring here. Perhaps we could twist it slightly and have the hostcalls (as the public API entry) outside of host specific modules, and have them call host specific bits only? I'm wondering how messy would that be? Anyhow, definitely something on my radar! :-)

Sharing code to this degree would be great, though not if it makes things more complicated, so we'll see where it goes :-). Factoring out the code for inferring read/write here would be especially nice because deciding exactly which rights determine this is tricky, and fairly likely to change as WASI evolves.

I've factored out common functionality in #26. Have a look!

FWIW a helpful pattern I've found in the past is that instead of from_raw_* plus forget you can do:

let file = ManuallyDrop::new(File::from_raw_handle(raw_handle));
let meta = file.metadata();
// ...

and the usage of ManuallyDrop means you don't have to call forget and can continue to use the File if necessary

Nice one, thanks! That's a fantastic suggestion :-)

Done! For the moment, I've decided to only include it in the bits pertaining this very PR (so Win only), whereas I'll re-apply the suggestion to *nix bits in a separate PR.

FWIW we explicitly ignore errors in the Rust standard library for errors on close. We largely do that to mirror weirdness on Unix, but perhaps this should mirror that?

(or would it be possible to use a File from the standard library maybe?)

Thanks for the pointer! So the reason we've got error handling here is essentially because I mirrored the implementation here from the corresponding *nix implementation in wasi-common. Having said that, it might indeed be obsolete :-)

(Hmm, perhaps we could use File instead. If we could, then, again, we could consolidate a fair amount of *nix and Win code, so it'd be amazing!)

Ah yeah that makes sense (mirroring) and I don't want to try to pile on too much into one PR which is just trying to get things done!

Out of curiosity, is it possible to use File::duplicate from libstd?

Hmm, good question. I bet it would be as, as far as I can remember, File::duplicate at the very bottom uses DuplicateHandle syscall.

Yeah I was reviewing and the code was pretty similar to libstd here, so was just a passing though. In general though avoiding platform-specific code where possible and using libstd aggressively would also naturally fix things like this.

This is sort of a random drive-by comment, but this seems like it might be a useful API to share across Windows/Unix?

That's an excellent observation which becomes even more relevant given your comment below about vectored IO getting stabilised really soon :-) I reckon then we could indeed nicely consolidate ciovec for both platforms by using IoSlice and IoSliceMut as the return type.

Although not stable yet (but next week will be!) it'd be cool to get an underlying &File for both Unix and Windows and call write_vectored here, and that way there wouldn't need to be any platform-specific code at all for handling Unix/Windows and writev for files.

It does get a little more complicated with sockets, but it's more complicated anyway with sockets in general. It may also be solvable by having a platform-agnostic API to get something like an io::Write or io::Read from a file descriptor number for operations like this.

Oh nice one! You've probably already noticed that I've based winx::io::IoVec on IoSlice from libstd so I'm really excited for write_vectored becoming stable! I'll for sure revisit redoing the writev/readv functionality with write_/read_vectored!

In terms of sockets, you can say that again! I've been essentially trying to steer away from any socket considerations for now, but if libstd would handle it transparently behind the scene, that would be magic! In fact, if you feel I could help out with anything in libstd, just give me a shout! I've been scrutinising it quite a bit over the past month or so, and would definitely be happy to lend a hand wherever I can!