First, don't take all my reactions as defenses of my word choices, but consider they may rather be just explanations. I'm open to changing the wording in most cases.
Also, I have written a large part of this message before reading the other
responses, so forgive me if I repeat myself (or anyone else).
On 10. 2. 2016 8:36, Daniel Goldman wrote:
>> Regular Windows program as opposed to Cygwin or MSYS2 programs.
>> Those are Windows programs as well (EXE and stuff), but the
>> POSIX compatibility layer is making them "irregular".
>> Furthermore focusing the definition, I was talking
>> specifically about console programs (i.e. not pure
>> GUI ones, but AFAIK the differences between console
>> and GUI executables are miniscule).
>
> Again, when someone says "normal windows program", they are thinking about
> GUI programs - firefox on windows, excel on windows, etc. Since you are
> wanting to describe "console programs", why would you say "normal windows
> program"? It's totally confusing.
Again, because 1) Cygwin programs are Windows programs as well (they run on
Windows, after all), and 2) the domain of console programs is already
established in the first paragraph.
> Looking in the index of Programming Windows (Petzold), win32 Programming
> (Rector), and windows 2000 api superbible, there is no entry for "console"
> programs. We can't use undefined words, it confuses the reader. FWIW, Petzold
> calls it "character-mode". Even that is not too helpful, IMO.
>
> The problem here is that technical writing is hard, and I'm sorry, but you
> don't seem very good at it. Join the crowd, most writing stinks. I can't
> teach you how to do it, you would need to read a book or take a course. I
> would at least suggest that you put yourself in the role of someone reading
> the text for the first time, and be prepared to edit a fair amount. Also,
> good technical writing is structured, is clear, goes through logical
> sequences, and takes advantage of formatting conventions. I'm also pretty
> busy, but am at least willing to point out places where the message fails,
> and have taken some effort here. BTW, the cygwin web site has some of the
> WORST writing I have ever seen, specifically their incredibly long-winded
> section on posting etiquette.
I'm okay with sucking at writing in this situation. Consider that I'm also busy
and didn't actually spend much time on the article. I'm all for making the
article clearer and more accessible and I appreciate your effort. I'll continue
to revise the article based on your feedback (and maybe if I find more time,
I'll re-read it and come up with my own feedback, as you suggested).
>> I don't like the term so much either. If you think of
>> a better term that is not too technical, I'll start
>> using it instead. Note that I want to cover both
>> ncurses and readline-type interactive console programs.
>
> There probably is no really good term. That is perhaps because such "console
> programs" are so rare, at least in the windows world.
>
> Here is my suggestion, based on your first paragraph. We have to both define
> our terms, and give good examples. A good example is worth 1,000 words. Write
> something like: 'To make sure we're on the same sheet of music, we need to
> define the types of programs: 1) The first category is "msys2 programs".
> These programs are created by blah, blah. They run blah, blah. Good examples
> are X, Y, and Z. X shows blah, blah. Y is different in that blah, blah. Z
> shows blah, blah. 2) The next category is "curses programs". These programs
> are compiled with ncurses or pdcurses. ncurses is used when blah, blah. Use
> pdcurses if blah, blah. Curses programs have a TUI (text user interface), and
> optionally may support the mouse. Good examples are X, Y, Z. X shows blah,
> blah. Y is different in that blah, blah. 3) The final category is "windows
> console programs". These programs are native windows executables, like excel
> or firefox, but are NOT GUI programs. They only read and write text to a text
> window (the console). They do (do not?) support a mouse.'
I think you've partially fallen into your own trap. What are "native windows
executables" to our reader? This term IMO desires further explanation or
definition in order to keep the proposed technical level of the article.
I've realized that instead of trying to accommodate every possible reader in
the article, it could be better to establish a baseline using references to
Wikipedia. If the reader doesn't know a term, they can read up on it.
> I may (probably do) have the details wrong in the above description. Another
> point about technical writing is don't put something down as true unless you
> are sure. You can always say "This section needs expansion. Can someone
> please suggest additions?".
I'm not sure about my writing, but I'm pretty sure of the facts. Maybe it's all
just terminology confusions.
>> Ncurses isn't really a regular visitor on Windows, is it?
I noticed the irony of calling Windows ncurses programs "regular" (but didn't
come up with a better term yet).
>> But non-Cygwin ncurses programs were supposed to belong into
>> the group of "regular Windows programs". The general
>> explanation should apply to them as well.
>
> I didn't limit myself to ncurses. So I don't understand the comment.
You said:
>>> I was specifically referring to curses programs. I stated that clearly.
I reacted to that to say that I covered them as well regardless of the
"regular" adjective I used.
I saw "curses", "ncurses" and "pdcurses" as interchangeable in this context, so
maybe that was the source of this specific confusion.
> "non-Cygwin ncurses programs" are ** NOT ** regular windows programs. I'm
> sorry, that's totally ridiculous and shows a total misunderstanding of the
> two programming models. I'm willing to be corrected if I am wrong. However, I
> write both curses and native windows applications, at the source code level,
> so I know the difference. Why would you not want to split out programs that
> use the win32 api from those using curses? If they share some
> characteristics, that's fine to point out, but they seem like apples and
> oranges to me.
Even curses programs use the Win32 API "under the hood". See pdcurses source
directory `win32` and ncurses source directory `win32con`.
I've mixing these two categories intentionally because both fall under the
category of console programs.
>> I agree. I wasn't intending to describe the technical details, but I
>> could've rephrased like so: "The way mintty expects input and output
>> matches the way other Cygwin programs were built to send and receive."
>
> I'm sorry, I find that confusing, all the business about the input and output
> matching. Get to the main point. I might say, "cygwin programs built using
> the standard X method or the standard Y method run correctly under mintty". I
> have no idea what the "standard methods" I mention are. Hopefully, there is
> some agreed upon vocabulary for the methods. If not, that should be a first
> priority.
Okay, rewritten.
> As part of this, I would hope that you define what the standard method(s) for
> building curses cygwin programs to run under mintty, the point of my original
> post. :) If that is not currently known, then I would put a note. IMO, it
> doesn't help for us to act like we understand something when we obviously
> don't.
I don't think there was anything profound to say. You should use Cygwin gcc and
Cygwin ncurses and it should work out fine.
>> I'm not so sure about specifying versions of ncurses,
>> but I could add Cygwin bash and Cygwin mc as examples.
>
> There are not "versions" of ncurses, except in the sense of new release
> numbers. There is just ncurses. I said "version of curses". The separate
> version is pdcurses. It would help to clarify which is used for what. My
> thinking is that ncurses is used to compile cygwin curses exes (eg, mc), and
> pdcurses to compile curses exes intended to run under windows (eg, my
> program). If that is the case, why doesn't MSYS2 come with pdcurses (my
> understanding) (I copied pdcurses library to under MSYS2 root myself by hand)?
I admit that I know little of the difference between ncurses and pdcurses. I
always thought they just implement the same APIs, but are from different
authors. I would disagree with the statement that one is for Cygwin and other
for Windows. Note that MSYS2 has both `ncurses` and `mingw-w64-ncurses`, both
of which should work in their respective environments (didn't test myself).
>> Cygwin bash can be run both inside a Windows console and
>> inside mintty (or other Cygwin terminal emulators). I was
>> assuming you mean bash+mintty. Bash does little to affect
>> if mc will work or not, it's the console/terminal.
>
> I very clearly said bash under windows 7 command window. That was the entire
> point of the post, which you seem to have totally missed.
No, you didn't say it clearly at first. Originally, you said this:
>>> For example, I notice that mc runs poorly under the
>>> bash.exe environment. Arrow keys don't work, colors get messed up, it is
>>> slow. Oddly, mc (same exe) runs perfectly when run directly from dos shell.
I assumed you meant bash+mintty in the first ("poorly") case and cmd+conhost in
the second ("perfectly") case and responded accordingly.
Then you said:
>>> I never said mc.exe had problems under mintty. I believe you misread. I
>>> said "mc runs poorly under the bash.exe environment", which I believe is
>>> separate from mintty, since bash.exe is run from within the windows 7
>>> command prompt. If I'm wrong about this, please let me know.
So I explained my misunderstanding (I didn't misread -- there was no indication
of whether mintty or conhost was used in that example). After you explained, I
threw away my original assumption and went on to talk about the situation you
were actually interested in.
>> That's surprising. I've attached a screenshot of
>> my /usr/bin/mc.exe. Input seems to work fine, but
>> the UI is not good.
>
> Thanks for doing the test / screenshot. Indeed, it looks like garbage.
> However, you don't provide enough detail for me to be sure you are running
> under the same kind of window (windows 7 command window / command prompt). If
> you are running same window, it makes my point about how these different
> environments (mintty, etc.) are so poorly understood. Again, someone else
> could easily, in a few seconds, repeat the experiment.
>
>> Like you, I'm speaking from my personal experience. I
>> really wonder why your mc works in a Windows console. I'm
>> on Windows 10, but I've tried both legacy mode and the new
>> mode, but without luck.
>
> Now we are maybe making progress. You're using Windows 10. Maybe that's the
> difference. Could someone else please repeat the experiment?
More test results in the other discussion.
> An attempt to improve your text, to my best understanding (please correct any
> factual errors you might see):
>
> ================ START
>
> About mintty, winpty, bash, cmd, consoles and terminals
>
> This topic is not totally understood. The following information is our best
> understanding. If the reader has any corrections / clarifications, please
> post to the email list. Note that where we say MSYS2 below, one could usually
> substitute Cygwin and get the same meaning.
Using primarily MSYS2 instead of Cygwin sounds good.
> -------------- Types of programs
>
> To start off, we need to define four different types of programs:
>
> 1) The first category is "MSYS2 command line programs". These programs are
> created by the process described in the section XXX. They normally run in the
> standard mintty window. Good examples are ls and cat. "MSYS2 command line
> programs" use stdin, stdout, and stderr.
>
> 2) The second category is "MSYS2 curses programs". These programs are created
> by programming in and linking to the ncurses library (reader, please correct
> if that is not the case!). Good examples are vim and mc. curses programs do
> not normally use stdin, stdout, or stderr. Instead, they present a TUI (text
> user interface), such as with vim and mc.
They do use stdin, stdout and stderr. See article or
<https://en.wikipedia.org/wiki/ANSI_escape_code>.
> 3) The third category is "Windows curses programs". These are like category
> 2) except that they are intended to run under the Windows "command prompt",
> not under wintty. An example would be some curses program you write, but not
> for MSYS2. pdcurses is normally used to compile curses programs designed to
> run in the "command prompt".
IMO confusing.
> 4) The next category is "Windows GUI programs", such as excel or firefox. An
> example would be a GUI program you compile under MSYS2.
>
> Two other categories are not further discussed. "Windows console programs"
> are native windows executables, but are NOT GUI programs. They only read and
> write text to a "command prompt" window (the console). Basically, nobody
> writes these kinds of programs.
Not true. Console programs may not be the most popular thing in the Windows
world, but in context of MSYS2, there's lots of console programs (see
/mingw64/bin/*.exe).
> "Windows .NET apps", to our understanding, are totally separate from MSYS2.
.NET apps can be console programs as well as GUI programs. No need to separate
them out.
> -------------- Ways to compile under MSYS2
>
> There are two basic ways to compile under MSYS2:
>
> 1) Compile for running the executable under MSYS2 (categories 1 and 2 above).
> An example would be from compiling mc (midnight commander) to run in a mintty
> window. Methods for compiling MSYS2 programs are detailed in the section
> XXXXX.
>
> 2) Compile for running the executable under Windows (categories 1 and 2
> above). An example would be a Windows GUI or curses program you are using
> MSYS2 to compile. We do not have separate documentation describing how to
> compile these kinds of programs. Please refer to standard sources concerning
> how to compile using gcc or clang.
>
> Keep in mind to use the correct MSYSTEM mintty window for compiling (MINGW32
> for 32 bit, MINGW64 for 64 bit).
>
> -------------- mintty, win32 console, shells
>
> mintty is a terminal emulator built for running MSYS2 programs. It's the
> window where you enter commands. It provides the necessary POSIX interface
> for MSYS2 programs to correctly display and receive text. MSYS2 programs
> compiled with the XXX method run correctly under mintty.
>
> mintty only runs console (non-GUI) programs. If for some reason you start a
> "Windows GUI program" from mintty, it runs independently of MSYS2, under
> Windows. Similarly, a "Windows curses program" will normally not run
> correctly under mintty, probably won't even start.
>
> There are other terminal emulators, but they're not provided in MSYS2. You
> will normally use mintty.
>
> The Windows "command prompt" (formally called "win32 console")
> (https://en.wikipedia.org/wiki/Win32_console) is the command line interpreter
> under Windows, and may also be used to run curses programs. It might also be
> referred to as "DOS prompt".
>
> A shell is the actual program that reads commands from you and then runs
> them. When you open a mintty window, you'll probably see bash (a shell)
> running inside and waiting for your commands. The Windows "command prompt"
> runs cmd.exe to read and run commands.
>
> -------------- Terminal emulator combinations
>
> Normally, you will run 1) "MSYS2 command line programs" and 2) "MSYS2 curses
> programs" from mintty, 3) "Windows curses programs" and 4) "Windows GUI
> programs" from Windows "command prompt".
>
> However, there is a confusing (but useful) array of other combinations and
> ways to run programs. Here is the current list of possibilities:
>
> - It is possible to run an "MSYS2 command line program" program (eg, ls or
> grep) in a Windows "command prompt".
>
> - Conversely, you can run "DOS commands" and batch files in mintty. Not sure
> why you might want to do this. A major point of using MSYS2 is to take
> advantage of the superior UNIX environment.
>
> - You can run MSYS2 bash.exe in a Windows "command prompt". This allows you
> to run and debug "Windows curses programs" from within a UNIX-type
> environment.
>
> For basic stuff, the above combinations work fine. Anything more complicated,
> like colored text, TUIs and line editing, may break (or may work). For
> example, as of Feb, 2016, mc (midnight commander) is reported to run
> correctly under windows 7 "command prompt", but not for windows 10.
>
> ------------ winpty
>
> winpty is a wrapper program that works as a translator between Windows curses
> programs and mintty. It opens a hidden Windows "command prompt" window and
> opens the wrapped program in it. It then relays input from your terminal to
> the program and output from the program to your terminal. This may solve
> issues of running Windows curses programs in a Cygwin terminal. However, as
> of Feb, 2016 this is reported to not work correctly.
>
> ------------ Open issues
>
> - Could MSYS2 have pdcurses included, for Windows curses programs?
>
> - Is ncurses always used for compiling MSYS2 curses programs (eg, vim)?
>
> ============ END
I took some parts of the text, but I'm not convinced of the usefulness of
mentioning all of it. It doesn't mean your text will go to waste. I'm thinking
maybe a separate, developer-focused page on TUI/curses apps would be a good
place for it. What do you think?
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
