Do you have any plan to support Windows ?

[portsip]

Do you have any plan to support Windows ?

[hydratim]

Not at the moment, the network stack doesn't support it (see the answer from @oktal in issue #6) due to architectural decisions.

In theory we could potentially add a compile-time option the replaces the network stack with boost (thus changing from a read-ready to a read-complete model), thus allowing windows support, but it's not likely to happen soon.

The latest Windows 10 will come with a full Linux Kernel in WSL though, so in the mean time you could potentially use that for developing with pistache.

[UndarkAido]

Pistache works great in WSL1 on Windows 10, that's how I've used it.

[seghcder]

The reason I chose Pistache was to avoid the dependency on Boost, and to have a fully native, fast, standalone ReST server. I am also keen to see a Windows native version of Pistache.

I'd be willing to sponsor/donate a few hundred US dollars to support this project and particularly this specific goal. Would anyone else be willing to support?

I've raised a new issue re that topic... #569

Is it reasonably achievable? Or are those architectural decisions too fundamental to Pistache?

[seghcder]

FYI regarding Travis - https://blog.travis-ci.com/2018-10-11-windows-early-release and https://docs.travis-ci.com/user/reference/windows/ (in reference question in #569)

[mheyman]

https://github.com/piscisaureus/wepoll may provide a good if limited option - a scalable drop-in replacement for epoll() on windows. Wepoll doesn't do EPOLLET (edge-triggered) mode and only works with sockets.

[Tachi107]

I would close this and reopen #6, since it contains more information about the subject and was opened first

[Tachi107]

As mentioned in my previous comment, I'm closing this issue in favour of #6. It contains far more information than this one and was opened earlier