Menu
▾
▴
mingw-users
|
From: waterlan <wat...@xs...> - 2012-08-06 09:57:22
|
min...@sp... schreef op 2012-08-03 19:41: > Erwin Waterlander - wat...@xs...: > >> Op 2-8-2012 21:18, Andy Koppe schreef: >> >>> Fwiw, mintty does support surrogate pairs, as does Cygwin's C >>> library. >> Well, I know that libc's wcstombs() ignores them. I converts the >> UTF-16 surrogate halves individually to UTF-8. Some programs can >> read >> the resulting UTF-8, but others, including Windows Notepad, not. >> Perhaps this is a shortcoming of notepad. I don't know if it is >> legal >> in UTF-8 to have surrogate pairs individually encoded. Anyway, I >> worked >> around it in dos2unix by using WideCharToMultiByte() instead of >> wcstombs() with mingw32 and Cygwin. On Linux I decode the surrogate >> pair myself to a single UTF-32 character, before running wcstombs(). > > It appears they're not valid UTF-8: > > http://en.wikipedia.org/wiki/UTF-8#Invalid_code_points > >> According to the UTF-8 definition (RFC 3629) the high and low >> surrogate >> halves used by UTF-16 (U+D800 through U+DFFF) are not legal Unicode >> values, and the UTF-8 encoding of them is an invalid byte sequence >> and >> thus should be treated as described above. > > And the more official... http://tools.ietf.> 3629#page-5 The > definition > of UTF-8 prohibits encoding character >> numbers between U+D800 and U+DFFF, which are reserved for use with >> the >> UTF-16 encoding form (as surrogate pairs) and do not directly >> represent >> characters. When encoding in UTF-8 from UTF-16 data, it is necessary >> to >> first decode the UTF-16 data to obtain character numbers, which are >> then encoded in UTF-8 as described above. This contrasts with CESU-8 >> [CESU-8], which is a UTF-8-like encoding that is not meant for use >> on >> the Internet. CESU-8 operates similarly to UTF-8 but encodes the >> UTF-16 >> code values (16-bit quantities) instead of the character number >> (code >> point). This leads to different results for character numbers above >> 0xFFFF; the CESU-8 encoding of th > s is NOT valid UTF-8. > > Mark. > > Thanks for the info. This means that some implementations of wcstombs() have a bug when it comes to surrogate pairs. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Andy K. <and...@gm...> - 2012-08-04 19:49:05
|
On 3 August 2012 09:13, Erwin Waterlander wrote: > Op 2-8-2012 21:18, Andy Koppe schreef: >> Fwiw, mintty does support surrogate pairs, as does Cygwin's C library. > > Well, I know that libc's wcstombs() ignores them. I converts the UTF-16 > surrogate halves individually to UTF-8. That's not true for Cygwin, which uses newlib rather than msvcrt, and where surrogate pairs are correctly converted to 4-byte UTF-8 sequences. Andy |
|
From: Erwin W. <wat...@xs...> - 2012-08-05 21:11:41
|
Op 4-8-2012 21:48, Andy Koppe schreef: > On 3 August 2012 09:13, Erwin Waterlander wrote: >> Op 2-8-2012 21:18, Andy Koppe schreef: >>> Fwiw, mintty does support surrogate pairs, as does Cygwin's C library. >> Well, I know that libc's wcstombs() ignores them. I converts the UTF-16 >> surrogate halves individually to UTF-8. > That's not true for Cygwin, which uses newlib rather than msvcrt, and > where surrogate pairs are correctly converted to 4-byte UTF-8 > sequences. > Hi, I can confirm that you are right. On Cygwin a correct 4-byte UTF-8 string is returned. On Linux (eg Suse 10) I get 6 bytes returned. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Earnie B. <ea...@us...> - 2012-08-04 20:23:16
|
On Sat, Aug 4, 2012 at 3:48 PM, Andy Koppe wrote: > On 3 August 2012 09:13, Erwin Waterlander wrote: >> Op 2-8-2012 21:18, Andy Koppe schreef: >>> Fwiw, mintty does support surrogate pairs, as does Cygwin's C library. >> >> Well, I know that libc's wcstombs() ignores them. I converts the UTF-16 >> surrogate halves individually to UTF-8. > > That's not true for Cygwin, which uses newlib rather than msvcrt, and > where surrogate pairs are correctly converted to 4-byte UTF-8 > sequences. Perhaps a wcstombs mingwex function could be added based on the newlib implementation. Newlib is mostly PD license. If someone wants to submit a patch for it I'll consider it. -- Earnie -- https://sites.google.com/site/earnieboyd |
|
From: Erwin W. <wat...@xs...> - 2012-08-05 21:18:12
|
Op 4-8-2012 22:23, Earnie Boyd schreef: > On Sat, Aug 4, 2012 at 3:48 PM, Andy Koppe wrote: >> On 3 August 2012 09:13, Erwin Waterlander wrote: >>> Op 2-8-2012 21:18, Andy Koppe schreef: >>>> Fwiw, mintty does support surrogate pairs, as does Cygwin's C library. >>> Well, I know that libc's wcstombs() ignores them. I converts the UTF-16 >>> surrogate halves individually to UTF-8. >> That's not true for Cygwin, which uses newlib rather than msvcrt, and >> where surrogate pairs are correctly converted to 4-byte UTF-8 >> sequences. > Perhaps a wcstombs mingwex function could be added based on the newlib > implementation. Newlib is mostly PD license. If someone wants to > submit a patch for it I'll consider it. > WideCharToMultiByte() is coming from msvcrt, isn't it. And this is working properly. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Eli Z. <el...@gn...> - 2012-08-06 02:40:31
|
> Date: Sun, 05 Aug 2012 23:18:05 +0200 > From: Erwin Waterlander <wat...@xs...> > > > Perhaps a wcstombs mingwex function could be added based on the newlib > > implementation. Newlib is mostly PD license. If someone wants to > > submit a patch for it I'll consider it. > > WideCharToMultiByte() is coming from msvcrt No, it doesn't. It comes from kernel32.dll. |
|
From: Erwin W. <wat...@xs...> - 2012-08-16 18:11:40
|
waterlan schreef, Op 30-7-2012 15:30: > Hi, I am willing to maintain ncurses(w) packages for mingw32, Hi, I have created mingw32 packages for ncurses (narrow chars), but while testing I noticed that newterm() doesn't work and none of the applications built with ncurses run in Console2. So at the moment I don't see any reason why one would prefer ncurses over pdcurses. My current standpoint is to not upload them to the mingw database. When there is a better ncurses I can use the package script I created to make new packages. Until then, I you must have ncurses, use the one from the ezwinports project. best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Erwin W. <wat...@xs...> - 2012-09-08 20:58:44
|
Erwin Waterlander schreef, Op 16-8-2012 20:11: > waterlan schreef, Op 30-7-2012 15:30: >> Hi, I am willing to maintain ncurses(w) packages for mingw32, > Hi, > > I have created mingw32 packages for ncurses (narrow chars), but while > testing I noticed that newterm() doesn't work and none of the > applications built with ncurses run in Console2. > > So at the moment I don't see any reason why one would prefer ncurses > over pdcurses. My current standpoint is to not upload them to the mingw > database. When there is a better ncurses I can use the package script I > created to make new packages. Until then, I you must have ncurses, use > the one from the ezwinports project. > > best regards, > For the record: I tried the test programs in ConEmu, an other alternative console for Windows. The test programs run, except the ones which use newterm(). regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Thomas D. <di...@hi...> - 2012-08-17 10:15:20
Attachments:
signature.asc
|
On Thu, Aug 16, 2012 at 08:11:29PM +0200, Erwin Waterlander wrote: > waterlan schreef, Op 30-7-2012 15:30: > > Hi, I am willing to maintain ncurses(w) packages for mingw32, > > Hi, > > I have created mingw32 packages for ncurses (narrow chars), but while > testing I noticed that newterm() doesn't work and none of the > applications built with ncurses run in Console2. If "none" work, I'd check if the TERM variable is set. The ncurses port writes to the console window only if it is not set. (Alternatively, Console2 may not support the API used by ncurses :-) ...something to investigate (will be gone a few days) -- Thomas E. Dickey <di...@in...> http://invisible-island.net ftp://invisible-island.net |
|
From: Eli Z. <el...@gn...> - 2012-08-17 10:30:41
|
> Date: Fri, 17 Aug 2012 06:15:09 -0400
> From: Thomas Dickey <di...@hi...>
>
> > I have created mingw32 packages for ncurses (narrow chars), but while
> > testing I noticed that newterm() doesn't work and none of the
> > applications built with ncurses run in Console2.
>
> If "none" work, I'd check if the TERM variable is set.
> The ncurses port writes to the console window only if it is not set.
IMHO, that's a bug. Just setting TERM to some bogus value (e.g., like
Emacs does when it runs a sub-shell) should not prevent ncurses on
Windows from using its internal terminal driver. Only if TERM is set
to something that ncurses can use should cause that variable's value
to be used.
In my port of ncurses, I made the following change to fix this:
--- ncurses/base/lib_initscr.c~0 2009-02-14 22:55:49.000000000 +0200
+++ ncurses/base/lib_initscr.c 2012-02-23 14:12:25.939059400 +0200
@@ -51,6 +51,7 @@ NCURSES_EXPORT(WINDOW *)
initscr(void)
{
WINDOW *result;
+ SCREEN *st;
NCURSES_CONST char *name;
@@ -84,7 +85,16 @@ initscr(void)
}
}
#endif
- if (newterm(name, stdout, stdin) == 0) {
+ st = newterm(name, stdout, stdin);
+#if defined(__MINGW32__) && defined(USE_TERM_DRIVER)
+ /* Don't fail too soon if someone defines $TERM to a bogus
+ value, since usually this variable is a no-op on Windows. */
+ if (st == 0) {
+ name = "unknown";
+ st = newterm(name, stdout, stdin);
+ }
+#endif
+ if (st == 0) {
fprintf(stderr, "Error opening terminal: %s.\n", name);
exit(EXIT_FAILURE);
}
--- progs/infocmp.c~0 2010-05-02 01:04:08.000000000 +0300
+++ progs/infocmp.c 2012-02-26 08:46:27.518763800 +0200
@@ -1239,10 +1239,14 @@ terminal_env(void)
char *terminal;
if ((terminal = getenv("TERM")) == 0) {
+#if defined(__MINGW32__) && defined(USE_TERM_DRIVER)
+ terminal = "unknown";
+#else
(void) fprintf(stderr,
"%s: environment variable TERM not set\n",
_nc_progname);
exit(EXIT_FAILURE);
+#endif
}
return terminal;
}
--- progs/tput.c~0 2010-01-09 18:53:24.000000000 +0200
+++ progs/tput.c 2012-02-26 08:54:09.361044000 +0200
@@ -406,6 +406,11 @@ main(int argc, char **argv)
argv += optind;
}
+#if defined(__MINGW32__) && defined(USE_TERM_DRIVER)
+ if (term == 0)
+ term = "unknown";
+#endif
+
if (term == 0 || *term == '\0')
quit(2, "No value for $TERM and no -T specified");
|
|
From: Erwin W. <wat...@xs...> - 2012-08-17 10:31:34
|
Op 17-8-2012 12:15, Thomas Dickey schreef: > On Thu, Aug 16, 2012 at 08:11:29PM +0200, Erwin Waterlander wrote: >> waterlan schreef, Op 30-7-2012 15:30: >>> Hi, I am willing to maintain ncurses(w) packages for mingw32, >> Hi, >> >> I have created mingw32 packages for ncurses (narrow chars), but while >> testing I noticed that newterm() doesn't work and none of the >> applications built with ncurses run in Console2. > If "none" work, I'd check if the TERM variable is set. TERM is not set. > The ncurses port writes to the console window only if it is not set. > (Alternatively, Console2 may not support the API used by ncurses :-) > > ...something to investigate (will be gone a few days) > > -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Roumen P. <bug...@ro...> - 2012-08-18 13:35:00
|
Erwin Waterlander wrote: > Op 17-8-2012 12:15, Thomas Dickey schreef: >> On Thu, Aug 16, 2012 at 08:11:29PM +0200, Erwin Waterlander wrote: >>> waterlan schreef, Op 30-7-2012 15:30: >>>> Hi, I am willing to maintain ncurses(w) packages for mingw32, >>> Hi, >>> >>> I have created mingw32 packages for ncurses (narrow chars), but while >>> testing I noticed that newterm() doesn't work and none of the >>> applications built with ncurses run in Console2. Demo applications like xmas and worm run fine in command.com and cmd.exe. So issue could be related to Console2. I note that if one of those demos is run in command.com screen is resized to 120 columns and in cmd it remain as is. Same demos run in Console-2.00b148-Beta_32bit shrink screen to 1 column(1) . Options like "resizable" unchecked does not work. In this mode screen size from settings is non-functional. Look like console2 does not resize properly. Also test is performed without installation of terminfo database, ncurses up to 5.9-20120811 patch "ascii" build with explicitly set --datadir. >> If "none" work, I'd check if the TERM variable is set. > TERM is not set. Same , TERM is not set. > The ncurses port writes to the console window only if it is not set. > (Alternatively, Console2 may not support the API used by ncurses :-) Once resize issue in console2 is fixed then ncurses could be tested. > ...something to investigate (will be gone a few days) Roumen |
|
From: Thomas D. <di...@hi...> - 2012-08-20 01:20:54
Attachments:
signature.asc
|
On Fri, Aug 17, 2012 at 01:30:38PM +0300, Eli Zaretskii wrote: > > Date: Fri, 17 Aug 2012 06:15:09 -0400 > > From: Thomas Dickey <di...@hi...> > > > > > I have created mingw32 packages for ncurses (narrow chars), but while > > > testing I noticed that newterm() doesn't work and none of the > > > applications built with ncurses run in Console2. > > > > If "none" work, I'd check if the TERM variable is set. > > The ncurses port writes to the console window only if it is not set. > > IMHO, that's a bug. Just setting TERM to some bogus value (e.g., like not necessarily. If I'd designed it, there'd be an explicit function. However, I didn't modify Jurgen's design in this respect because (a) it is documented, and (b) it is unambiguous. Presumably you've documented your change. However, it's not unambiguous, and for that reason I don't regard it as an improvement. :-( If this is a real problem, then the only suggestion that I have at the moment is to add a function which establishes which mode the library is running in. (For instance, pdcurses provides Xinitscr()). -- Thomas E. Dickey <di...@in...> http://invisible-island.net ftp://invisible-island.net |
|
From: Eli Z. <el...@gn...> - 2012-08-20 02:59:43
|
> Date: Sun, 19 Aug 2012 21:20:35 -0400 > From: Thomas Dickey <di...@hi...> > Cc: di...@hi..., min...@li... > > > IMHO, that's a bug. Just setting TERM to some bogus value (e.g., like > > not necessarily. If I'd designed it, there'd be an explicit function. > However, I didn't modify Jurgen's design in this respect because (a) it > is documented, and (b) it is unambiguous. > > Presumably you've documented your change. However, it's not unambiguous, and > for that reason I don't regard it as an improvement. :-( How is it not unambiguous? Also, I don't see how is it necessary to document obvious things. TERM is usually meaningless on Windows; the only people who set it and _intend_ it to be adhered to know very well what they are doing. 99.99% of users who might have it set, don't. Using that variable will only trip the vast majority -- and for what benefit? > If this is a real problem, then the only suggestion that I have at the > moment is to add a function which establishes which mode the library is > running in. (For instance, pdcurses provides Xinitscr()). I don't understand what that function would do. The issue at hand is to handle correctly the cases where some programs set TERM=dumb or some such, to make sure their subprograms don't misbehave. In the original ncurses, any program linked with the library would immediately fail in that case, which doesn't sound like a good idea. Thanks. |
|
From: Thomas D. <di...@hi...> - 2012-08-20 09:19:24
Attachments:
signature.asc
|
On Fri, Aug 17, 2012 at 01:30:38PM +0300, Eli Zaretskii wrote:
> IMHO, that's a bug. Just setting TERM to some bogus value (e.g., like
> Emacs does when it runs a sub-shell) should not prevent ncurses on
> Windows from using its internal terminal driver. Only if TERM is set
> to something that ncurses can use should cause that variable's value
> to be used.
"Only if", etc., is ambiguous. Technically (and in practice), any
string composed of printable ASCII characters excluding a few
punctuation characters (such as comma, vertical-bar) can be used
directly as a name for a terminal entry.
newterm fails when setupterm fails (that should be clearer in the manpage
for newterm). setupterm can return failure for certain valid entries in
the terminal database, if the terminal database itself is missing, and
if the given entry is not found. Your change treats all three as "other",
and happens to rely on the "gn" capability which is defined by convention
for the "unknown" entry:
unknown|unknown terminal type,
am, gn,
cols#80,
bel=^G, cr=^M, cud1=^J, ind=^J,
> In my port of ncurses, I made the following change to fix this:
>
> --- ncurses/base/lib_initscr.c~0 2009-02-14 22:55:49.000000000 +0200
> +++ ncurses/base/lib_initscr.c 2012-02-23 14:12:25.939059400 +0200
> @@ -51,6 +51,7 @@ NCURSES_EXPORT(WINDOW *)
> initscr(void)
> {
> WINDOW *result;
> + SCREEN *st;
>
> NCURSES_CONST char *name;
>
> @@ -84,7 +85,16 @@ initscr(void)
> }
> }
> #endif
> - if (newterm(name, stdout, stdin) == 0) {
> + st = newterm(name, stdout, stdin);
> +#if defined(__MINGW32__) && defined(USE_TERM_DRIVER)
> + /* Don't fail too soon if someone defines $TERM to a bogus
> + value, since usually this variable is a no-op on Windows. */
> + if (st == 0) {
> + name = "unknown";
> + st = newterm(name, stdout, stdin);
> + }
> +#endif
> + if (st == 0) {
> fprintf(stderr, "Error opening terminal: %s.\n", name);
> exit(EXIT_FAILURE);
> }
--
Thomas E. Dickey <di...@in...>
http://invisible-island.net
ftp://invisible-island.net
|
|
From: Eli Z. <el...@gn...> - 2012-08-20 16:42:04
|
> Date: Mon, 20 Aug 2012 05:19:15 -0400 > From: Thomas Dickey <di...@hi...> > Cc: di...@hi..., min...@li... > > "Only if", etc., is ambiguous. Technically (and in practice), any > string composed of printable ASCII characters excluding a few > punctuation characters (such as comma, vertical-bar) can be used > directly as a name for a terminal entry. Indeed. I relied on newterm to detect if the entry is valid or not. > newterm fails when setupterm fails (that should be clearer in the manpage > for newterm). setupterm can return failure for certain valid entries in > the terminal database, if the terminal database itself is missing, and > if the given entry is not found. Your change treats all three as "other", > and happens to rely on the "gn" capability which is defined by convention > for the "unknown" entry: > > unknown|unknown terminal type, > am, gn, > cols#80, > bel=^G, cr=^M, cud1=^J, ind=^J, Thanks, I see now what you meant. However, it looks to me that newterm should provide this information to the caller; a user of the library shouldn't need to dig too deep into the internals to understand what exactly could trip the call. IOW, it might be a good idea to have newterm return more than just a boolean value. E.g.: 1 -- found and valid; -1 -- not found; any other value -- found, but invalid. |
|
From: Thomas D. <di...@hi...> - 2012-08-21 00:36:45
Attachments:
signature.asc
|
On Mon, Aug 20, 2012 at 07:40:44PM +0300, Eli Zaretskii wrote: > However, it looks to me that newterm should provide this information > to the caller; a user of the library shouldn't need to dig too deep > into the internals to understand what exactly could trip the call. > IOW, it might be a good idea to have newterm return more than just a > boolean value. E.g.: 1 -- found and valid; -1 -- not found; any other > value -- found, but invalid. newterm's been defined for a while, and doesn't return a boolean: http://pubs.opengroup.org/onlinepubs/7908799/xcurses/newterm.html -- Thomas E. Dickey <di...@in...> http://invisible-island.net ftp://invisible-island.net |
|
From: Eli Z. <el...@gn...> - 2012-08-21 02:45:44
|
> Date: Mon, 20 Aug 2012 20:36:27 -0400 > From: Thomas Dickey <di...@hi...> > Cc: di...@hi..., min...@li... > > On Mon, Aug 20, 2012 at 07:40:44PM +0300, Eli Zaretskii wrote: > > However, it looks to me that newterm should provide this information > > to the caller; a user of the library shouldn't need to dig too deep > > into the internals to understand what exactly could trip the call. > > IOW, it might be a good idea to have newterm return more than just a > > boolean value. E.g.: 1 -- found and valid; -1 -- not found; any other > > value -- found, but invalid. > > newterm's been defined for a while, and doesn't return a boolean: > > http://pubs.opengroup.org/onlinepubs/7908799/xcurses/newterm.html For the purposes of error checking, its return value is a boolean: Upon successful completion, newterm() returns a pointer to the specified terminal. Otherwise, it returns a null pointer. |
|
From: Maximus <Con...@gm...> - 2012-09-09 00:21:43
|
Erwin Waterlander <waterlan@...> writes: > For the record: > I tried the test programs in ConEmu, an other alternative console for > Windows. The test programs run, except the ones which use newterm(). Did you mean GUI-subsystem programs, which calls AllocConsole on start? Give me example of such program, please. regards |
|
From: Thomas D. <di...@hi...> - 2012-09-09 00:28:31
Attachments:
signature.asc
|
On Sun, Sep 09, 2012 at 12:21:22AM +0000, Maximus wrote: > Erwin Waterlander <waterlan@...> writes: > > > For the record: > > I tried the test programs in ConEmu, an other alternative console for > > Windows. The test programs run, except the ones which use newterm(). > > Did you mean GUI-subsystem programs, which calls AllocConsole on start? > Give me example of such program, please. He's saying in effect that the test-programs of the ncurses port work about as well in ConEmu as in the Windows console window. (Those are known issues, for which a fix would involve changes to the programs themselves rather than to the library). -- Thomas E. Dickey <di...@in...> http://invisible-island.net ftp://invisible-island.net |
|
From: Erwin W. <wat...@xs...> - 2012-09-09 07:13:56
|
Op 9-9-2012 2:28, Thomas Dickey schreef: > On Sun, Sep 09, 2012 at 12:21:22AM +0000, Maximus wrote: >> Erwin Waterlander <waterlan@...> writes: >> >>> For the record: >>> I tried the test programs in ConEmu, an other alternative console for >>> Windows. The test programs run, except the ones which use newterm(). >> Did you mean GUI-subsystem programs, which calls AllocConsole on start? >> Give me example of such program, please. > He's saying in effect that the test-programs of the ncurses port work > about as well in ConEmu as in the Windows console window. (Those are > known issues, for which a fix would involve changes to the programs > themselves rather than to the library). Yes, it is not a ConEmu problem. I wanted to share that the ncurses test programs work better in ConEmu than in Console2. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
|
From: Thomas D. <di...@hi...> - 2012-09-09 10:47:07
Attachments:
signature.asc
|
On Sun, Sep 09, 2012 at 09:13:47AM +0200, Erwin Waterlander wrote: > Op 9-9-2012 2:28, Thomas Dickey schreef: > > On Sun, Sep 09, 2012 at 12:21:22AM +0000, Maximus wrote: > >> Erwin Waterlander <waterlan@...> writes: > >> > >>> For the record: > >>> I tried the test programs in ConEmu, an other alternative console for > >>> Windows. The test programs run, except the ones which use newterm(). > >> Did you mean GUI-subsystem programs, which calls AllocConsole on start? > >> Give me example of such program, please. > > He's saying in effect that the test-programs of the ncurses port work > > about as well in ConEmu as in the Windows console window. (Those are > > known issues, for which a fix would involve changes to the programs > > themselves rather than to the library). > > Yes, it is not a ConEmu problem. I wanted to share that the ncurses test > programs work better in ConEmu than in Console2. I'll take a look at ConEmu too, but so far have only looked closely at Console2 in addition to the Windows console. The ncurses test program "filter" is an example that might rely on the library. Along the same line, from PDCurses 3.4 history file: - newterm() works now, in a limited way -- the parameters are ignored, and only the first invocation will work (i.e., only one SCREEN can be used). -- Thomas E. Dickey <di...@in...> http://invisible-island.net ftp://invisible-island.net |
|
From: Erwin W. <wat...@xs...> - 2012-09-09 18:47:23
|
Thomas Dickey schreef, Op 9-9-2012 12:46: > On Sun, Sep 09, 2012 at 09:13:47AM +0200, Erwin Waterlander wrote: >> Op 9-9-2012 2:28, Thomas Dickey schreef: >>> On Sun, Sep 09, 2012 at 12:21:22AM +0000, Maximus wrote: >>>> Erwin Waterlander <waterlan@...> writes: >>>> >>>>> For the record: >>>>> I tried the test programs in ConEmu, an other alternative console for >>>>> Windows. The test programs run, except the ones which use newterm(). >>>> Did you mean GUI-subsystem programs, which calls AllocConsole on start? >>>> Give me example of such program, please. >>> He's saying in effect that the test-programs of the ncurses port work >>> about as well in ConEmu as in the Windows console window. (Those are >>> known issues, for which a fix would involve changes to the programs >>> themselves rather than to the library). >> Yes, it is not a ConEmu problem. I wanted to share that the ncurses test >> programs work better in ConEmu than in Console2. > I'll take a look at ConEmu too, but so far have only looked closely at > Console2 in addition to the Windows console. The ncurses test program > "filter" is an example that might rely on the library. > > Along the same line, from PDCurses 3.4 history file: > > - newterm() works now, in a limited way -- the parameters are ignored, > and only the first invocation will work (i.e., only one SCREEN can be > used). In my versions of wcd built with PDCurses, I don't use newterm() simply because it was not available in PDCurses until recently. I prefer newterm(), which I use in Unix/Cygwin builds, because with newterm I can make a fall back. Initscr exits in case of failure, newterm not. But an ncurses without newterm would be acceptable for me. My main reason for not uploading ncurses libraries for mingw is that Console2 has been downloaded by millions of people. So there is a big chance that a lot of end users will get disappointed. Or do you think it would still be useful to provide ncurses 5.9? If you want I can add the libraries, but I'm afraid it will lead to a lot of frustration among Console2 users. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
Thanks for helping keep SourceForge clean.
X