Add a Windows 7 build

[mmmray]

Relevant discussions:

• fix compatibility issues with go 1.21 #3455
• 让最新版xray-core支持在Windows7下运行的方法，还在用老系统的可以试试。 #3373

Important point:

仅提供编译，无其它支持

Only compilation is provided, no other support

---

TODO:

• It would be more correct to change the minimum version in go.mod, but I am slightly too afraid of breaking something else. Input from go experts is needed.
• Also, the output binary is untested.
• agree on asset naming

[Fangliding]

looks well. The only question is how we name it.
Xray-Windows-64-compatible
Xray-Windows7-64
Xray-Windows-64-go121
or ...

[yuhan6665]

Thanks! Do we want to re-release..

[mmmray]

• regarding release schedule, rprx has a plan

• it would be good to have at least one user test the binary artifacts. I was not able to get it to run in VM: kernel32.dll not found -- not sure if I did anything wrong.

• it seems for the naming, a telegram poll is needed

[test5uninstall]

• regarding release schedule, rprx has a plan
• it would be good to have at least one user test the binary artifacts. I was not able to get it to run in VM: kernel32.dll not found -- not sure if I did anything wrong.
• it seems for the naming, a telegram poll is needed

Try updating to Service Pack 1 (SP1) and then give it another try?

[test5uninstall]

looks well. The only question is how we name it. Xray-Windows-64-compatible Xray-Windows7-64 Xray-Windows-64-go121 or ...

It is recommended to refer to the Mihomo project for naming release version files.

[test5uninstall]

looks well. The only question is how we name it. Xray-Windows-64-compatible Xray-Windows7-64 Xray-Windows-64-go121 or ...

Xray-windows-go121-64.zip
Xray-windows-go121-32.zip

[RPRX]

It would be more correct to change the minimum version in go.mod, but I am slightly too afraid of breaking something else. Input from go experts is needed.

现在是会把 go.mod 中的 version 改成 go 1.21.4？这样没有问题

Also, the output binary is untested.

@test5uninstall 测一下 https://github.com/XTLS/Xray-core/actions/runs/9914586816

agree on asset naming

Xray-win7-64.zip 和 Xray-win7-32.zip 即可，简单直观，重点是不会下载错，用 Win7 的会下载它们，不用 Win7 的会绕开它们

Xray 的 releases 都是 friendly-filenames，所以会写 macos 而不是 darwin，会写 32 而不是 386，就是追求直观

而 Xray-windows-64-compatible 或 Xray-windows-go121-64 显然都不够 friendly，用 Windows 的看了都迷糊，不知道下哪个

Do we want to re-release..

我们有成熟的给现有 releases 加 assets 技术：#3305 (comment)

[Fangliding]

昨天晚上我也研究了一下 action会自动读取gomod里的版本来安装go 剩下就是把改版本号的操作整合到matrix build里
1.21.4能跑我是没想到的 这样最好 因为改到1.20就刚好会出问题了

[RPRX]

其实还可以找一下有没有 patch 了最新版 Golang 以支持 Win7 的项目，可以用这个 Go 来替代 1.21.4，Meta 好像有 @wwqgtxx

[RPRX]

To GL_OUT_OF_MEMORY：我觉得 Win7 是最后一个“干净”的 Windows，如果可以我都想用，现在的有登录账号什么的用着恶心

To 风扇滑翔翼：可以，这就叫 reproducible

[RPRX]

反正 Windows 一路用过来还是 Vista 的风格最有质感，而且我就是在 Win7 时代开始了大规模编程，写了很多电脑软件，很怀念

[test5uninstall]

It would be more correct to change the minimum version in go.mod, but I am slightly too afraid of breaking something else. Input from go experts is needed.

现在是会把 go.mod 中的 version 改成 go 1.21.4？这样没有问题

Also, the output binary is untested.

@test5uninstall 测一下 https://github.com/XTLS/Xray-core/actions/runs/9914586816

agree on asset naming

Xray-win7-64.zip 和 Xray-win7-32.zip 即可，简单直观，重点是不会下载错，用 Win7 的会下载它们，不用 Win7 的会绕开它们

Xray 的 releases 都是 friendly-filenames，所以会写 macos 而不是 darwin，会写 32 而不是 386，就是追求直观

而 Xray-windows-64-compatible 或 Xray-windows-go121-64 显然都不够 friendly，用 Windows 的看了都迷糊，不知道下哪个

Do we want to re-release..

我们有成熟的给现有 releases 加 assets 技术：#3305 (comment)

测试环境：

命令行测试通过：

v2rayN测试通过：

[Fangliding]

如果可以跑的话差不多可以合了
还有win7有没有必要改成Windows7什么的

[RPRX]

我想知道这个“-dirty”是啥玩意儿

[RPRX]

VERSION=$(shell git describe --always --dirty)

盲猜是改了 go.mod 中的 version 后没 commit 就有了 -dirty，不过 commit 的话 id 会变，特意忽略 -dirty 好像也没必要，就留着吧

[RPRX]

或者我们把 go.mod 中的 version 改回 1.21，就不用 go mod edit 了，应该还可以避免不小心用了新版 Go 特性导致 1.21 编译不了

[RPRX]

我觉得既然我们提供了 Win7 的 builds 就要避免它们编译不出来，即避免使用 Go 1.21 没有的特性，所以应该：

1. 把 go.mod 中的 version 改回 1.21，代表最低支持 Go 1.21 编译，workflow 需 revert f9653d0
2. 删掉 go mod edit 那行，因为可以直接用 Go 1.21.4 编译

@mmmray

[Fangliding]

我记得哪个issue还是pr下面说过我们不可能一直停滞应该向前看还是什么来着

[KobeArthurScofield]

其实 pr 和 commit 的时候都会触发 Actions workflow 运行一遍所以那种时候出毛病应该就能发现吧

[lxhao61]

@mmmray Xray-win7-64 不可用，报错。

[KobeArthurScofield]

@test5uninstall @lxhao61 @dashabiguard 是 Win7 SP1 吗？安装的最新系统补丁是什么时候发布的？
@mmmray Are you on Windows 7 SP1 and Windows Update is up to date?

因为 kernel32.dll 一般只有在系统更新的时候才会更改，而且这个 DLL 真的坏了的话系统是没法用的。

所以能探明能用的条件最好，用 go 1.20 要动的地方还是稍微多了点。
如果是修改过或者精简版系统那么可能有机会出现这种问题，而且系统更新也会变得麻烦。因为说不好微软在后面的更新修复了一下 bug 或者把一些 fix backport 了

[lxhao61]

@KobeArthurScofield 是 win7 SP1，且无更新。

[Fangliding]

Windows7 available build → Windows7 with golang 1.21.4 helpdesk

[KobeArthurScofield]

Windows7 available build → Windows7 with golang 1.21.4 helpdesk

有那种味道了

不过之前 win7 不能用的 issue 都是 1.8.7 (go 1.21.5) 才冒出来的，1.8.6 (go 1.21.4) 和更早的倒是没见着。
按理来说用 go 1.21.4 编译的 1.8.17 跑不起来的机器那么 1.8.6 应该也跑不起来，除非中间有什么改动导致新版本用不了。

[lxhao61]

你们在虚拟机里打上KB4490628补丁再运行试试

问题依旧，还是一样报错。

[vrnobody]

@lxhao61 请试一下以前的 v1.8.4 以及 v1.8.6 这两个版本，看看能不能运行？

差点忘了还有 v1.8.3

[KobeArthurScofield]

话说 go.mod 中的 version 只能写 1.21.4 吗？感觉很不优雅，我试试再改成 1.21

1.21.5 和之后用到了 Win7 没有的 API 必然会炸，所以只能指定使用小版本号。
不过 Go 那边倒是对恢复兼容性的 patch 感兴趣

[test5uninstall]

可以参考一下v2fly那边的go.mod

[test5uninstall]

试试看最新版和1.21.4版能不能都编译成功

module github.com/xtls/xray-core

go 1.21

toolchain go1.21.4

[test5uninstall]

或者执行一下go mod tidy

[mmmray]

It's not correct to specify go 1.21 as this codebase does not actually support 1.21.0 in practice. You can check this locally by running go get go@1.21.0, it will downgrade gvisor. After that, go mod tidy will work, but the build will still fail for other reasons.

The lowest version without major build issues is 1.21.1, but I don't think there is a need to support a golang version even lower than what is used to build Windows 7.

About 1.21.5: My understanding of go.mod always was that it only specifies a lower bound of supported version, specifying a more precise version does not mean "pinning". actions/setup-go did this pinning, but this PR is no longer using the version in go.mod to determine which exact version should be used to compile a binary.

I think the recent changes should just be reverted, then the PR can be merged.

[RPRX]

你们理解错了，不是编译炸了，毕竟以我对 Go 的经验，这样改是可以用 Go 1.21+ 的任意版本编译的，是 test 炸了：

Run go test -timeout 1h -v ./...
  go test -timeout 1h -v ./...
  shell: /usr/bin/bash -e {0}
go: updates to go.mod needed; to update it:
	go mod tidy
Error: Process completed with exit code 1.

就是说需要修改 test.yml 来绕过这个限制 @mmmray

[mmmray]

based on my experience with Go, this change can be compiled with any version of Go 1.21+

Then we are seeing different things. Is my development environment wrong?

On this branch, I get:

$ go mod tidy -go=1.21.0 -compat=1.21.0
go: gvisor.dev/gvisor@v0.0.0-20231202080848-1f7806d17489 requires go@1.21.1, but 1.21.0 is requested

and this:

$ go get go@1.21.0
go: upgraded go 1.21 => 1.21.0
go: added toolchain go1.22.4
go: downgraded gvisor.dev/gvisor v0.0.0-20231202080848-1f7806d17489 => v0.0.0-20230927004350-cbd86285d259

It seems after downgrading gvisor, the compilation will be fine.

I believe that the go mod tidy error in the testsuite is triggered because of gvisor. The version 1.22 probably became stricter about the meaning of go 1.22 in go.mod.

[Fangliding]

win7毕竟已经这么老了 构建里发一个1.21.4的能用的差不多就可以了 个人觉得没必要再改这改那了 这有的人甚至都没有win7物理机还得开虚拟机

[mmmray]

I also have the feeling that go.mod should not be modified at all. I think it will cause contributors to run go 1.21 for their development environment, which is misleading because it cannot pass the testsuite. Instead, a patchset should be maintained specifically for Windows 7, and support for go 1.21 should not be advertised in other contexts. Nevermind, I am unsure about it.

[RPRX]

研究透了，这个与用哪个版本的 Go 编译无关，而是有这个 gvisor 在时 go.mod 中的 version 不能写 1.21，只能写 1.21.1+

如果写 1.21，Go 会要求先 go mod tidy，也就是降级 gvisor 以兼容 1.21.0，然后才允许你编译，即使你编译用且只用 1.21.1+

比如 version 写 1.21 时 builds 全是“-dirty”，就是自动 go mod tidy 了，而 test 的行为则是报错，让你先 go mod tidy

而 version 写 1.21.4 时不需要先 go mod tidy，所以 builds 全不带“dirty”，且 test 也是正常的，所以优雅失败只能写 1.21.4

[mmmray]

Yes! That's what I'm saying! 😆 Golang 1.22 interprets go 1.21 the same as go 1.21.0

So what should be done then? Do you want to downgrade gvisor? I would prefer go 1.21.4

[Fangliding]

这个gvisor当时升上来就费了不少事 降下去也费事

[RPRX]

So what should be done then? Do you want to downgrade gvisor? I would prefer go 1.21.4

“所以优雅失败只能写 1.21.4”

win7毕竟已经这么老了 构建里发一个1.21.4的能用的差不多就可以了 个人觉得没必要再改这改那了 这有的人甚至都没有win7物理机还得开虚拟机

改这改那一是为了追求优雅，二是为了确保“构建里发一个1.21.4的能用的差不多就可以了”

如果不改 version，写 1.22+，会不小心用到 1.21.4 没有的特性，根据新发现的东西，也会导致依赖升级到不支持 1.21.4 的版本

目前先这样吧，但长久之计是 #3530 (comment) ，@test5uninstall 你用几天你的版本的 Xray 看看有没有什么问题

[RPRX]

下载 https://github.com/XTLS/Xray-core/actions/runs/9937317400 上传 https://github.com/XTLS/Xray-core/releases/tag/v1.8.17

[RPRX]

下载 https://github.com/XTLS/Xray-core/actions/runs/9937317400 上传 https://github.com/XTLS/Xray-core/releases/tag/v1.8.17

又删掉了，因为发了 https://github.com/XTLS/Xray-core/releases/tag/v1.8.18

[test5uninstall]

使用修改后的go1.22.5编译Xray，编译过程一切顺利，看起来效果很好，目前看来没有发生任何错误。
在这里放出使用修改后的go编译好的Xray，你们测试下有没有问题。
Xray-go122-windows7-compatible.zip

[simpleandstupid]

我还是很怀疑对win7的兼容能保持多久