Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

win32 variant not usable without "real" sysout #50

Open
GitMensch opened this issue Jul 25, 2017 · 5 comments
Open

win32 variant not usable without "real" sysout #50

GitMensch opened this issue Jul 25, 2017 · 5 comments

Comments

@GitMensch
Copy link
Collaborator

The GnuCOBOL test suite runs some checks where the curses functions are used to display something and the return codes are checked. This works in all posix environments including cygwin with ncurses and it works with msys + win32a (there's a short popup during the test), but it did never worked with msys and pdcurses-win32.

Maybe there's something PDCurses can do to fix this issue?

This can be reproduced with the demos from command line, for example by using testcurs.exe 1>sysout.log. Other curses variants leads to sysout.log full of control characters, PDCurses stops during initscr() with an abort.

testcurs.exe 1>sysout.log
LINES value must be >= 2 and <= 64: got -1685
initscr(): Unable to create SP

testcurs.exe 1>sysout.log
LINES value must be >= 2 and <= 20: got 2572
initscr(): Unable to create SP

The error message comes from https://github.com/Bill-Gray/PDCurses/blob/master/win32/pdcscrn.c#L413:

    if (SP->lines < 2 || SP->lines > csbi.dwMaximumWindowSize.Y)
    {
        fprintf(stderr, "LINES value must be >= 2 and <= %d: got %d\n",
                csbi.dwMaximumWindowSize.Y, SP->lines);

        return ERR;
    }

The number for "got" is different on each run. I did expected csbi.dwMaximumWindowSize.Y to be identical for each run, but obviously this changes, too.

Any ideas how to fix that? I haven't checked yet what NCurses does here but it would be nice to be able to change sysout from stdout to a file or a different channel (the may gets displayed from there afterwards) with PDCurses win32, too.

@Bill-Gray
Copy link
Owner

Bill-Gray commented Jul 26, 2017

I got the same error message in Wineconsole the first time I ran testcurs 1>sysout.log. After that, it worked, which is making it harder for me to puzzle this out.

With the warning that I've not done much with Win32 console mode, so this may be all wrong: PDC_get_rows does a call to GetConsoleScreenBufferInfo for the standard output. Redirecting stdout means it's not a console anymore. The return value from that function is ignored; it probably shouldn't be, because on failure, I think it returns garbage. If the garbage fell in the right range, we'd keep on going happily.

However, when I added a check to give an error if GetConsoleScreenBufferInfo returned zero, I didn't get an error. So I'm currently stumped (though of course, it could be that error will indeed turn up over the course of the next few days of testing.)

@GitMensch
Copy link
Collaborator Author

Thank you for investigating. I try to check what ncurses returns under cygwin for LINES/COLS when run in a file.

@rhaberkorn
Copy link

I get the error "Redirection is not supported." when running PDCursesMod/Wincon apps in the MSYS console while other MinGW apps like "nano" appear to run fine. Could this possibly be related?

@Bill-Gray
Copy link
Owner

Y'know, I feel rather silly that I didn't ask about this 4.5 years ago when this first cropped up : does the same error happen when using 'mainline' PDCurses?

If it doesn't, that'd be one heck of a major clue. The differences between PDCurses and PDCursesMod on the Windows console are quite minor.

Probably, the same error will occur in PDCurses. (In which case, any fix we find may (or may not) be of interest to @wmcbrine.) But if we're lucky and it's specific to this fork, the code to dig through becomes much less.

@wmcbrine
Copy link
Contributor

It has always worked (or, not worked) that way. It needs a real Windows Console (and the need runs deep, and you're not going to find a simple "fix" for it). I mean... it's not a bug, to begin with. Just, perhaps, a mismatch of expectations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants