Mail Archives: cygwin-developers/1998/09/23/13:04:32
On Tue, 22 Sep 1998, Christopher Faylor wrote:
> On Tue, Sep 22, 1998 at 01:41:50AM -0700, Geoffrey Noer wrote:
> >-----Forwarded message from "Andrey V. Lukyanov" <land AT long DOT yar DOT ru>-----
{many further lines are skipped}
> First off, I believe that you are referring to the Cygnus product which
> is called "Cygwin32".
Just so.
My first point was that it is a bad thing to have 2 types of executables
on the same platform. So, for reason of consistency, it is better to have
only one of them -- namely, GUI.
> 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.
Imagine I have ported an X Windows program. For X programs, it is common
to write error messages to the xterm window from which the program was
started. At the same time, if the program was started not from an xterm
window, it will run OK without such. How can we emulate this behaviour
under Win32 if not using GUI programs with a separate terminal emulator?
> 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".
I think that the amount of work will not be so great, because the main
task will be to split one module in two.
As to simple black screens: the terminal emulator in both cases will be a
separate program using either a console or a normal window to make input
and output. All other modules should know nothing about this.
> 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.
It is the concept of modularity. You will easily agree that emulating UNIX
APIs is one thing, and emulating a terminal is another thing. So it is
preferable to implement them separately, because they do not depend much
on each other.
And then it is the portability. Under Win32s, there are no consoles.
Still, using a GUI terminal emulator, we can make Cygwin32 to run on this
platform (this platform is not very important really, but the more
universal solutions are preferable).
And you should not think that implementing a terminal as GUI is much more
difficult than doing so as a console program. In fact, it may be even
easier (and certainly more exciting).
> > 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.
The only thing the people have to do is to get a text editor that
understands both types of text and allows conversions (plus maybe a bulk
conversion utility).
UNIX compilers usually have no options for opening files in "text mode".
Still many UNIX programs handle DOS-style and UNIX-style texts equally
good. All you need is to port these programs. To make things easier, Win32
output routines do not require the CR byte.
As to the Ctrl-Z symbol, it is now completely obsolete. Even the command
"copy con" does not append it to files.
There is one more problem that I did not mention previously. The Microsoft
Windows is unique in that it normally uses 2 different character sets
(usually referred to as ANSI and OEM) simultaneously. For Americans, this
problem is virtually nonexistent, but in Russia it is really annoying.
The best solution would be to drop the OEM character set support completely
and to have only one type of text files (namely, ANSI). If we use a
separate terminal emulator, the OEM/ANSI translation will be inside it,
and all other modules can safely suppose that there is no OEM character
set at all. But, of course, the present system of putting everything in
one DLL also permits to hide translation from the user programs.
Currently, Cygwin32 uses the OEM character set. But, if I develop a
Windows program, then all text strings must be in the ANSI character set,
and all the Cygwin32 text utilities will be unusable. And that's more,
UNIX systems (AFAIK) never use the OEM character set, so there is no
reason to keep it.
Best regards
- Raw text -