David,
Thanks very much for the reply and the explanation of the differences. I
did have a few points.
> Non-graphical Cygwin (generally POSIX) and regular
> Windows programs use fundamentally different ways
> to display output and receive input.
It's unclear to me what you mean by "regular Windows programs". It seems
a vague term (and I am a windows programmer). To me, a "regular Windows
program" is a GUI program, like firefox under windows, Excel under
windows, etc. Is that what you are referring to? BTW, what's an
"irregular windows program"?
I was specifically referring to curses programs. I stated that clearly.
So I don't understand your sole mention of vague "regular windows
programs", no mention of specific "curses program".
> It provides pty's and other POSIXy stuff to programs and
> it draws the result "manually". Cygwin programs "just know"
> how to use it and usually have no problems with it.
I would suggest that the explanation is lacking, especially in saying
that cygwin programs "just know" something. Programs don't know
anything, except in a metaphorical sense. "just know" seems a lazy
explanation at best.
I accept that cygwin programs run under mintty. But a real explanation
would mention a specific API or other specific technical means. I am not
asking for that explanation, just pointing out "just knows" is no
explanation. I would delete the bit about "just know", or say something
like "cygwin curses programs, such as A, B, and C, run under mintty
because _________". That would also require knowing which cygwin
programs are compiled with curses, and which version, that would be
specific, helpful information.
> The Windows terminal (console, conhost) does the same
> for regular Windows programs. It provides the back-end
> to Windows console handles and regular Windows
> programs "just know" how to use it.
Again, the use of the term "regular windows programs" is ambiguous and
ill-defined, as I explained above. Again, my questions are related to
curses programs. Again, programs don't "just know" anything, that's
either a misunderstanding or an unhelpful use of a metaphor where a more
technical explanation is required.
>> 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.
> /usr/bin/mc.exe? On my system, this one runs perfectly
> in mintty, but is horribly broken in a regular Windows terminal.
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.
I again ran /usr/bin/mc.exe again in a regular windows terminal, windows
7 home premium. It is not "horribly broken", as you say, it works
perfectly, I was able to navigate, switch with ^O, do everything I do
when using mc under mintty. I sent screenshots to David (exceeded size
limit for posting to list), before (1) and after (2) running
/usr/bin/mc.exe in command window.
***************************************************
Assuming this is replicated by someone else, which could easily be
tested, this discrepancy ("works perfectly" vs "totally broken") 100%
makes my point that there is confusion about these different interfaces,
what works where, and why the differences.
***************************************************
> This solves a lot of the issues when running regular
> Windows programs in a Cygwin terminal.
Again, I think it would be best to avoid the perhaps vague term "regular
windows programs", and be more specific, especially since my question
specifically related to programs compiled under curses.
> Cygwin allows some inter-operation between a Cygwin
> program and Windows console and between a Windows program
> and Cygwin terminal emulators. You can run bash in a Windows
> terminal and also run cmd in mintty. For basic stuff, it
> works fine. Anything more complicated, like colored text,
> TUIs and line editing, breaks.
I'm sorry, but that was totally not my experience, as I clearly stated.
The curses program (a TUI) works perfectly, that was the point of my
post, so I don't understand why you say "Anything more complicated ...
breaks". I sent a snapshot to David (3) (exceeding size limit for
posting to list).
Please don't take my comments the wrong way. I appreciate your response
and that you are trying to make sense of the confusing situation. I
admit I am confused. I just think you are also confused. The worst thing
one can do is act like we know something, when we don't. It is better to
say nothing than place incorrect / misleading / unhelpful information in
an "introduction". For the reasons I've stated above, I don't find the
current "explanation" in the introduction very helpful. Instead of
suggesting that the situation is understood, it might be better to say
"This is a subject of some current confusion. Our current knowledge is
as follows: blah, blah, blah. If you can help with better information
concerning X, Y, and Z, please __________".
I wish there was someone else on the list with more specific knowledge
about how curses programs (pdcurses and ncurses) should be compiled to
work best in the different MSYS2 environments, for both running and
debugging. I'm here to report what I observe, offer my technical
expertise when possible, and to learn. Again, thanks to Greg Jung. I
hope my observations help clear up at least some of the confusion.
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
