添加 Windows 平台支持

[slince]

虽然比较难实现，或者觉得没意义毕竟服务器都是linux；

但现实是使用 windows 开发者基数比较庞大，所以除非是因为客观业务需求，window平台的开发者 是不会主动去探索swoole。也因为window开发者的不接触，在项目方案选择上主动选择swoole的 概率自然也会比较低。

为了更好的推广swoole，window不支持的天然屏障肯定是需要解决的；就像nodejs如果不支持window的话我想是不会由这么快的被推广开来。swoole依赖的一些linux上的东西可以适当的像nodejs的libuv一样做一个抽象层屏蔽下。

[slince]

开发周期过长的话， swoole可以给个官方的使用docker解决开发问题的方案，在doc页给篇文章标注下，从docker安装到 swoole 示例代码运行。是的就是小白文章，因为依赖windows的开发者求知欲和探索欲是要弱于使用linux的开发者的。

[huangzhhui]

用 Win for Docker 或者 wsl 就好了吧，提供文档引导一下？

[slince]

@huangzhhui 不是长久之计，没解决根本问题，过渡期可以

[matyhtf]

可使用 Cygwin 或者 WSL，或者使用 VirtualBox 安装 Linux 虚拟机

[slince]

@matyhtf 不管是虚拟机还是docker都是需要额外的学习成本的，对于小白用户（姑且认为window用户是小白用户）来说最怕的就是额外的学习负担，所以最好的解决方案就是别给他额外的负担。

得小白者得天下，得windows者得天下。

[twose]

项目尊重普众用户是一环, 但是这不是用户不肯学习的理由, 虚拟机/容器的搭建都是很基础的, 学习成本并不高, Linux的东西是肯定要学的, 不能抱着win不放. 再者就是权衡一下维护和开发的难度和win兼容的价值, 很容易就能得出目前很难对win提供有效支持的结论, 不如多花精力在Linux(或OSX)的维护完善上. 最后就是Swoole本来就是偏向高级开发/企业级开发或者geek, 我相信企业主流还是使用linux系统的, 不可能用windows. 个人意见, 以前也在要求win支持的issue下留言过...现在不再那么想了, 希望每个学习swoole的同学都有进取心, 有大佬能贡献一下win兼容就更好了(太难

[slince]

@twose 生产环境肯定没有问题；问题在吸引开发者上，除非有必选swoole的理由，一般人很难在只听过swoole的情况下去选择它

我相信企业主流还是使用linux系统的, 不可能用windows.

前半句没有问题，但实际上windows server的部署量远大于linux

Swoole本来就是偏向高级开发/企业级开发或者geek

这句话更不对了，真正的geek或者大企业会直接转向go；说实话 swoole 就是给开发实力比较差的初创及中小企业用的，ps 现在杭州等一些大城市初创公司起步就是go

项目尊重普众用户是一环, 但是这不是用户不肯学习的理由, 虚拟机/容器的搭建都是很基础的, 学习成本并不高, Linux的东西是肯定要学的, 不能抱着win不放.

这个是在用户想用并且没有其它更好的选择的情况下做的事情；但现在 swoole 和普通 phper 之间的关联非常的微弱，甚至不及 nodejs

[slince]

看到一个项目，感觉和swoole有重合 https://github.com/spiral/roadrunner

[twose]

@slince 这个和swoole不是一个类型的东西, 只是替换掉了fpm而已(负载均衡和进程管理), PSR7也是一个特色. Swoole目前核心还是在于异步协程能力.

[slince]

@twose 并发处理模型不一样，应用场景一样；都是给php赋予常驻内存的能力。

[PeratX]

Windows 10 + Windows Subsystem for Linux 目前就是使用这套进行开发，生产环境采用Ubuntu Server基本可以无缝对接。 也可以方便的在IDE内启动（调试好像也可以）。

[matyhtf]

WSL2 已经实现100% 兼容 Linux 了，不再有 win32 兼容计划。

[slince]

一直在关注swoole，没用过公司也没计划用，说一点东西，不是想喷，表达下观念；

win的支持问题

这是个原则问题；有就是有，没有就是没有；不是因为wsl兼容linux所以swoole就不在需要原生支持；如果以这个理推论php-src也不需要在写win32兼容代码，不只是php，其它所有语言都可以不再支持win32；

不会有谁在win server上装个wsl，缺失Win32的原生支持，再发展几年都是一样；不完整，缺点什么；一个不完整的东西就是比别人矮一头，就像现在的PCNTL扩展，大多数人看来就是个“玩具”；

swoole的定位

swoole的关注度确实比以前高不少，但 ng+swoole的组合替代不了ng+fpm，swoole很出色，不是学习成本高，是swoole的畸形的机制问题，

php是天生同步的语言，swoole非要改变这一特性，打破了所有io的向下兼容，再造各种客户端，这种程度的改变不亚于发明一种新语言；

以现在php开发组成员的谨慎，swoole不可能会被加入到core ext；如果swoole加进去了，那pdo，phpredis，各种stream的原生代码可能都要重写了，

也许swoole脱离php，改名叫swoole语言，可能推广的会更顺利。

官方费劲心思去对原生io函数兼容，有没有想过丢弃php长久以来的财富”积累“造成这种不兼容本来路就走偏了呢，php解决c10k需要的可能只是更加高级和完整的“pcntl”+“pthread”，php和协程合不来；别再把phper搞的怀疑人生了。

[matyhtf]

感谢你的关注。关于你的提到的内容，这里做一些回复。

1 兼容性问题

现在 Swoole 4.3 和 4.4 版本开始已经提供了全新的 Hook 机制。可以将 PHP 原生的同步阻塞式 stream、pdo、mysqli、redis、curl、sleep、proc_open、gethostbyname 等函数或类一键转换为协程模式。

具体请参考 https://wiki.swoole.com/wiki/page/p-runtime.html

2 WSL 问题

现在 wsl 是随着 win 内核一起更新的。会成为基础设施，所以不需要担心安装性问题。实际上有一些用户目前还在使用 cygwin 兼容来跑 swoole 程序。WSL 会成为新的更好的方案。

3 Linux Only

实际上 Swoole 现在就是 Linux Only 的，包括 FreeBSD、MacOS、Cygwin 等等只是能运行。这个反而会使 Swoole 的特色，这样可以大量使用 Linux Only 的特性。如 signalfd

反而其他语言为了兼容各种平台，对 Linux 系统提供的专有特性使用并不是非常多。

兼容多个平台，需要花费 N 倍的研发资源。其实对对于用户来说，意义并不大。对于 Swoole 项目组来说，实在没有那么多资源去做这些事情，不如舍弃，选择更专注于 Linux 这一个平台。做一个小而美的库，而不是大而全。

4 协程的问题

你的判断恐怕是错的，协程的模式是最适合 PHP 的，我们做 Swoole 开源项目长达 7年，协程成为最终的方案，是我们长期思考的结果。

而且有大量实际项目中已经使用了 Swoole 协程，未来也会也来越多。

当然即使 Swoole 做的再好，也不可能赢得所有用户。最重要的是服务好选择了 Swoole 的用户。

[manaphp]

其实SWOOLE的协程功能非常强大，

如果是写WEB可以考虑使用ManaPHP,支持FPM下开发，协程下运行，没有那么高的学习和开发成本。

https://github.com/manaphp/manaphp

[Yurunsoft]

支持win原生能更方便推广，也能方便使用.net的一些公司，尝试使用swoole。 得小白者得天下是肯定的，但是这样会导致开发和维护成本上升。 目前，安装wsl之后用swoole也没什么大问题了。不过安装wsl这一步，可能会让小白望而生畏。（比如奇怪的应用商店错误代码） 我的结论：可以兼容win原生，但没必要

[manaphp]

不用考虑windows版的性能，只需要能用而已，

[monkeykingGWX]

个人觉得支持windows有一定意义，但如果需要投入大量精力的话，那就没必要了。 真的，小白还是挺多了，之前一家公司，开发人用的服务器全都是windows的，而且，他们工作经验最少的也有2年了。

[manaphp]

个人觉得支持windows有一定意义，但如果需要投入大量精力的话，那就没必要了。 真的，小白还是挺多了，之前一家公司，开发人用的服务器全都是windows的，而且，他们工作经验最少的也有2年了。

我工作十多年了，哪怕以前是做嵌入式开发，也是WINDOWS平台，没毛病，WINDOWS上的软件太好用了。离不开。。。

LINUX只是一个运行环境而已

对于ManaPHP来说, Swoole也只是一个运行环境而已， Swoole相关逻辑不超过100行代码，但可以同时支持Swoole协程与FPM

[JaguarJack]

wsl2 的到来会解决这一切。开发组没必要再在这上面折腾了，支持 Linux Only

[twose]

@slince

Win

Win的问题很简单, 专注确实是开发组第一要务, 我们现在没有那么多资源, 用好几倍的精力去满足不到好几倍的需求, 得不偿失

多线程

PHP写的pthread大佬都去搞parallel了, 而且多线程并不能拯救PHP的性能, 多线程的开发绝对比协程复杂一百倍

生态复用

自造客户端已经是老路子了, 现在Swoole完全复用了PHP的生态, 可以将PHP原有的库协程化, 甚至使用PHP代码去开发内核而不是C代码

Swoole近期的进步非常大, 因为你们没有用, 所以你们不知道, 早期用Swoole的先吃螃蟹的用户已经尝到了甜头, 从2.0协程刚刚推出到现在4.3.5协程的进步非比寻常, 不论是稳定性还是生态完整度都不可同日而语, 你还在用从前的眼光看待

合并

合进php-src对Swoole来说意义并不大, Swoole内核现在仍处于高速迭代期, 而开发需要稳定和效率, 所以选择了C++甚至PHP本身来写内核, 现阶段要考虑合进php-src反而对Swoole没有好处

PHP官方也和我们有一些邮件交流, 他们对协程特性的兴趣也是很大的, 包括在PHP内核中做出一些修改来兼容我们的协程特性(如文件操作协程化), 我也在开发Swoole过程中遇到了很多PHP内核的问题并pr修复.

PHP和Swoole是相辅相成的, Swoole其实包含了libswoole和php_swoole, libswoole是C层面的协程网络库, 也就是说Swoole是可以给任何用C实现的语言赋能的, 但对于有一定水平的开发者来说, 在PHP这样的语言上使用协程是最爽的

[PeratX]

针对特定平台优化往往能获得最佳效能且成本可控 再说了WSL确实已经可以在大部分情况下胜任测试工作 当前资源有限的情况下，却务必要专门开发Windows方面的支持

[mabu233]

Swoole主要开发者就那三个，想要支持Windows也没那个精力啊

[LuffyQAQ]

swoole对于一些小白来说，确实linux不是太好的选择，但是对于我们现在软件更新迭代这么快来讲，我觉得自主学习是必备的能力

[hanhyu]

linux是物联网的基石，连他说的win都开始放出wsl2了，

做为一个开发者，还不与时俱进，还在一个劲地只用win不用其他的开发，只能被淘汰，

说更实在点现在php开发找工作不会点linux、js、甚至go、python等能面试上吗？

再说实在点，只会用win开发的php，不可能会玩swoole，就是现在弄个win版的swoole，他们也不会运行起来，更别说上生产环境了，到处坑到你怀疑人生？

[xavieryang007]

有精力的前提下，支持WIN也是不错的。当然Linux支持必须是首位的。

[thinker-gao]

支持win原生能更方便推广，也能方便使用.net的一些公司，尝试使用swoole。 得小白者得天下是肯定的，但是这样会导致开发和维护成本上升。 目前，安装wsl之后用swoole也没什么大问题了。不过安装wsl这一步，可能会让小白望而生畏。（比如奇怪的应用商店错误代码） 我的结论：可以兼容win原生，但没必要

swoole面向的用户不是小白 ，你可以看文档

[Yurunsoft]

支持win原生能更方便推广，也能方便使用.net的一些公司，尝试使用swoole。 得小白者得天下是肯定的，但是这样会导致开发和维护成本上升。 目前，安装wsl之后用swoole也没什么大问题了。不过安装wsl这一步，可能会让小白望而生畏。（比如奇怪的应用商店错误代码） 我的结论：可以兼容win原生，但没必要

swoole面向的用户不是小白 ，你可以看文档

说是这么说，但是你要火起来，还得靠小白

[slince]

@matyhtf

可以将 PHP 原生的同步阻塞式 stream、pdo、mysqli、redis、curl、sleep、proc_open、gethostbyname 等函数或类一键转换为协程模式

我也在上述的评论中的 “费劲心思对原生做兼容”就是已经提到，官方做兼容结果是好的，但swoole去兼容io api这个行为本身就出了问题，这本是不需要做的事；一个扩展改变了整个语言的行为，这说明swoole设计的就是不健康的，swoole要做的不是改变phper的习惯，不是改变php本身。

其次一键转换说白了单纯地让api用法上兼容协程，对原生的php-src肯定是有hack的；我们都知道php官方一直都很谨慎哪怕有一点点打破向下兼容的代码都要考虑再三；swoole这种程度的hack很难被开发组认可；

现在 wsl 是随着 win 内核一起更新的。会成为基础设施

wsl应该只有win10有吧，window server 这种服务器操作系统要不要考虑呢

你的判断恐怕是错的，协程的模式是最适合 PHP 的，

协程的效率确实很高，但效率并不是考量的唯一的点，我在上个回复中也提到，php是通步语言，和java一样的同步语言，java处理高并发的机制是经过成千上万的项目考验过的，

多进程多线程如引进来是对现有php生态和社区做补充；swoole是却打破了BC, packagist上80%的包都是没法直接用的，这种和整个 php 社区做对抗的行为很难让人苟同认为协程是最合适的。

到底协程与线程/进程那个才是最合适的呢。是协程能解决的问题线程解决不了吗。

@twose

PHP写的pthread大佬都去搞parallel了, 而且多线程并不能拯救PHP的性能, 多线程的开发绝对比协程复杂一百倍

我并不是指望pthread拯救php，事实上我根本瞧不上现有的pcntl和pthread，各种不兼容很难站得住脚；我说的是期待一个更加完整的“pcntl”和“pthread”，至于学习复杂度，那不是问题

合进php-src对Swoole来说意义并不大

swoole不以进入phpsrc为目标确实是我没想到的。但你说的理由短期内我是理解的，swoole已经出现了7年还在高速发展期，那你们的节奏是不是出了问题，这里打个问号。

至于其他说linux学习能力的

看清回复：“支不支持这是原则问题，和学习能力无关，和wsl无关，只和win系统还有没有人用有关”

[twose]

Swoole一直都是Linux only的，从没宣称支持Win Swoole扩展是PHP多样化生态的一部分，目的不是取代PHP 协程发展的时间才一年多，前几年走的都是异步的路子 我们的目标是尽可能地兼容原有生态，尽可能地一致，设计良好的代码库都可以复用(没有滥用全局变量的) PHP现在是通用型脚本语言，希望你可以理解它的含义，PHP不只是fpm，那是以前，Swoole改变PHP语言的行为这种说法，是不成立的，分清楚什么是语言，什么是标准库，什么是运行模式 所有语言都有协程的实现，都会一定程度上不兼容原有的库 你质疑的精神我不反对，但是说这么多，你认为什么是对的，Swoole开发组应该做什么你才觉得是正道，你又可以为PHP社区做出什么贡献呢？

[iiQi]

@slince

swoole要做的不是改变phper的习惯

只要你使用了 swoole，那你就必须要改变一些原有的习惯，哪怕不使用 swoole 的协程，也不使用异步

[slince]

@twose

你质疑的精神我不反对，但是说这么多，你认为什么是对的，Swoole开发组应该做什么你才觉得是正道

我上述回复中已经很明显了，多进程/多线程才是最稳妥，最有可能进入phpsrc，最能和php生态兼容的处理机制；强求协程，撼动php几十年来的设计基础也不是你说的对php的补充吧。

你又可以为PHP社区做出什么贡献呢？

你是c开发者，我是php开发者；我们都用各自的语言为php社区贡献。

[slince]

swoole的出现确实打破了大众对php解决c10k问题困难的认知，这一点也让不少phper高潮，我希望韩大和开发组的小伙伴不要被这些无意义的高潮蒙蔽，能和开发组接触的都是swoole的粉丝，他们的看法很明显都是片面单一的，希望韩大可以审视下，swoole做的事情是不是真的能帮助php，而不是让一群人在自嗨；

太激进的项目终究没有好结果，前有Facebook的hhvm

[matyhtf]

@slince 你的想法有一些狭隘，实际上我们与 PHP 语言开发组有深入的交流和合作。不见得我们做就是不专业的，PHP 官方做就是专业的。而是谁在技术上研究更深入、时间更久谁就更专业。

长期来看 PHP 官方会更专注于 语言 VM 本身。而 Swoole 是专注于 异步IO、网络通信、并发。这样才是一个真正的双赢局面。毕竟每个人每个组织都有自己擅长的方向和领域。

请勿带着偏见评论。我们非常欢迎提出有深度的意见和建议。但不接受无意义的争论。

Swoole 有自己的独特定位、专注的方向。