Post by David MacekAgain, 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.
We can use whatever brief terms we please, as long as they:
- correspond with real-world things.
- are clear to the reader.
- if needed, are briefly defined or have examples.
"normal windows program" by itself, without clarification, fails those
criteria. I'm a windows programmer, and I don't know exactly what the
phrase means. The phrase is not in common usage.
Post by David MacekI 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 must point out that the very first sentence of the MSYS2 wiki mentions
"native Windows software". :) In any case, I gave examples to make it
clear what I was referring to. "Theoretical" definitions (eg, "native
windows") are often weak. Examples are usually better. Anyway, I think
this kind of got rewritten below.
Post by David MacekI'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 agree. Mention which technologies (eg, ncurses) are used where. Other
than perhaps brief mention of what the technology does (eg, TUI
programming library), it's up to the reader to read elsewhere.
Post by David MacekI'm not sure about my writing, but I'm pretty sure of
the facts. Maybe it's all just terminology confusions.
I agree it's largely terminology confusions. However, I think I have
also seen and documented some wrong understanding of the facts. I admit
some of my understanding of the facts is incorrect. That was the whole
point of my original post, trying to get some clarification.
Post by David MacekI noticed the irony of calling Windows ncurses programs
"regular" (but didn't come up with a better term yet).
Right. ncurses programs are ncurses programs. That's it. It perhaps (not
sure about this) needs to specified whether they are compiled to run
under mintty or under "command prompt". Again, this was why I originally
posted, to ask for clarification.
Post by David MacekI saw "curses", "ncurses" and "pdcurses" as interchangeable
in this context, so maybe that was the source of this
specific confusion.
Right, you had a misunderstanding. The terms are NOT interchangeable.
"pdcurses" and "ncurses" are both "curses" libraries. But they are
different.
For the most part they share the same function calls, but the code needs
to written somewhat differently, especially related to various
constants, for one or the other.
And they are intended (to my understanding) for different purposes.
ncurses -> unix. pdcurses -> dos / windows. And I take it that ncurses
-> msys2 though I have never seen this explicitly stated.
Again, given that msys2 is designed to support compiling programs to run
under windows, I don't understand why pdcurses is not built in.
Post by David MacekI 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).
You may be right that ncurses could be used for either cygwin or
windows. However, it's not my understanding. I have previously used
ncurses under windows, and it turned out pdcurses worked better in some
ways. I would have to do some research to be more specific. Does anyone
else know the preferred usage, and for what reason?
Post by David MacekPost by Daniel GoldmanFor 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 didn't misread -- there was no indication of
whether mintty or conhost was used in that example)
I'm sorry, but I did say it clearly, you did misread / selectively
quoted the post, the first attribute of the good programmer is to admit
reality and move on, here is the relevant text from the post:
Run "C:\msys64\usr\bin\bash.exe --login -i" from within the windows 7
command prompt ("dos shell") and get a bash prompt. Then run the curses
(compiled with pdcurses) program with "./txu1-tpl-eg1.exe" - it runs
perfectly! Arrow keys work, everything looks / functions perfectly.
I'm still confused about the difference between 1) mintty, 2) winpty
from within mintty, 3) bash.exe from within dos window, and 4) dos
window itself. 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.
Obviously, "bash environment" refers to "bash.exe from within dos
window", not mintty. I never suggested that mc.exe had a problem running
under mintty. Obviously, that would have been a priority #1 bug report,
it wouldn't make sense to just mention that as an aside.
Post by David MacekThey (curses programs) do use stdin, stdout and stderr.
See article or <https://en.wikipedia.org/wiki/ANSI_escape_code>.
I disagree. I stand by my statement that "curses programs do not
normally use stdin, stdout, or stderr", but am ready to be corrected and
learn. However, when I search the article you cite for "stdin",
"stdout", "stderr", nothing comes up.
Are you a curses programmer? If yes, then why do you offer such
irrelevant evidence? If no, then why are you disputing?
Post by David MacekSo 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.
You know nothing about me, so I can't criticize your directing me to the
bin directory. But you just misread some. I already categorized those
programs as "MSYS2 command line programs". I was referring to someone a
win32 api app for running under windows, and stand by my statement that
the overwhelming number are GUI.
Post by David Macek"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.
Whatever you want to do with .NET apps is OK with me. I'm also a C#
programmer. I'm well aware of what is possible. I have no idea if MSYS2
is structured to allow compilations of .NET apps. I did not see it
mentioned, but did not particularly look for it. You can edit as you see
fit depending on whether MSYS2 actually compiles .NET apps (no, I am not
asking for that capability).
Post by David MacekI 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?
I think it is a good idea, especially if it lists the uncertainties. You
can use as little or as much of my suggested text as you like, it's up
to you. I appreciate your volunteering. MSYS2 is very useful.
Daniel