Have you tried compiling tokio before? Can it run in XP about xp-compatiblerust

[deadash]

I tried tokio, need to patch the following API

GetQueuedCompletionStatusEx
SetFileCompletionNotificationModes
GetFinalPathNameByHandleW
NtCancelIoFileEx

After the patching is completed, the program can run successfully, but there will be an error, 10022 socket error. I don’t have the energy to investigate the cause for the time being. Other tokio non-networks may be able to take effect. If you have the smallest demo, you can send it to me. See if you can run

The projects I tried before used synchronous codes such as reqwest and ureq, and asynchronous ones were not used (including service startup, etc.). In theory, most rust programs can run, and if there are problems, they can be repaired.

I used the following example to test

use tokio::io::{AsyncWriteExt, AsyncReadExt};
use tokio::net::TcpStream;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut stream = TcpStream::connect("icanhazip.com:80").await?;

    let request = "GET / HTTP/1.1\r\nHost: icanhazip.com\r\nConnection: close\r\n\r\n";
    stream.write_all(request.as_bytes()).await?;

    let mut response = Vec::new();
    stream.read_to_end(&mut response).await?;

    println!("{}", String::from_utf8_lossy(&response));

    Ok(())
}

[zhuxiujia]

I tried tokio, need to patch the following API

GetQueuedCompletionStatusEx
SetFileCompletionNotificationModes
GetFinalPathNameByHandleW
NtCancelIoFileEx

After the patching is completed, the program can run successfully, but there will be an error, 10022 socket error. I don’t have the energy to investigate the cause for the time being. Other tokio non-networks may be able to take effect. If you have the smallest demo, you can send it to me. See if you can run

The projects I tried before used synchronous codes such as reqwest and ureq, and asynchronous ones were not used (including service startup, etc.). In theory, most rust programs can run, and if there are problems, they can be repaired.

I used the following example to test

use tokio::io::{AsyncWriteExt, AsyncReadExt};
use tokio::net::TcpStream;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut stream = TcpStream::connect("icanhazip.com:80").await?;

    let request = "GET / HTTP/1.1\r\nHost: icanhazip.com\r\nConnection: close\r\n\r\n";
    stream.write_all(request.as_bytes()).await?;

    let mut response = Vec::new();
    stream.read_to_end(&mut response).await?;

    println!("{}", String::from_utf8_lossy(&response));

    Ok(())
}

Thank you very much.

[deadash]

@zhuxiujia

After some effort, I've figured out a few things. Tokio and Reqwest rely on Mio for networking, and Mio uses wepoll on Windows. The reason wepoll does not support XP can be seen in the following issue:

piscisaureus/wepoll#15.

During debugging, I encountered some issues caused by the following APIs:

WSASocketW sets the flag WSA_FLAG_NO_HANDLE_INHERIT, which I removed to continue using it.

WSAIoctl calls SIO_BASE_SOCKET, which I cannot adapt for compatibility. I think this part can be modified similar to the uv_poll library in Mio to achieve XP compatibility.

The specific code can be seen in .cargo\registry\src\index.crates.io-6f17d22bba15001f\mio-0.8.11\src\sys\windows\selector.rs.

So, if you want to use Mio or Reqwest, you must modify the above to work properly.