gh-85796: Build the curses module on Windows against PDCurses - #154956
serhiy-storchaka wants to merge 3 commits into
Conversation
The curses and _curses_panel modules are built when PDCURSES_DIR points to a PDCursesMod source tree, linking it as a shared library so both modules share one screen and panel stack. PDCurses has no terminfo database, so PC/pdcurses supplies the entry points the module needs. curses.pdcurses_version reports the library version, as ncurses_version already does. What PDCurses provides is declared in one block, in the same HAVE_CURSES_* terms that configure defines on Unix. window.encoding follows the program locale, or is UTF-8 where PDCurses is built to force it. A cell holds a character on a wide build and a locale byte on a narrow one, whichever library provides it. test_curses covers the differences: PDCurses has its own color model, supports one screen per process, and reports some errors differently. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentation build overview
397 files changed ·
|
…rses # Conflicts: # Lib/test/test_curses.py # Modules/clinic/_cursesmodule.c.h
PDCursesMod's setcchar() reads uninitialized memory for an empty string (PDCursesMod issue python#388), so build a cell without text directly. Its winnstr() reads at most 512 bytes, and a NUL is written in its ^@ form.
|
Hum. Adding a new dependency to Python on Windows sounds like a non-trivial change. It would be worth it to open a discussion at discuss.python.org in the Core dev category to discuss it. I don't expect that many people care about suporting curses on Windows, but it would be nice to get some feedback from users, and discuss the choice of PDCursesMod. |
|
There are some changes required for the Windows build, but I think those can wait until after we're sure we want to be doing this (e.g. conditions in |
3 participants
Point
PDCURSES_DIRat a PDCursesMod checkout andbuild.batcompilespdcurses.dll,_curses.pydand_curses_panel.pyd; without it nothing changes, and the installer does not ship them yet. The library is built wide, with a 64-bitchtype, and both modules link the one DLL, so they share a screen and a panel stack.PDCurses has no terminfo database, so
PC/pdcursessupplies<term.h>and the entry points the module references unconditionally:setupterm()reports success, the capability queries report "not found". What PDCurses does provide is declared in one block, in the sameHAVE_CURSES_*terms that configure defines on Unix, since configure does not run here.curses.pdcurses_versionreports the library version, asncurses_versiondoes, andwindow.encodingfollows the program locale, or is UTF-8 where PDCurses forces it.curses.termattrs()now returns its mask through anunsigned long long, asterm_attrs()does, since a 64-bitchtypereaches past the 32 bits of anunsigned longon Windows.test_cursescovers the differences rather than skipping them: PDCurses has its own color model, keeps one screen per process, and reports some errors differently.$TERMno longer gates it there, since PDCurses does not consult it.Tested on Windows 11, and against PDCursesMod 4.5.4 on Linux and FreeBSD in five configurations — wide and narrow, 32- and 64-bit
chtype, forced UTF-8 — in three locales each.test_cursespasses in all of them but the wide builds on FreeBSD in an 8-bit locale, wherewchar_tholds the raw locale value rather than a code point and the round-trip throughwcstombs()fails; the system ncurses fails the same tests there.