From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: [land AT long DOT yar DOT ru: Letter to Cygnus developers] 22 Sep 1998 05:51:42 -0700 Message-ID: <19980922083120.B26399.cygnus.cygwin32.developers@cygnus.com> References: <19980922014150 DOT 23623 AT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Geoffrey Noer , cygwin32-developers AT cygnus DOT com Cc: land AT long DOT yar DOT ru On Tue, Sep 22, 1998 at 01:41:50AM -0700, Geoffrey Noer wrote: >Looks like this should really have been sent to cygwin32-developers so >I'm forwarding it. > >-----Forwarded message from "Andrey V. Lukyanov" ----- > > Letter to Cygnus developers > (A user's look on Cygnus) > > Gentlemen, > > being a simple user, I still feel myself entitled to tell you something >concerning the Cygnus architecture. > > Firstly, Cygnus follows the Windows-imposed distinction between >text-mode and GUI applications. As you may know, a text-mode program >always has a console (so I cannot make it to run completely in background >if I start it from some GUI program). At the same time, a GUI program has >no access to the console from which I start it. This is so different from >UNIX X-Windows environment, where any program may have or not have a >console and in every case may write something to the xterm window from >which I have started it. First off, I believe that you are referring to the Cygnus product which is called "Cygwin32". Second, a GUI program on winodws *can* have a console and a console program can start a window. It is true that a GUI program cannot easily reference the console window which started it but I don't see why this distinction is important. > The solution would be simple: use only one type of programs, namely GUI >programs. In order to make a GUI program look like a text-mode program, we >need to make a terminal emulator, which should create 3 anonymous pipes >(for stdin, stdout and stderr) and to pass the 3 handles (via STARTUPINFO) >to the GUI program that we want to look a text-mode program. So, if our >terminal emulator is called term, we can start our UNIX-like shell (which >will be a GUI program, but without windows) as follows: > > term bash >> When we start other programs from bash, they receive (again via >STARTUPINFO) these 3 handles and use them for their standard input and >output. > > The terminal emulator itself may be either a text-mode or a GUI program >(it is a good idea to supply both, so we will please everybody -- those >who like decorations and those who like simple black screens). This would be an incredible amount of work and, if I understand you correctly, you still want to leave the terminal emulation in the .dll for those who "like simple black screens". What would be the point of doing this exactly? For the GUI method you'd have to do all of the "terminal emulation" that is in the cygwin console layer plus a whole lot more. I'm not sure what problem this is solving. > In addition, it will be much easier to make telnet-like programs -- no >need to create terminal emulation inside them, because it will be outside >them! Why do you think that you have to do anything special to create a telnet like program? You do what you would do in UNIX -- you send escape sequences to the screen to control cursor placement, color, region clearing, etc. > Secondly, Cygnus tries to preserve the old DOS habits of using CR/LF >and Ctrl-Z. From a user's point of view, it is a totally unnecessary >complication, because there are many good text editors that handle >UNIX-style text flawlessly. It is even more unnecessary in view of the >fact that people intend to have ultimately a single set of sources for >both UNIX and Cygnus. Please read the gnu-win32 mailing list archives. There is no simple solution to this problem. It has been rehashed almost continuously for quite some time. Let me just say, that while I am no fan of CRLF and CTRL-Z, people using Cygwin are living in a Windows environment where files with CRLF in them are the norm, not the exception. Ignoring these types of files or putting the onus on the user to modify programs to deal with them seems to me to be clearly the wrong way to go. > At this point, let me remain > Very truly yours -- cgf AT cygnus DOT com http://www.cygnus.com/