Other connected clients will now print:
```
Connected to an existing tunnel process running on this machine. You can press:
- Ctrl+C to detach
- "x" to stop the tunnel and exit
- "r" to restart the tunnel
```
These are then sent to the server to have that take effect. This is
mostly some refactors in the singleton_server to make the lifecycle work.
Fixes#167708 by using a more predictable naming scheme.
```
me> Write a haiku about the extinction of birds
chatgpt>
Silent skies above,
Once lively songs now gone,
Fading memories.
```
Fixes#167741
This eschews the offical Windows service system in favor of registering
into `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run`.
Unlike services, this can be done without administrative permissions,
does not require the current username/password, and is not blocked by
miscellaneous and mysterious system policies.
Since the process is basically unmanaged by the OS, this requires a
little legwork to start and stop the process when registering and
unregistering.
Adds an stdin/out json rpc server for wsl.
Exposes a singular install_local command to install+boot the vscode server on a port from a local archive.
Also refines the common rpc layer some more. I'm decently happy with it now.
I want to use the rpc interface for communication via stdin/out in wsl,
but currently RPC is tightly coupled to the control server. The control
server also speaks msgpack instead of JSON, since it deals with binary
messages. WSL won't, and we'll want to use JSON to interact with VS
Code, so some separation is needed.
This pulls out a base set of RPC types for use in both scenarios.
Currently these are only 'helper' structs that don't actually do any
i/o, but once I figure out the model I would like to have a cleaner way
to do i/o in a unified way as well.
For the control server, previously we basically handled all methods in
one big `switch` block with nasty macros, whereas now there's
nicer `register_a/sync` functions.
Some additional small refactors were needed to preserve the strict
ordering of server messages, since they need to be order else we get
decompression errors. This is the `start_bridge_write_loop`. As a small
benefit, this means we can avoid the relatively expensive async Tokio
mutex that we were using, and instead use the standard library mutex.
Fixes https://github.com/microsoft/vscode/issues/167760
The VS Code CLI gets run from a bash/shell script. This prevents interactions--in the former case, it doesn't look like a tty, and in the latter case batch scripts don't seem to support having interactive subprocesses.
This PR avoids interactions if stdin is not a tty, prompting the user to use the flag instead. Use of the flag is also persisted like an interactive agreement prompt.
This uses a hash of the tunnel ID to create the connection token, which
should be sufficient to resolve the issues.
We also now publish the protocol version in the tunnel tags, since the
connection token must be supplied in the resolver, which is before we
start connecting to the tunnel.
See https://github.com/microsoft/vscode-internalbacklog/issues/3287
