nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f58ddf26fe
putty-source/windows/pterm.c

67 lines
2.1 KiB
C
Raw Normal View History

New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
#include "putty.h"
#include "storage.h"
pterm.exe: run command-line options through cmdline.c. This makes pterm.exe support the same (very small) subset of the standard option collection that Unix pterm does. Namely, -load (which won't do anything useful with a hostname to connect to, but is still useful if you have a saved session containing configuration like colours or default size or what have you), and also -sessionlog. To make this work, I've had to move the 'tooltype' definition out of window.c into {putty,pterm}.c, so that it can be defined differently in the two.
2022-05-21 09:32:32 +00:00
const unsigned cmdline_tooltype =
TOOLTYPE_NONNETWORK |
TOOLTYPE_NO_VERBOSE_OPTION;
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
void gui_term_process_cmdline(Conf *conf, char *cmdline)
{
do_defaults(NULL, conf);
conf_set_str(conf, CONF_remote_cmd, "");
cmdline = handle_restrict_acl_cmdline_prefix(cmdline);
if (handle_special_sessionname_cmdline(cmdline, conf) ||
handle_special_filemapping_cmdline(cmdline, conf))
return;
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
CmdlineArgList *arglist = cmdline_arg_list_from_GetCommandLineW();
size_t arglistpos = 0;
while (arglist->args[arglistpos]) {
CmdlineArg *arg = arglist->args[arglistpos++];
CmdlineArg *nextarg = arglist->args[arglistpos];
const char *argstr = cmdline_arg_to_str(arg);
int retd = cmdline_process_param(arg, nextarg, 1, conf);
pterm.exe: run command-line options through cmdline.c. This makes pterm.exe support the same (very small) subset of the standard option collection that Unix pterm does. Namely, -load (which won't do anything useful with a hostname to connect to, but is still useful if you have a saved session containing configuration like colours or default size or what have you), and also -sessionlog. To make this work, I've had to move the 'tooltype' definition out of window.c into {putty,pterm}.c, so that it can be defined differently in the two.
2022-05-21 09:32:32 +00:00
if (retd == -2) {
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
cmdline_error("option \"%s\" requires an argument", argstr);
pterm.exe: run command-line options through cmdline.c. This makes pterm.exe support the same (very small) subset of the standard option collection that Unix pterm does. Namely, -load (which won't do anything useful with a hostname to connect to, but is still useful if you have a saved session containing configuration like colours or default size or what have you), and also -sessionlog. To make this work, I've had to move the 'tooltype' definition out of window.c into {putty,pterm}.c, so that it can be defined differently in the two.
2022-05-21 09:32:32 +00:00
} else if (retd == 2) {
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
arglistpos++; /* skip next argument */
pterm.exe: run command-line options through cmdline.c. This makes pterm.exe support the same (very small) subset of the standard option collection that Unix pterm does. Namely, -load (which won't do anything useful with a hostname to connect to, but is still useful if you have a saved session containing configuration like colours or default size or what have you), and also -sessionlog. To make this work, I've had to move the 'tooltype' definition out of window.c into {putty,pterm}.c, so that it can be defined differently in the two.
2022-05-21 09:32:32 +00:00
} else if (retd == 1) {
continue; /* nothing further needs doing */
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
} else if (!strcmp(argstr, "-e")) {
if (nextarg) {
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
/* The command to execute is taken to be the unparsed
* version of the whole remainder of the command line. */
Switch CONF_remote_cmd to being STR_AMBI. The immediate usefulness of this is in pterm.exe: when the user uses -e to specify a command to run in the pterm, we retrieve the command in Unicode, store it in CONF_remote_cmd as UTF-8, and then in conpty.c we can extract it in the same form and convert it back to Unicode to pass losslessly to CreateProcessW. So now non-ACP Unicode works in that part of the pterm command line.
2024-09-26 09:50:47 +00:00
char *cmd = cmdline_arg_remainder_utf8(nextarg);
conf_set_utf8(conf, CONF_remote_cmd, cmd);
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
sfree(cmd);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
return;
} else {
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
cmdline_error("option \"%s\" requires an argument", argstr);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
}
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
} else if (argstr[0] == '-') {
cmdline_error("unrecognised option \"%s\"", argstr);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
} else {
New abstraction for command-line arguments. This begins the process of enabling our Windows applications to handle Unicode characters on their command lines which don't fit in the system code page. Instead of passing plain strings to cmdline_process_param, we now pass a partially opaque and platform-specific thing called a CmdlineArg. This has a method that extracts the argument word as a default-encoded string, and another one that tries to extract it as UTF-8 (though it may fail if the UTF-8 isn't available). On Windows, the command line is now constructed by calling split_into_argv_w on the Unicode command line returned by GetCommandLineW(), and the UTF-8 method returns text converted directly from that wide-character form, not going via the system code page. So it _can_ include UTF-8 characters that wouldn't have round-tripped via CP_ACP. This commit introduces the abstraction and switches over the cross-platform and Windows argv-handling code to use it, with minimal functional change. Nothing yet tries to call cmdline_arg_get_utf8(). I say 'cross-platform and Windows' because on the Unix side there's still a lot of use of plain old argv which I haven't converted. That would be a much larger project, and isn't currently needed: the _current_ aim of this abstraction is to get the right things to happen relating to Unicode on Windows, so for code that doesn't run on Windows anyway, it's not adding value. (Also there's a tension with GTK, which wants to talk to standard argv and extract arguments _it_ knows about, so at the very least we'd have to let it munge argv before importing it into this new system.)
2024-09-25 09:18:38 +00:00
cmdline_error("unexpected non-option argument \"%s\"", argstr);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
}
}
New config option for shifted arrow key handling. This commit introduces a new config option for how to handle shifted arrow keys. In the default mode (SHARROW_APPLICATION), we do what we've always done: Ctrl flips the arrow keys between sending their most usual escape sequences (ESC [ A ... ESC [ D) and sending the 'application cursor keys' sequences (ESC O A ... ESC O D). Whichever of those modes is currently configured, Ctrl+arrow sends the other one. In the new mode (SHARROW_BITMAP), application cursor key mode is unaffected by any shift keys, but the default sequences acquire two numeric arguments. The first argument is 1 (reflecting the fact that a shifted arrow key still notionally moves just 1 character cell); the second is the bitmap (1 for Shift) + (2 for Alt) + (4 for Ctrl), offset by 1. (Except that if _none_ of those modifiers is pressed, both numeric arguments are simply omitted.) The new bitmap mode is what current xterm generates, and also what Windows ConPTY seems to expect. If you start an ordinary Command Prompt and launch into WSL, those are the sequences it will generate for shifted arrow keys; conversely, if you run a Command Prompt within a ConPTY, then these sequences for Ctrl+arrow will have the effect you expect in cmd.exe command-line editing (going backward or forward a word). For that reason, I enable this mode unconditionally when launching Windows pterm.
2021-10-18 19:00:25 +00:00
pterm.exe: run command-line options through cmdline.c. This makes pterm.exe support the same (very small) subset of the standard option collection that Unix pterm does. Namely, -load (which won't do anything useful with a hostname to connect to, but is still useful if you have a saved session containing configuration like colours or default size or what have you), and also -sessionlog. To make this work, I've had to move the 'tooltype' definition out of window.c into {putty,pterm}.c, so that it can be defined differently in the two.
2022-05-21 09:32:32 +00:00
cmdline_run_saved(conf);
New config option for shifted arrow key handling. This commit introduces a new config option for how to handle shifted arrow keys. In the default mode (SHARROW_APPLICATION), we do what we've always done: Ctrl flips the arrow keys between sending their most usual escape sequences (ESC [ A ... ESC [ D) and sending the 'application cursor keys' sequences (ESC O A ... ESC O D). Whichever of those modes is currently configured, Ctrl+arrow sends the other one. In the new mode (SHARROW_BITMAP), application cursor key mode is unaffected by any shift keys, but the default sequences acquire two numeric arguments. The first argument is 1 (reflecting the fact that a shifted arrow key still notionally moves just 1 character cell); the second is the bitmap (1 for Shift) + (2 for Alt) + (4 for Ctrl), offset by 1. (Except that if _none_ of those modifiers is pressed, both numeric arguments are simply omitted.) The new bitmap mode is what current xterm generates, and also what Windows ConPTY seems to expect. If you start an ordinary Command Prompt and launch into WSL, those are the sequences it will generate for shifted arrow keys; conversely, if you run a Command Prompt within a ConPTY, then these sequences for Ctrl+arrow will have the effect you expect in cmd.exe command-line editing (going backward or forward a word). For that reason, I enable this mode unconditionally when launching Windows pterm.
2021-10-18 19:00:25 +00:00
conf_set_int(conf, CONF_sharrow_type, SHARROW_BITMAP);
New application: a Windows version of 'pterm'! This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
2021-05-08 16:24:13 +00:00
}
const struct BackendVtable *backend_vt_from_conf(Conf *conf)
{
return &conpty_backend;
}
const wchar_t *get_app_user_model_id(void)
{
return L"SimonTatham.Pterm";
}
Windows tools: assorted '-demo' options. Using a new screenshot-taking module I just added in windows/utils, these new options allow me to start up one of the tools with demonstration window contents and automatically save a .BMP screenshot to disk. This will allow me to keep essentially the same set of demo images and update them easily to keep pace with the current appearance of the real tools as PuTTY - and Windows itself - both evolve.
2022-04-02 15:18:08 +00:00
void gui_terminal_ready(HWND hwnd, Seat *seat, Backend *backend)
{
}
Reference in New Issue Copy Permalink