feat: make compile pass on windows

[loongs-zhang]

Simply supporting compilation on Windows is already a huge workload. This PR solves most compilation errors, and I found that the buf module is missing msg. Do you plan to manually assemble libc::msghdr/windows_sys::Win32::Networking::WinSock::WSAMSG directly? @ihciah

[loongs-zhang]

@CarrotzRule123 Could you please help me?

[ihciah]

Thank you so much! Supporting windows requires a lot of work.
I have little background knowledge about winapi, can you clarify the

manually assemble libc::msghdr/windows_sys::Win32::Networking::WinSock::WSAMSG directly

?

[loongs-zhang]

For example, in monoio/src/driver/op/send.rs:103

impl<T: IoBuf> Op<SendMsg<T>> {
    pub(crate) fn send_msg(
        fd: SharedFd,
        buf: T,
        socket_addr: Option<SocketAddr>,
    ) -> io::Result<Self> {

// manually assemble the libc::msghdr
// I think we should add `msg` submodule for `buf`

        let iovec = [libc::iovec {
            iov_base: buf.read_ptr() as *const _ as *mut _,
            iov_len: buf.bytes_init(),
        }];
        let mut info: Box<(Option<SockAddr>, [libc::iovec; 1], libc::msghdr)> =
            Box::new((socket_addr.map(Into::into), iovec, unsafe {
                std::mem::zeroed()
            }));

        info.2.msg_iov = info.1.as_mut_ptr();
        info.2.msg_iovlen = 1;

        match info.0.as_ref() {
            Some(socket_addr) => {
                info.2.msg_name = socket_addr.as_ptr() as *mut libc::c_void;
                info.2.msg_namelen = socket_addr.len();
            }
            None => {
                info.2.msg_name = std::ptr::null_mut();
                info.2.msg_namelen = 0;
            }
        }

        Op::submit_with(SendMsg { fd, buf, info })
    }
}

I also have some doubts about SendMsg and SendMsgUnix. It seems that SendMsgUnix should be used in #[cfg(unix)], and SendMsg should be used in #[cfg(windows)] ?

[ihciah]

It seems that SendMsgUnix should be used in #[cfg(unix)]

Yes, you are right. It is used by unix datagram and seq_packet, so it is unix only.

Manually construct msghdr should be ok. Maybe WSAMSG should be ok too since it is a repr(C) struct? Our first step is to try to get it work, so if it can work correctly, it is ok for now:)

[loongs-zhang]

Got it, so RecvMsgUnix also has a similar problem.

I plan to use SendMsgUnix/RecvMsgUnix as an alias for SendMsg/RecvMsg to ensure good compatibility.

Then refer to the implementation of monoio/src/driver/op/write.rs:17 to finish SendMsg&RecvMsg in the next PR.

Any other suggestions? @ihciah

[ihciah]

use SendMsgUnix/RecvMsgUnix as an alias for SendMsg/RecvMsg

For linux both SendMsgUnix and SendMsg may be used at the same time. I suggest to add cfg unix to SendMsgUnix/RecvMsgUnix and the code which only related to unix.

[loongs-zhang]

Sure, I see the differences between the structures.

[ihciah]

It's a great work, thank you!