On 10. 2. 2016 3:05, David Marceau wrote: > 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.
I was even ready to put up with the MS-hate, but you lost me at "taxpayers". :) It's true that Microsoft pushed (and is still pushing) pure GUI applications, but you could say the same of Xorg, KDE, GNOME, Ubuntu or whichever non-power-user-centered project you think of. As to the technical aspects, console programs are still first-class citizens in Windows. You can build a console app with stdin, stdout and stderr with MSVC, .NET, mingw-w64 or Cygwin and it will work just the way it always did. The one change for console apps users between DOS and Windows I can think of, is that in Windows, because you don't need have a console open to run a console app, Windows can open a temporary console for you. (And of course, that you can run and see more than one at a time.) I don't remember very many GUI apps that manage their own console window(s). These things are mostly limited to terminal emulators (like ConsoleZ) and special cases like the Cygwin runtime and winpty. -- David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
