OLD UNIX terminals had standard output, standard input, standard
auxiliary and standard error. Every application had these, but it was
to the programmer's discretion whether to fully exploit these file
handles or not.
When MS-Dos was starting out, these 4 file handles were called exactly
the same: standard output, standard input, standard auxiliary, and
standard error.
MS Windows arrived on the scene and the concept of standard input and
standard output wasn't really the recommended way of building windows
applications. MS was recommending ditching these 4 standard file
handles althout inherent to every DOS and WINDOWS app by default, The
recommended way was to open other files through the common dialog apis
for reading/writing that way. The standard error file handle was
replaced with gui dialog messages or windows debug log messages(not
stderr, but windbg found in the 1st,2nd,3rd+ gen windows platform
sdk's(win16,win32,win64+).
As a result of all this GUI favortism, MS seemed to have detached the
console and its associated 4 file handles by providing these console
handles in a separate console api, but from what I understand they
always were part of each app from the very beginning, just very well
encapsulated(hidden). In Unix/Linux/Msys2 land, it has always remained
fashionable to have a terminal to read standard input from and to dump
standard output and standard error to if we wanted it. I am not up to
date with windows apis, but I am certain console file handles are still
available from .net apis.
The common things for a windows app to use console is to create the app
window, then create a console, then attach the windows app to the
console, then send stuff to the console. It's actually very funny
because they used to be part of the app for free from the beginning, but
then MS took this functionality away. Think "embrace, extend,
extinguish" here and you'll figure out what's going on. They took away
the functionality; they weren't aiming for interoperability; they
weren't aiming for compatibility; they were aiming for programmer API
vendor lock-in. The sooner everyone realizes that the sooner everyone
will run away from Microsoft like it was some fatal contagious airborne
virus. Nothing has changed. .Net has the same aspirations to
extinguish NON-MICROSOFT-based languages/operating-systems somehow.
It is not in the public taxpayers interest to continue to use
proprietary software because taxpayers can't see what's happening under
the hood and can't learn/participate in maintaining what's under the
hood. There is no world-synergy occurring from proprietary
software/vendor-lockin. The real synergy is happening in NON-MICROSOFT
operating systems and tools. Msys2 using pacman points to people using
ArchLinux which rocks my world now. Hats off to the
MSYS2/PACMAN/ArchLinux team for existing. MSYS2 is my shell of choice
when forced to do stuff on a windows box.
On 02/09/2016 06:59 PM, Daniel Goldman wrote:
> 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
>
------------------------------------------------------------------------------
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
