jart
use ConPTY to support pty for windows (at least in latest 10/11)?
it is useful for create cross-platform remote shell service (not for evil usage) there is the win api prototype
// Creates a "Pseudo Console" (ConPTY).
HRESULT WINAPI CreatePseudoConsole(
_In_ COORD size, // ConPty Dimensions
_In_ HANDLE hInput, // ConPty Input
_In_ HANDLE hOutput, // ConPty Output
_In_ DWORD dwFlags, // ConPty Flags
_Out_ HPCON* phPC); // ConPty Reference
// Resizes the given ConPTY to the specified size, in characters.
HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size);
// Closes the ConPTY and all associated handles. Client applications attached
// to the ConPTY will also terminated.
VOID WINAPI ClosePseudoConsole(_In_ HPCON hPC);
ref https://learn.microsoft.com/en-us/windows/console/pseudoconsoles https://learn.microsoft.com/en-us/windows/console/creating-a-pseudoconsole-session
I don't know what pty support has to do with tmux. The APIs you mentioned are going to help programs like examples/script.c work on Windows. What's tmux? Is that a cmd.exe alternative? I recommend using Windows Terminal Preview from the Microsoft Store or the old fashioned cmd.exe. Contributions welcome on supporting other terminals.
I don't know what pty support has to do with tmux. The APIs you mentioned are going to help programs like
examples/script.cwork on Windows. What's tmux? Is that a cmd.exe alternative? I recommend using Windows Terminal Preview from the Microsoft Store or the old fashioned cmd.exe. Contributions welcome on supporting other terminals.
it is provided in cosmos... https://cosmo.zip/pub/cosmos/bin/tmux tmux could be used as terminal multiplexer, the thing is it can be run in background, user can "connect" it later to view the result It is particularly advantageous when used for remote access. Considering that you want run some one-time commands in a remote server, but need to run for a long time, and you need to come back to check the results at any time, you definitely do not want to maintain the ssh connection for a long time.
it seems another blocker is the unix socket, but I think it is also provided in latest windows version
Ah yes, I understand now. Yes, there's a strong chance program like tmux and screen will work on Windows if we polyfill syscalls like posix_openpt() using the WIN32 APIs you suggested. It's going to be a bit invasive and painful to do though. CreatePseudoConsole requires that we create five separate WIN32 handles, whereas the POSIX API only makes two file descriptors. We'd likely need a pointer in struct Fd that points to a reference-counted object that holds phPC. We'd need to define a new file descriptor "kind" for PTYs.
I've added the WIN32 APIs themselves so far. As much as I'd love to have GNU Screen on Windows, I don't have the cycles to complete this right now. Contributions are welcome if anyone has an itch to scratch, and is willing to collaborate closely on Discord while they work on this.
