On 2/10/2016 11:57 AM, David Macek wrote:
> 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.
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.
> 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 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.
> 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 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.
> I'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.
> I 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.
> I 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.
> 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).
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?
>
> 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 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.
> They (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?
> 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.
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.
>> "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).
> 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?
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
------------------------------------------------------------------------------
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
