On Sun, 3 Mar 2002, I wrote: [Under DJGPP,] PDCurses is calling usleep() with a 10ms parameter, so there's no pause. I haven't attempted to fix this yet. I changed the 10 in waitingtenths = 10*SP-delaytenths to 2, and changed the napms() parameter from 10 to 50, and indeed it works correctly now. I'm not sure if that should be applied as is, since it would affect all ports. And I haven't yet figured out why the Turbo C++ routine (based on delay() from TC's dos.h) isn't working. Still no luck there... anyone else? -- William McBrine [EMAIL PROTECTED]
On Mon, 22 Jul 2002, Jeremy Smith wrote: *If I link with the .lib, this is GPL'ed, and I assume I have to release the source as I am effectively 'compiling in' PDCurses PDCurses is NOT GPL'ed, nor LGPL'd. Most of it is public domain -- hence the name. The license of some portions, like the Win32 section, seems to be more restrictive, but it's still not GPL. Specifically, it says this: * This file comprises part of PDCurses. PDCurses is Public Domain software. * You may use this code for whatever purposes you desire. This software * is provided AS IS with NO WARRANTY whatsoever. * Should this software be used in another application, an acknowledgement * that PDCurses code is used would be appreciated, but is not mandatory. * * Any changes which you make to this software which may improve or enhance * it, should be forwarded to the current maintainer for the benefit of * other users. * * The only restriction placed on this code is that no distribution of * modified PDCurses code be made under the PDCurses name, by anyone * other than the current maintainer. * * See the file maintain.er for details of the current maintainer. I think that's pretty straightforward -- although of questionable validity, since first it states that it's public domain, and then it attempts to place restrictions on use. Anyway, it says that you can link and distribute your binaries as you please, with or without source. But if you were a good person, you'd want to release your code anyway. ;-) -- William McBrine [EMAIL PROTECTED]
In recent versions of Borland C++, the name of the linker has changed to ilink32. More importantly, the makefile mistakenly lists pdcclip.c as being in srcdir rather than osdir. Here are the patches. -- William McBrine [EMAIL PROTECTED] *** win32/bccwin32.old 2005-05-26 20:03:57.963471800 -0400 --- win32/bccwin32.mak 2005-05-26 20:05:19.678049296 -0400 *** *** 48,54 CCFLAGS = -c -Tpe -w32 $(CFLAGS) $(CPPFLAGS) ! LINK = tlink32 CCLIBS =$(CCLIBDIR)\bidsf.lib+$(CCLIBDIR)\import32.lib+$(CCLIBDIR)\cw32.lib STARTUP =$(CCLIBDIR)\c0x32.obj --- 48,54 CCFLAGS = -c -Tpe -w32 $(CFLAGS) $(CPPFLAGS) ! LINK = ilink32 CCLIBS =$(CCLIBDIR)\bidsf.lib+$(CCLIBDIR)\import32.lib+$(CCLIBDIR)\cw32.lib STARTUP =$(CCLIBDIR)\c0x32.obj *** *** 246,253 $(CC) $(CCFLAGS) -o$@ $(srcdir)\window.c ! pdcclip.obj: $(srcdir)\pdcclip.c $(PDCURSES_HEADERS) ! $(CC) $(CCFLAGS) -o$@ $(srcdir)\pdcclip.c pdcdebug.obj: $(srcdir)\pdcdebug.c $(PDCURSES_HEADERS) $(CC) $(CCFLAGS) -o$@ $(srcdir)\pdcdebug.c --- 246,253 $(CC) $(CCFLAGS) -o$@ $(srcdir)\window.c ! pdcclip.obj: $(osdir)\pdcclip.c $(PDCURSES_HEADERS) ! $(CC) $(CCFLAGS) -o$@ $(osdir)\pdcclip.c pdcdebug.obj: $(srcdir)\pdcdebug.c $(PDCURSES_HEADERS) $(CC) $(CCFLAGS) -o$@ $(srcdir)\pdcdebug.c
On Thu, 19 Jan 2006, I wrote: There isn't really any specific support for the Amiga in PDCurses. I'm not sure why it was listed in the README in 2.5 and 2.6 (I've asked Mark), OK, Mark found an Amiga port from the 2.4 era. I've put it up in the 2.4 section on SourceForge (amiga-port.tar.gz). It seems very incomplete. I haven't tested it, and I can't read the .info files yet (gotta set up UAE again, I guess). Presumably you'd extract the original 2.4 archive first, then this on top of it. -- William McBrine [EMAIL PROTECTED]
On Tue, 16 May 2006, Zbigniew Baniewski wrote: How should I understand such native X11 application? Is it an application, which doesn't need any XTerm (terminal window) anymore? Yes. If so - perhaps someone could point some screenshots, how such applications prepared using PDCurses will look like? It doesn't really look any different. You can alter the appearance by specifying the font, colors, etc. But it still looks pretty much like an xterm window. -- William McBrine [EMAIL PROTECTED]
On Fri, 23 Feb 2007, Gareth Brown wrote: I've been racking my head for hours trying to compile PDCurses programs on my Mac OS X installation, and Linux. I'm in a dire need of help. What I'm trying todo is compile the demos included separately using the following; $ gcc firework.c -lpdcurses -o firework and get the following error; /usr/bin/ld: can't locate file for: -lpdcurses collect2: ld returned 1 exit status The -l option tells gcc, take the following name, munge it in a system- specific way, and search the library path for the name. In Linux, it will prefix the name with lib, and suffix it with .so or .a; in other words, it will look for the files libpdcurses.so and libpdcurses.a. In Mac OS X, the suffix for shared libraries is .dylib instead of .so. So, have you got one of those files in your library path? Probably not. For one thing, the X11 version of PDCurses (which is what you have in Linux or Mac OS X), for historic reasons, is built with the name XCurses by default. The corresponding option would thus be -lXCurses rather than -lpdcurses. You could change it to pdcurses; but if you had, you'd know it. Secondly, you don't have it in your library path unless you've installed it there. That would mean you either ran make install (or perhaps sudo make install), with no errors, or else manually copied it to an appropriate place. Now, make install doesn't work correctly in Mac OS X, because make sees the file INSTALL and thinks it satisfies the rule. This only happens in Mac OS X (and not Linux or other *nix), because of its case-preserving but non-case-sensistive file system. (Fixed in PDCurses CVS. You can fix it by adding a second colon after install: in the Makefile.) You can also specify the full pathname to the library file directly. In that case, you don't use -l. Example -- if it's installed: gcc -ofirework firework.c -lXCurses If it's not installed: gcc -ofirework firework.c ../pdcurses/libXCurses.a I'm completely stuck, should I put a file in /usr/bin/ld ? /usr/bin/ld is the name of the linker executable, not a directory. -- William McBrine [EMAIL PROTECTED]
PDCurses 3.0 is up on SourceForge now. For the time being, only the source code archives are there, because I want to encourage people to build it themselves; binaries will be posted eventually. There are a lot more things I wanted to do with this release, but it's been long enough, and there are important changes that I want to get out there. (I did meet my _original_ goals for it, before I kept adding to the list...) I don't think there are any showstoppers left, but please let me know if you find any. There WILL be incompatibilities with some existing code, due to the magnitude of the changes. The focuses for this release are X/Open conformance, i18n, better color support, cleaner code, and more consistency across platforms. -- William McBrine [EMAIL PROTECTED]
In Windows, there are two separate 8-bit character sets: one for GUI apps, which Microsoft calls the ANSI code page; and one for the console, known as the OEM code page. (On a typical U.S. system, these would be Windows- 1252 (a superset of ISO-8859-1) and IBM Code Page 437, respectively.) In adding wide-character support to PDCurses, I made the existing char string functions, like addstr(), into wrappers for their wide-char counterparts, like addwstr(). They convert between Unicode and the current 8-bit character set via the standard library functions mbtowc(), mbstowcs(), and wcstombs(). And I still think that was the right thing to do -- but only later did I realize that, for Windows, I didn't know whether these functions would use the ANSI or OEM code pages. As it turns out, different compilers have implemented it in different ways. MSVC and MinGW use the ANSI page; Borland and Watcom use the OEM. I'm not sure there's anything to fix here, since neither behavior is incorrect per se, and either might be desired; but it's something to be aware of. Note that this only applies to the library built with wide-character support, but without forced UTF-8 mode. The narrow-character build uses the OEM code page, as always; in this case, the char string functions are not wrappers, and the wide-char versions are not available. -- William McBrine [EMAIL PROTECTED]
PDCurses 3.2 is on SourceForge now: http://pdcurses.sf.net/ This release mainly covers changes to the build process, along with a few structural changes and documentation updates. Nothing in this version is an actual bug fix. But there are several large changes that I wanted to get out there -- some because people will want them, some to get out of the way before moving on to anything else. And no, I'm not really planning to do a release every month from now on. -- William McBrine [EMAIL PROTECTED]
Now in CVS: a port of PDCurses that uses SDL as the backend. This is essentially complete, but could use more testing. Works great on Linux and Windows; crashes mysteriously on Mac. (If anyone can fix that, please let me know.) It's the first port to support _both_ kinds of resizing, as well as the *LINE attributes, previously only available in X11. Special features: The font or icon can be changed by adding a BMP file named pdcfont.bmp or pdcicon.bmp in the starting directory. (The font file should be 1-bit, with the characters arranged in 8 lines of 32 characters each.) If the files don't exist, internal fallbacks are used. Also, to an extent, you can mix SDL and PDCurses code. Pointers to the SDL surfaces pdc_screen, pdc_font, and pdc_icon are exposed. (This is subject to change.) Any of them can be set before calling initscr(); or the pdc_screen created by PDCurses can be used with SDL functions after initscr(). Limitations: No wide-character support; the output character set is code page 437, and the input is restricted to ASCII (plus the special keys) for now. Of course, you can change the output character set by changing pdcfont.bmp, but the acs_map expects CP 437. The directory is labelled sdl1 because I'm tentatively planning for a more advanced SDL port in the future, to support Unicode and TTF, but I expect this one to remain useful, because it's fast, and doesn't depend on anything beyond basic SDL. Currently only set up for an sdl-config based build (Makefile) for Unix, or MinGW (Makefile.mng) for Windows. (The build system is the main thing that needs work before it's released.) -- William McBrine [EMAIL PROTECTED]
On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote: Is there a pre-compiled library for Windows that will allow me to statically link to pdcurses Why not compile it yourself? The default is to build a static library. -- William McBrine [EMAIL PROTECTED]
Pre-compiled Win32 DLLs are posted now. -- William McBrine [EMAIL PROTECTED]
On Mon, 23 Feb 2009, Karl Garrison wrote: I have encountered a problem with the wmove() function under PDCurses 3.4 - it appears to not change the cursor position at all, as far as I can tell. It works fine. The problem in your test program is that after every wmove(), you're doing a getch(), which does an implicit refresh on stdscr (since getch() == wgetch(stdscr)), which moves the cursor back to the position it had in stdscr. If you replaced these with wgetch(win), it would work as you expect. The behavior is slightly different from ncurses, but it's not an error. In recent versions of PDCurses, wgetch() places the cursor at its current position in the window, since that's where the input text will appear. ncurses doesn't actually move the cursor until it starts outputting the text. -- William McBrine wmcbr...@gmail.com
On Sun, 21 Jun 2009, Nik Nyby wrote: I'm trying to port an ncurses application to Windows. I've gotten it to compile successfully with MinGW, but I'm getting this PDCurses error in stderr.txt whenever I run the program: LINES value must be = 2 and = 15496: got -879 initscr(): Unable to create SP It seems to me that, when I've seen that kind of error before, it was due to someone trying to use a Win32 console build in a non-console terminal, like xterm. However, the mention of stderr.txt suggests that you're using an SDL build. So, I don't know. Anyone else? -- William McBrine wmcbr...@gmail.com
On Mon, May 7, 2012 at 2:45 PM, Bill J Gray pl...@projectpluto.com wrote: Is there any particular character encoding associated with PDCurses? No. In the case you're talking about, the input comes from ReadConsoleInput(). It's Windows itself that determines the active console code page. (The tables in win32/pdckbd.c are all just for things like ALT and function keys.) You could set it to a so-called ANSI page if you wanted. The exception is if you're using the WIDE build. In that case, you always get Unicode. That's actually what I'd recommend.
Sorry for the delay. I finally got around to looking at Frank Palazzolo's CVS to git conversion and was satisfied with it, so I forked it on GitHub, and cloned it to SourceForge. The old CVS repository is now gone. Further changes will be pushed to both SourceForge and GitHub.
PDCurses 3.5 is now available: http://pdcurses.org/ Catching up on many of the changes of the last (ahem) ten years... hopefully without breaking too much (I'm saving that for later). Source only, no binaries yet.
PDCurses 3.6 is now available: http://pdcurses.org/ 256 colors in the Windows console, real blinking and fixed up attributes everywhere, fixed X11 install, more. Source only, no binaries yet. SourceForge has been down all day, so it doesn't have 3.6, and links to it are temporarily disabled -- you'll have to use the GitHub links.
On Sat, Mar 24, 2018 at 3:09 PM, Karl Garrison
wrote: > Also, I don't see this in the docs anywhere, but it took me a bit to realize > that the BMP needed to be 1 BPP. ... I suggest adding a note to the > documentation about the BMP depth requirement Ahem... "The font is a simple BMP, 32 characters wide by 8 characters tall, preferably with a palette. (BMPs without palettes still work, but in that case, no attributes will be available, nor will the cursor work.) The first entry in the palette (usually black) is treated as the background color; the last entry (usually white) is treated as the foreground. These are changed or made transparent as appropriate; any other colors in the palette are passed through unchanged. So -- although a one-bit depth is sufficient for a normal font -- you could redraw some characters as multi-colored tiles." That's from doc/sdl.md (combined into PDCurses.md, if you build that). It's been there since 2007.
PDCurses 3.7 is now available: https://pdcurses.org/ Lots of SDL2 fixes, compatibility with stdbool.h, various fixes including wincon resizing, general code and doc reorganization and cleanup.
PDCurses 3.8 is now available: https://pdcurses.org/ SDL fixes, DLL fixes, run-time version info, documented a lot of undocumented functions, etc.