On 02/18/2016 05:38 PM, Daniel Goldman wrote: > Thank you for citing the lines and function calls. I was not aware that > those win32 api calls were used in the ncurses library. > > SetConsoleTextAttribute and GetConsoleScreenBufferInfo (and some others > I see now) are all "console functions", related to the windows console. > A curses program runs within a windows console, so in retrospect it > makes perfect sense. > > Back to the original assertion, that 'non-Cygwin ncurses programs were > supposed to belong into the group of "regular Windows programs"', that a > windows curses app (eg, mc or vim) running within a console window is > basically the same as a win32 api program, I still disagree with that. I should clarify. Anything running within the windows desktop is running through win16/win32/win64, but that does not necessarily mean it is behaving as a "regular windows program". A regular windows program does not usually require the use the console api. mc or vim would require the use of the console api therefore fall under the umbrella of a console app definition. If a great percentage of the app run-time is spent under console api rather than non console api, that would also fall under the realm of a console app.
> First, of course "regular windows programs" (not my phrase) is ill > defined. Regular windows behaviour standards started appearing within IBM's CUA(common user access) guidelines and realized with ms-dos text-consoles as text-character rectangle frames/panes. You could see microsoft's programmer's workbench and borland's turbo-c turbo-pascal using these CUA notions: standard menu placement at the top left, standard key combinations for standard activities(tab, alt key and letter combos, space/enter bringing you to the next dialog), modal and modeless dialogs. Because it looked quirky made with characters and all to denote the different areas on the text-character based screen, it was a real stretch to call those thingys "windows". The notion of inter-application communication within earlier windows versions were immature and evolving. DDE, OLE, COM, DCOM, ACTIVEX, .NET. None of these were available from DOS or DOS-PROMPTS in earlier releases of windows so... ******** So the general rule of thumb ******** Anything made with text characters or displaying text characters is defined a regular windows program. It is a console program. Anything that doesn't have a CUA style menu and looks like a console shell is a console shell and not a regular windows app. Anything that can't be automated via DDE, OLE, COM, DCOM, ACTIVEX and now .NET is probably a console program at heart also. In more recent versions of windows, you may automate stuff from console shell<<-->>window/officeapp using COM/DCOM/.NET, but the console shell itself quite clear it is not a regular windows app as stated for the reasons above from its legacy constraints placed upon it. The further complicate matters powershell is another kind of shell which may be automated upon and automate anything .NET as if it were VB/VC#. To re-enforce this notion, MS SDK and compiler have special switches for console apps versus regular windows apps. -m console versus -m windows if I recall correctly. That should help to clearly distinguish between windows apps and console apps. The DOS PROMPT/COMMAND SHELL/COMMAND PROMPT embedded within the windows desktop through the win16/win32/win64 api is an exception and does not have any gui controls as are normally displayed within a window area. It may have access to all the api that regular windows apps have, but certainly does have a well-defined behaviour which is very different from non-command-prompt "regular windows apps". I do hope this clarifies the boundaries as to what a "regular console app" versus a "regular windows app" are. Yes of course there are possibilities to build apps that overlap both of these capabilities, but they are the exception and not the norm in Windows land. Even so, the fact that the ncurses library uses win32 api > function calls to communicate with the windows console does not change > the reality that curses programs do not have WinMain, do not use a > message loop, and many other fundamental differences. curses programs > running under windows are limited to running in a windows console. It > seems a broad over-generalization and not useful in practice to lump > together curses apps (eg, mc) and win32 api apps (eg, microsoft word). > > Again, thanks for clearing up the question on those source files. I > learned something. > > Daniel > > On 2/18/2016 12:08 AM, Fabrice Popineau wrote: >> >> >> 2016-02-18 6:55 GMT+01:00 Daniel Goldman <[email protected] >> <mailto:[email protected]>>: >> >> >> I cannot go through these files line by line to prove that each line >> does not "use the win32 api". In contrast, all you need to do is cite a >> few lines that "use the win32 api", and I would be happy to reconsider. >> >> >> In win_driver.c, you get a bunch of GetConsoleXXXX and SetConsoleXXXX calls. >> Look for example at the wcon_setcolor() function : >> >> static void >> wcon_setcolor(TERMINAL_CONTROL_BLOCK * TCB, >> int fore, >> int color, >> int (*outc) (SCREEN *, int) GCC_UNUSED) >> { >> if (okConsoleHandle(TCB)) { >> WORD a = MapColor(fore, color); >> a |= (WORD) ((CON.SBI.wAttributes) & (fore ? 0xfff8 : 0xff8f)); >> SetConsoleTextAttribute(CON.hdl, a); >> get_SBI(); >> } >> } >> >> SetConsoleTextAttribute() is Win32 API. >> >> Fabrice >> > > ------------------------------------------------------------------------------ > 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
