Hi
On 2026-10-02 22:38, Pratik Bhujel wrote:
I also checked Windows because I did not want to assume the POSIX PTY
mechanism translated there. It does not directly, since proc_open() on
Windows does not provide the same PTY descriptor. I built the current
branch on Windows 11 ARM64 and exercised the native console path
instead.
The PHP side was just:
$t = Io\Terminal\SystemTerminal::fromStdio();
var_dump($t->readKey());
A small harness attached to a real Windows console injected KEY_EVENT
records into CONIN$ with WriteConsoleInputW(). Injecting Up produced:
enum(Io\Terminal\Key::Up)
[…]
straightforward cross-platform testing seam is still relevant for
Windows
code that directly consumes readKey().
I know nothing about Windows, but am seeing that `proc_open()` offers a
`create_new_console` option that is documented as:
create_new_console (windows only): the new process has a new console,
instead of inheriting its parent's console
Is that perhaps already all that is required? Or would a
(Windows-specific) helper `Io\Terminal\inject_fake_keypress()` outside
of the main terminal API be helpful?
On the interface question, Tim's objections to the current
Terminal/ModeToken shape still make sense to me, especially the
ModeToken
case where a userland token can satisfy the interface but cannot
actually
be restored by the native terminal. At the same time, after checking
Windows I don't think I can honestly say that php://memory or stream
injection alone makes the interface unnecessary everywhere. It clearly
solves readLine(), and the PTY gives us a good POSIX integration seam,
but
Windows userland code directly consuming readKey() does not have the
same
pure-PHP PTY seam today.
It sounds to me that “PHP is unable to spawn terminals on Windows” is an
orthogonal concern and a pre-existing limitation of e.g. the
`proc_open()` API. The lack of Windows support must not influence the
design of the `Io\Terminal` API to introduce a “short term” workaround
that will become obsolete as soon as PHP will be able to spawn terminals
on Windows, but that will affect the `Io\Terminal` API in a negative way
for eternity. We should try very hard that every new API we add to the
standard library is well-designed and convenient to use for 15+ years
without introducing breaking changes. Perhaps Ilia’s suggestion of just
allowing a `php://memory` stream is okay, keeps `readKey()` capabilities
in sync with `readLine()` and fills gap until `proc_open()` is extended
for proper end-to-end testing?
Best regards
Tim Düsterhus
