Proxy32 is "Native" XP/Vista/7 Desktop and Terminal environment for CYGWIN.
It comes with 6 built-in Workspaces and Workspace management functionality (switch between workspaces, rename workspace, create terminal window in the workspace, move terminal window from one workspace to another etc).
It comes with Mouse-Driven GUI LauncherTree. LauncherTree allows user to build all launchers (aka shortcuts to start terminals, scripts and applications) into one big GUI tree. This LauncherTree is somewhat similar to the Favorites/Bookmarks Tree in major browsers, except that it "bookmarks" not only web-page url's but several different actions (creating terminals, executing commands and scripts into terminals, starting Windows applications). Tree is editable by GUI means (Launcher Editor dialogs and Drag-and-drop). It is saved/loaded/exported/imported in XML format. XML format allows bulk edits and easy transfer of user-created LauncherTree to another user.
It comes with built-in terminal that has several powerful features that are not common yet in other popular terminals (unlimited scroll back buffer with PERL REGEX search, line bookmarking, unlimited "copy" and 1MB "paste" buffers, terminal session sharing over TELNET/TLS and/or COM-PORT, control of terminal via PLUGINs written in ANY language, etc).
It comes with built-in pre-configured CYGWIN installation (that can be modified at any time by official CYGWIN installer). This is in case user does not have CYGWIN installed yet.
Terminal (and Desktop) requires some type of access to Windows GUI Drawing functions just to draw itself on Windows Monitor. There are two ways to draw GUI/Window in CYGWIN software:
"Native", when program directly access Windows GUI Drawing functions. That means it is not ported from LINUX but written from scratch for Windows only.
Software ported from LINUX/UNIX uses "X-Window" drawing protocol, when one CYGWIN program (like XTerm terminal) sends generic "X-Window" drawing requests over TCP/IP link to another CYGWIN program (X-Window Server) that "translates" those "X-Window" drawing requests into requests to Windows GUI Drawing functions and then passes those requests to Windows for execution. Use of "X-Window" server on Windows is similar to the use of CYGWIN1.DLL in a sense that it translates from UNIX-style drawing language into Windows-style drawing language. There is some overhead in using TCP/IP link for passing drawing requests. Also, converting "X-Window" drawing language to Windows "native" drawing language during the runtime would cause some overhead and will not allow to use full capability of Windows "native" drawing language.
Proxy32 is using "Native" Windows drawing, so it does not have the overheads of using TCP/IP link for passing drawing requests and converting from one drawing language to another during the runtime.
Proxy32 is Native to Windows because it is written in C++ and using Win32 API. It does not use any kind of portable (cross-platform) run-time environment like Java or CLR/.NET.
Once upon a time I wanted to add some simple "external" layer of automation to the CYGWIN XTerm terminal so that user can add shortcuts to frequently used commands and scripts (lists of commands) "on the fly" without need to do any programming. The tool of choice to write such a layer would be tcl/Expect/Tk at that time, but I wanted my software to be pure C++ without any dependency on tcl interpreter or Expect and Tk libraries. During the Spring of 2002 this "external" layer of automation was ready in the form of the standalone CYGWIN program called "telnet proxy". It was loading list of commands and shortcuts from the "config" text file on the start and showing list of commands with shortcuts in its own terminal window. To use automation, any telnet terminal had to make telnet connection via "telnet proxy" to the destination remote host (instead of connecting directly to remote host). Later, when user was pressing command "shortcut letter" in "telnet proxy" terminal window, "telnet proxy" was injecting command into telnet byte stream towards the remote host. At that time COMMAND/SCRIPT/PLUGIN Launchers and Telnet session sharing were already supported, though LauncherTree existed in its prehistoric form of text-choice menu shown in "telnet proxy" terminal window.
When I converted software to Java/Swing GUI in 2003-2004, the need for "telnet-proxying" for external terminal was eliminated. Java version had real Swing-based GUI LauncherTree window and it had real terminal of its own that was executing COMMAND/SCRIPT/PLUGIN Launchers from LauncherTree when user double-clicked on them. Built-in Java Terminal was supporting ssh by using local CYGWIN OpenSSH ssh client as backend (via "ptyopen" CYGWIN program that was, probably, originated in examples for W. Richard Stevens 1992 book). Even so it was not pure telnet proxying, the name "Proxy" was stuck as it was implying that the software is "proxying" between user and remote host by sending commands on behalf of the terminal user instead of having user type commands manually into the terminal.
In 2005 I have converted software to C++ to use only Windows low level native Win32 API (to reduce memory consumption and to have direct access to COM-PORTs). As the software was using Windows Win32 API, the name has changed to "Proxy32" to avoid confusion with older Java/Swing version.
Short answer:
"Everything you can do in CYGWIN as Proxy32 is just another GUI interface to work with CYGWIN. For the question "What one can do in CYGWIN?", the answer is "Almost all that you can do in LINUX" (as most of the CYGWIN software is ported from LINUX world). And in LINUX one can do almost anything as LINUX has wide variety of software for all imaginable intents and purposes.
Technical details:
Well, does Proxy32 add something new to the CYGWIN capabilities? The answer is: yes.
For starters, Proxy32 has LauncherTree. It allows user to build all launchers (to start terminals, scripts and applications) into one big GUI tree. This LauncherTree is somewhat similar to the Favorites/Bookmarks Tree in major browsers, except that it "bookmarks" not only web-page url's but several different actions (creating terminals, executing commands and scripts into terminals, starting Windows applications). Tree is editable by GUI means (Launcher Editor dialogs and Drag-and-drop). It is saved/loaded/exported/imported in XML format. XML format allows bulk edits and easy transfer of user-created LauncherTree to another user.
The rest of the unique Proxy32 capabilities is mostly on the terminal side.
Proxy32 adds abilty to share every terminal session with unlimited number of remote users via TELNET/TLS protocol. This allows more experienced members of the team to couch colleagues and help them remotely.
Another unique feature of Proxy32 terminal is that there is no limit on the length of scroll back buffer. One can scroll back in the terminal window for 60 million lines and terminal does not even "sweat".
Having unlimited scrollback buffer in terminal is complemented by having capability of Regular Expression search (and bookmarking) in this scroll back buffer. Also "Copy text" from such scroll back buffer has no size limit (after exceeding certain size "copy" text is saved in the file instead of using memory-limited system clipboard). "Paste text" operation allows to paste up to 1 MB of text on one mouse click.
Proxy32 terminal can be controlled by PLUGINs. PLUGINs (external processes) can be written in ANY programming language to control terminal via STDIN/STDOUT/STDERR pipes. With regular Terminal software, if one wants to control terminal programmatically, the choice of programming language is usually very limited. With Proxy32 terminal one can choose practically any programming language for terminal automation.
Short answer:
CYGWIN is
a huge collection of LINUX software ported to run under Microsoft Windows
the toolset for rebuilding LINUX software from source code to make it run on Microsoft Windows and small cross-emulation layer DLL library that is used by such ported software
Technical details:
LINUX software is sending system requests (for example, read the file or print the text) to the LINUX kernel in the format that is understood only by LINUX kernel. The heart of the CYGWIN project is CYGWIN1.DLL that can translate LINUX style system requests into Windows style system requests and pass them to Windows for execution. The other core component of the CYGWIN project is CYGWIN GCC compiler that can take the original source code of LINUX software and build this software in a way that it will direct its system requests to CYGWIN1.DLL instead of sending them to LINUX kernel. Once software is rebuilt to use CYGWIN1.DLL instead of using LINUX Kernel, it will run on Windows if CYGWIN1.DLL is present.
All the software that was rebuilt to use CYGWIN1.DLL is part of CYGWIN project. All this software (together with CYGWIN1.DLL and CYGWIN GCC compiler) is available for download from the home page of CYGWIN project http://www.cygwin.com.
Short answer:
Yes. Proxy32 will, probably, give user the fastest and easiest way to access CYGWIN Bash prompt. It will also help user to organize growing CYGWIN knowledge (commands) in the ready-to-use and documented form. But except for those two differences, user still has to go through the learning of CYGWIN commands, regardless of using or not using Proxy32.
Technical details:
When one downloads and runs Proxy32.exe file, it will automatically create CYGWIN installation (with pre-selected set of packages) and start CYGWIN bash in Proxy32 Terminal at the end of installation process. Several minutes after clicking "Install" button in Proxy32, user will have CYGWIN Bash shell prompt in open terminal window inside of "Workspace0".
Then one can start learning LINUX/CYGWIN commands that can be executed at Bash prompt.
In Proxy32 user can save useful command as "COMMAND Launcher" on LauncherTree. This way the command will be saved in the form that is ready for future execution by double-click on it. Also, user can attach extensive tooltip text to the "COMMAND Launcher", for example, to show sample printout of the command that is configured in this "COMMAND Launcher". "COMMAND Launchers" can be grouped into "SUBTREE"s on LauncherTree. LauncherTree is searchable (using PERL REGEX).
Proxy32 process does not link to any static or dynamic CYGWIN library, so it does not have to be licensed under GPL. Proxy32 built-in terminal is using Windows inter process communication (IPC) mechanism to control standalone CYGWIN TTY-driver process called "proxycygterm". I have derived "proxycygterm" code from "cygterm" code in March 2006 to use it as new Proxy32 to CYGWIN TTY interface. Source code of "proxycygterm" is published here (as "cygterm" code is licensed under GPL). GPL source code of unmodified CYGWIN binaries that Proxy32.exe installs is located here.
One can think of external backend as local child process that user is interacting with by the means of the terminal. This child process in turn can represent either local shell or remote host via TELNET/FTP/SSH/SFTP/COM-PORT connection. Proxy32 built-in terminal is using Windows inter process communication (IPC) mechanism to control standalone external backends. Proxy32 terminal on "connect" starts configured "backend" as child process and communicates with it via STDIN/STDOUT/STDERR pipes. Most powerful backend is CYGWIN TTY-driver process called "proxycygterm". It creates CYGWIN TTY and starts any configured CYGWIN application on this TTY. On resize of Proxy32 terminal it sends Telnet NAWS command to STDIN of proxycygterm to resize slave TTY to match new size of the Proxty32 terminal. If backend command line does not contain word "proxycygterm" then NAWS command is not sent to STDIN of backend process. If backend process exited or died, Proxy32 terminal disconnects. If user "disconnects" Proxy32 terminal manually, backend process and all process tree it has created is killed.
Example of command line of backend process (SHELL) to launch CYGWIN Bash on proxycygterm TTY in the Proxy32 terminal: “proxycygterm.exe -s ‘/usr/bin/bash -i -l’” Command line is shown as it is entered into configuration of the SHELL-TERMINAL launcher.
Backends are very important as they extend functionality of the Proxy32 terminal.
Proxycygterm is the primary external backend that supports STDIN/STDOUT/STDERR/NAWS communication with Proxy32 terminal and allows to start any configured CYGWIN application on CYGWIN TTY and maintain correct size of this TTY at all times. Most frequent CYGWIN applications to run on proxycygterm tty are bash, telnet, ftp, ssh, sftp, GNU screen and mc (midnight commander). proxycygterm.exe supports utf-8.
PuTTY command line "friends" plink.exe and psftp.exe can be used directly as backend of Proxy32 terminal, but terminal window information will not be communicated to the remote host of plink.exe connection.
Windows command line interpreter CMD.exe can be used directly as backend of Proxy32 terminal, but some "Windows-console" type applications that can be started from CMD.exe are using direct internal access to caret and screen buffer of Windows console. They will not work as they do not communicate with the user via STDIN/STDOUT/STDERR pipes by design. Examples of such applications are Windows command-line TELNET client and Windows command line FTP client. Another important example is PowerShell. To handle command line applications that do not work without console window, proxy32 terminal uses another wrapper called proxywinconsole.exe. proxywinconsole.exe is similar to proxycygterm.exe as it creates hidden Windows Console window and then starts application (like PowerShell) on it. Then proxywinconsole will translate I/O of the application between Hidden Console window and proxywinconsole.exe STDIN/STDOUT. proxywinconsole.exe supports utf-8 (Microsoft Windows Console Window only supports BMP part of Unicode charset).
Natively:
Following communication protocols are supported "Natively" by Proxy32 Terminal (aka, without attaching Terminal to various CYGWIN or PuTTY communication shells):
"Native" protocols will work even if Proxy32 does not find or unable to install CYGWIN or PuTTY.
via CYGWIN backend:
Many more protocols are supported by connecting Proxy32 terminal directly (does not have to be via Bash prompt) to appropriate CYGWIN application (CYGWIN communication shell), including but, likely, not limited to:
When using CYGWIN communication shells as back-end for Proxy32 terminal, terminal resize information is passed to CYGWIN tty (on which ssh or telnet client is running) and then communicated properly to remote host.
via PuTTY backend:
PuTTY command line utilities ("plink.exe" and "psftp.exe") are installed by Proxy32 and can be used as back-end (communication shell) for Proxy32 Terminal:
When using PuTTY communication shells as back-end for Proxy32 terminal, terminal resize (tty) information is not communicated properly to remote host (as there is no tty involved on client side).
One can use in SHELL-TERMINAL launcher command line proxycygterm.exe -s '/usr/bin/screen -s bash'. It will start local CYGWIN "screen" application (for multiplexing multiple virtual vt100 terminals into one physical terminal) on the CYGWIN TTY created by interface program proxycygterm.exe. Once you see screen application initialized and started bash shell, use sequence of 3 keyboard commands ^aS then ^aTAB then ^ac to split window in two parts, switch to newly created split, create second virtual vt100 terminal and start new shell in the second virtual terminal. Then you can use both virtual terminals independently and switch keyboard input between them with ^aTAB (means "press Ctrl-a first, then press TAB"). Further use of ^aS then ^aTAB then ^ac will create more virtual vt100 terminals in the same physical proxy32 terminal. This mode is convenient to control multiple connections from single physical proxy32 terminal window under control of single script/plugin. Such operation allows to simulate functionality of "cluster" (or "vector") terminal when multiple connections to several network nodes working in redundant load sharing cluster are established in one terminal window and under control of single script/plugin. Issuing command ^a:caption always "%w" will force status line under the screen of every virtual terminal.
Often the whole team of people working on different computers and even from different locations should share single terminal session. Shared session means all team is typing on "remotely-shared" keyboard (one at the time) and viewing "remotely-shared" screen with output of remote host (simultaneously). This "shared" Proxy32 terminal session can be login session to remote host or session of local Proxy32 terminal CYGWIN bash shell activities. When such "sharing" may be needed:
Coaching
More experienced members of the team have to couch/teach colleagues and help them remotely.
Only single login session is available for many people
Remote host allows only one single login session but many people should perform their part of work with remote host (one at the time as this is the same terminal session).
Execute legacy scripts from another terminal software
User has to use different terminal software to work with the same terminal session. Say, user works most of the time in Proxy32 terminal session but still has to run legacy scripts written long time ago for another automated terminal. Examples: Expect script to interact with remote host over telnet in Xterm, TeraTerm script, SecureCRT script, AbsoluteTelnet script, etc. If user does not want to convert/adapt those legacy scripts to use them in Proxy32 terminal there is another way to execute them into existing Proxy32 terminal session. Another terminal (the one that can run legacy script) can be temporarily connected to Proxy32 terminal session (via Proxy32 terminal session sharing port) to execute it's own legacy script into this existing Proxy32 session. Then another terminal is disconnected from the session and user continues to work with the same session in Proxy32 terminal.
Every Proxy32 terminal window has built-in TELNET/TLS server and one "serving/listening" COM-PORT to share existing terminal session with remote users. Remote users connect via TELNET, TELNET/TLS or Serial protocol to Proxy32 terminal to receive copy of the output from remote host and to be able to type commands into shared terminal session. One user at the time can type commands to the remote host (shared session means shared keyboard and shared screen), otherwise remote host will be confused. Local User at the Proxy32 terminal can switch Remote users into "read only" mode when they will receive output from remote host but they cannot type commands to the host.
TELNET server:
Unlimited number of remote users (telnet clients). No authentication, no encryption. Remote user needs to know only "sharing" TCP port number to connect to Proxy32 terminal session. But the port number is random by default, so Local User has to supply this information to Remote User before Remote User can connect to the terminal of Local User.
TELNET/TLS server (TELNET protocol over Transport Layer Security protocol):
Unlimited number of remote users (telnet/TLS clients). Certificate authentication (server only or both server and client). Encryption is implemented by Microsoft Windows SCHANNEL library (that is also used for TLS part of HTTPS by MS Internet Explorer). Remote user initially needs to know "sharing" TCP port number to connect to Proxy32 terminal session. After TCP connection is established, both parties will validate each other's certificates (digital IDs) and (if validation is successful) proceed to cipher negotiation. When Cipher is negotiated, encryption starts and then TELNET connection is established inside of already encrypted TLS/TCP pipe.
Serial (COM-PORT):
One remote user (serial Terminal). No authentication, no encryption. Remote user needs to know only "sharing" COM-PORT number and settings to connect to Proxy32 terminal session. Useful to connect over Bluetooth COM-PORT link to share Terminal session between two computers that are IP-isolated by firewalls or by infrastructure.
Proxy32 PLUGIN is a child process that is started from the terminal and receives control over the interaction with remote host. Proxy32 PLUGIN interface to terminal is better that ActiveX/COM programmer's interface used in the other automated terminals:
it gives programmer direct access to terminal I/O byte streams,
it places less restriction on the programmer,
it requires practically no learning as there is no PLUGIN API.
Here is the brief description of the PLUGIN interface to control the terminal and remote host:
PLUGIN process is created from command line that is stored in the PLUGIN launcher. PLUGIN process will be used to control "active" (red frame) terminal
PLUGIN process is started as child process of terminal, in particular, that allows to kill PLUGIN process from terminal at any time (for example, terminal is closed or disconnected, or user decided to kill PLUGIN manually)
PLUGIN process does not have console/terminal window created for it (it is controlled only via Proxy32 Terminal in which it is running)
STDOUT of PLUGIN process is connected to the terminal's byte pipe that sends bytes to remote host. (STDOUT is sending bytes to remote host, instead of terminal keyboard)
STDERR of PLUGIN process is connected to the terminal's byte pipe that sends bytes to screen of the terminal
STDIN of PLUGIN process is connected to the terminal's byte pipe that receives buffered output bytes from the remote host
To automatically finish login for the SHELL-TERMINAL launcher with the following command line:
“proxycygterm.exe -s ‘/usr/bin/ftp 192.168.1.9 21′” one can place PLUGIN launcher with the following command line under the SHELL-TERMINAL launcher:
perl -e '
$a="";while(){sysread STDIN,$_,10000;syswrite STDERR,$_;$a.=$_;last if $a=~/Name/;}
syswrite STDOUT,\'belous\';syswrite STDOUT,"\r\n";
$a="";while(){sysread STDIN,$_,10000;syswrite STDERR,$_;$a.=$_;last if $a=~/assword:/;}
syswrite STDOUT,\'test123\';syswrite STDOUT,"\r\n";
$a="";while(){sysread STDIN,$_,10000;syswrite STDERR,$_;$a.=$_;last if $a=~/ftp>/;}
'There are seven lines of code here (1-7):
-e command line switch). Single quote at the end of the line starts the string that contains in-line PERL script.Name. Loop is exited when prompt is found.belous to remote host (STDOUT) followed by the CR/NLassword:. Loop is exited when prompt is found.test123 to remote host (STDOUT) followed by the CR/NLftp>. Loop is exited when prompt is found. This is the last line of the PERL script, PLUGIN is exiting here and connection between remote host and user`s screen and keyboard is automatically restored.in-line PERL scriptNote that this PLUGIN is designed to be started automatically on connect of the terminal. Autostart of the PLUGIN is achieved by placing PLUGIN launcher directly under the SHELL-TERMINAL launcher on the LauncherTree. When user double-clicks on the SHELL-TERMINAL launcher, terminal connects and then it looks for PLUGIN/I-SCRIPT launcher located directly under SHELL-TERMINAL. If such PLUGIN/I-SCRIPT launcher is found under SHELL-TERMINAL Launcher, it is executed immediately without user intervention. If PLUGIN Launcher is started manually, it will be too late to catch Name prompt from ftp server. Then PLUGIN will start reading from remote host after the Name prompt is already gone. PLUGIN will hung waiting for Name prompt in indefinite loop (until it is killed by user).
More info about PLUGINs can be found here.
Proxy32 can create Separate Windows Desktop and start Proxy32 GUI on it. In this case programs started on Common Windows Desktop will be unable to interact with Proxy32 GUI (manipulate Proxy32 windows and send mouse and keyboard events into them). When Proxy32 GUI is started on the Separate Windows Desktop, it allows user to switch back and forth between Separate and Common Windows Desktops via special key combination. Running Proxy32 on the Separate Windows Desktop can be used for executing mission-critical tasks when user wants to avoid any interference from the other Windows applications.