is there a specific change that you're proposing that could make it work?

cc @golang/windows

is there a specific change that you're proposing that could make it work?

cc @golang/windows

Yes, I just submitted #62710 to fix this issue

Change https://go.dev/cl/529315 mentions this issue: syscall: add SysProcAttr.PseudoConsole on Windows

This proposal doesn't contain the necessary API changes to support ConPty. For what I can see in the associated CL 529315, it would only need this addition into syscall.SysProcAttr :

type SysProcAttr struct {
        ...
	PseudoConsole              Handle              // if non-zero, the new process will be attached to the console represented by this handle, any AdditionalInheritedHandles will be ignored, this implies NoInheritHandles
}

Reading the docs and peeking at some code samples out there, adding this new property seems like enough to creating pseudoconsole sessions. What I can't find is documentation about why it precludes inheriting additional handles. Could you help me understanding that?

This proposal doesn't contain the necessary API changes to support ConPty. For what I can see in the associated CL 529315, it would only need this addition into syscall.SysProcAttr :

That's correct. This is where CL 528915 comes in place to add ConPty API to sys/windows. We need CL 529315 to support running processes on a ConPty.

Reading the docs and peeking at some code samples out there, adding this new property seems like enough to creating pseudoconsole sessions. What I can't find is documentation about why it precludes inheriting additional handles. Could you help me understanding that?

I couldn't find any info in the docs. All I found is this comment from hcsshim "If the client requested a pseudo console then there's nothing we need to do pipe wise, as the process inherits the other end of the pty's pipes."

EDIT: add node-pty and microsoft/node-pty#334 for reference

EDIT: add node-pty and microsoft/node-pty#334 for reference

Thanks for the sources. What I understood is that ConPty has a bug that makes it misbehave when inheriting handles. As it makes no sense to do that anyway, then handle inheriting is disabled. Looks fuzzy, but convinced me.

Any updates on this one? #62710 CR 529315 only needs one addition to syscall.SysProcAttr to make spawning processes on a ConPty possible

type SysProcAttr struct {
        ...
	PseudoConsole              Handle              // if non-zero, the new process will be attached to the console represented by this handle, any AdditionalInheritedHandles will be ignored, this implies NoInheritHandles
}

CC/ @bcmills @thanm @qmuntal

Any updates on this one?

It still needs to complete the proposal process and get accepted. The next step is that this proposal is discussed by the proposals team, but it can take a while as the proposals queue is big.