Repository navigation
Conversation
CREATE_NO_WINDOW 会让子进程脱离伪控制台：Windows 会给 shell 单独分配一个隐藏的 真实控制台（默认 120x9001），提示符与所有回显都进了那里，ConPTY 输出管道始终保持 静默。pty.write 仍然返回 ok，所以面板不报任何错误——只有一个没有提示符、按键盘毫无 响应的空白 xterm（issue #13）。 在 Windows 11 26200 / PI-Desktop 0.14.8 上，通过助手的 JSON 协议直接驱动验证： 带该标志时 drain() 恒为 0 字节；去掉后 PowerShell 提示符正常返回，输入也能正确回显。 子进程自己执行 mode con：带标志为 120x9001，去掉后为请求的 100x30，证明伪控制台已挂上。 去掉该标志不会重新引入控制台窗口：StartupInfoEx 仍设置 STARTF_USESHOWWINDOW + SW_HIDE， build.sh 仍以 -H windowsgui 构建；spawn 期间以 25ms 轮询 EnumWindows 未出现任何控制台窗口。 同时反转了锁定该标志的测试断言、更正 README、升版本到 0.1.7（重建 win32 x64/arm64 助手二进制）并重建 catalog。
|
Someone is attempting to deploy a commit to the vastsa's projects Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
修复 #13（Windows 下工作面板终端一直空白、无法输入）。
helper/pty_windows.go在同一处CreateProcess调用里同时传了PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE和CREATE_NO_WINDOW。这两个组合在一起会让子进程脱离伪控制台：Windows 给 shell 单独分配了一个隐藏的真实控制台（默认 120x9001），
横幅、提示符和所有回显都写进了那里，ConPTY 的输出管道始终保持静默。
因为
pty.write依旧返回{ok:true}，界面看起来完全正常——没有任何报错，只是一个没有提示符、敲键盘毫无反应的空白 xterm。这也解释了为什么此前从日志里查不出问题。
该标志是
6151af2（"attach Windows PowerShell to in-app ConPTY"）引入的：那次提交正确地把HPCON 改为按值传递，但同一个调用上的
CREATE_NO_WINDOW又把刚修好的 attach 抵消掉了。根因验证
环境：Windows 11 26200 / PI-Desktop 0.14.8。通过助手自身的 JSON 协议直接驱动
vendor里的二进制（完全绕开 renderer、xterm 与
pty.js）：drain()输出mode conCREATE_NO_WINDOW（0.1.6 现状）PS C:\Windows>spawn 之后写入
echo INPUT_OK\r，只有第二种情况能正确回显。A/B 两组代码完全相同，且用随包源码按
build.sh同参数重新编译后复现了同样的问题，说明源码与二进制行为一致，问题确实在源码。
不会重新弹出控制台窗口
去掉该标志并不会把"独立控制台窗口"带回来：
StartupInfoEx仍然设置STARTF_USESHOWWINDOW+SW_HIDE，build.sh也仍然使用-H windowsgui构建。在 spawn 期间以 25ms 间隔轮询
EnumWindows共 6 秒，未出现任何 console 类窗口。改动
helper/pty_windows.go：去掉CREATE_NO_WINDOW，并加注释说明为什么不能加回来tests/terminal.test.mjs：反转断言（原先它要求源码里必须存在该标志），改为要求可执行代码中不得出现（注释仍可提及）；同步被固定的版本号
README.md：更正原文把该标志描述成有意设计的说明manifest.json：0.1.6→0.1.7并补充 changelogvendor/pi-pty-win32-{x64,arm64}.exe：按helper/build.sh同参数重新构建packages/pi.terminal-0.1.7.piplug+catalog.json：重新打包并重建目录，sha256 已核对验证
python3 scripts/security_audit.py --check-packages→ 0 blockernode --test tests/terminal.test.mjs→ 8 passed / 3 failed（未改动的main为 7 passed /4 failed）。新增通过的一项是
real helper can spawn a short command——它在main上失败、打补丁后通过。剩余 3 项在未改动的
main上同样失败，属于 Windows 本机路径/shim差异（CI 运行在 Ubuntu）。
PS C:\Windows>提示符，输入回显正常；main上为 0 字节。说明
0.1.6已经发布过，因此这里新增0.1.7，而不是就地修改已发布的产物（本地一度误覆盖packages/pi.terminal-0.1.6.piplug，已还原，sha256 仍为e915e96f6895a3f3881314e29099ae3c59236e8e93e6f805f4ba6d3f14919c22）。darwin / linux 四个二进制未改动，也不受影响（走
pty_unix.go）。