> 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. 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 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 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?". > Ncurses isn't really a regular visitor on Windows, is it? > 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. "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. > 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. 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'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)? > 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. > 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? 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. -------------- 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. 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". 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. "Windows .NET apps", to our understanding, are totally separate from MSYS2. -------------- 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 Thanks, 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
