lmemsm | Entries tagged with pdcurses

I'm investigating ncurses/pdcurses and various other implementations of the curses library. Since there are several, I thought it would be useful to start a list to keep track of them all.

ncurses
https://invisible-island.net/ncurses/
ncurses is typically the mostly widely used variant of curses.

PDCurses
https://github.com/wmcbrine/PDCurses
PDCcurses has been used for a long time on DOS and Windows machines. ncurses did not originally have a Windows port and still does not include a DOS port. So PDCurses is used in that situation. PDCurses added a simple X11 backend which works with older versions of X and later SDL 1 and 2 backends so that it will work anywhere SDL does. That makes it useable with mobile devices or Webassembly.

PDCursesMod
https://www.projectpluto.com/win32a.htm
https://github.com/Bill-Gray/PDCursesMod
PDCursesMod is a fork of PDCurses that adds a Win32 backend. The original PDCurses only supported console mode in Windows.

NetBSD-libcurses
https://github.com/sabotage-linux/netbsd-curses
NetBSD had it's own version of curses. The version used by Sabotage Linux and some other lightweight Linux distributions is based on the NetBSD version but ported to work on Linux.

TinyCurses
https://github.com/tommyettinger/TinyCurses
TinyCurses is a subset of curses that uses SDL 1.2 for rendering.

incurses
https://github.com/infinnovation-dev/incurses
A minimal implementation of curses for embedded systems.

mcurses.h
https://github.com/yui0/slibs/blob/master/mcurses.h
An implementation of curses as a single header library. It uses termios.

I've been using SDL for a long while now. The newest version of SDL 3 will require migrating from SDL 2 versions. Like the switch from 1.2.15 to 2, it will once again break backward compatibility. It will remove support for several older platforms and change the API. The good news is that SDL 3 will have a compatibility layer much sooner than SDL 2 did. I'm still patching some of the SDL 1.2.15 programs I use so that they'll work with either SDL 2 or SDL 1.2.15. In my experiences with it so far, patching seems to work better than using the compatibility layer for SDL 1.2 support. SDL 3 will make more use of the GPU and modern graphics libraries and drivers. From what I've read, it'll introduce a new, portable shader language. So, you may now need more than just a C compiler to write programs. I prefer working with a minimal number of languages and compilers and am not looking forward to some of the new changes SDL 3 may bring. This leaves me wondering if I should seek another graphics/GUI library for more of my development.

I've looked into GUIs, TUIs and graphics libraries in the past and I really wasn't thrilled with most of the options out there. Besides SDL, Raylib seems very promising. It doesn't have the variety of FLOSS applications SDL seems to though. Using OpenGL directly can be just as problematic as SDL because its API keeps changing as well. So, GLFW may not be a great strategy either if the OpenGL compatibility it makes accessible has a changing API. Nano-X seems fairly stable and works on a variety of operating systems. Allegro is often used for applications similar to those created by SDL. However, differences between the versions it supports and what platforms those versions offer is also noticeable. I often use pdcurses with an SDL backend, but pdcursesmod works very well on Windows using Win32 and can also support console mode in Windows and BSD-curses and ncurses offers some benefits over pdcurses on POSIX systems. So, while I've found pdcurses built with SDL highly portable and useful (I even added SDL 2 and SDL2_ttf support), programs that build with pdcurses should port easily to other libraries that don't require SDL.

There are some platforms that only work with SDL 1.2.x and are not supported by later versions of SDL. The same will most likely be true for SDL 2 compared to the latest version of SDL 3. I'm wondering if I should keep using and patching the current SDL 2 and 1.2.15 libraries I've been working with or just make the switch to a new library. I'm also wondering if other developers are in the same situation, trying to determine whether to continue with what they have or port what they can to yet another graphics library or a later version of SDL. If there's interest from other developers in continuing to use older versions of SDL because of platforms they supported or portability issues, it would be nice to collaborate in continuing to maintain these libraries. It's easier to find security issues and bugs when there are a group of users rather than just one programmer using it.

I am currently working on backporting the latest SDL 2 helper libraries so that as many as possible work with SDL 1.2.15. That way SDL 1.2.15 can make use of newer features like loading and rendering SVG images, better utf-8 support, etc. I have a patched version of SDL2_ttf that adds functionality needed for sdl_unifontview to work properly. I've also been adding an alternative build system that doesn't require GNU autotools or cmake. It instead uses CDetect and make.

As one of the earlier contributors to MinGW, I use the original MinGW port to Windows and try to avoid the hostile fork of MinGW whenever possible. Unfortunately, many libraries do not maintain compatibility with the original MinGW compiler. The newer the libraries are, the less compatible they typically are. So, while SDL 1.2.15 is no problem to build with MinGW. SDL 2.26.5 is a nightmare. I'm currently looking into some issues related to building it with the original MinGW now. I maintain my own version of w32api based on the last public domain release and have been trying to add enough functionality to it to compile many of the more modern standard FLOSS libraries. I also built SDL 2 on AIX at one point to experiment with running SDL applications on AIX via X-forwarding. So, I have patches for that as well.

I've started a thread on Mastodon:
https://fosstodon.org/@lmemsm/110413981373101611
Would be very interested to hear how others are dealing with the SDL upgrade path and whether they will be upgrading, staying with what they have or seeking other libraries. If anyone's considering the route of maintaining older libraries, I'd be very interested in sharing resources and patches.

I've mentioned my build system before. I've been trying to find a good way to share the programs I've compiled for Windows, Linux, AIX, Android, etc. However, I still haven't found a good method to do so. Rather than continuing to wait until I find the perfect solution, I've decided to try a temporary solution that's very basic.

I've already been uploading the build scripts to the archive link at my LM Ports page ( http://www.distasis.com/cpp/lmports.htm ). I'm going to start adding some executables and libraries for Windows. I don't have an automated installation program at this point, so some manual work needs to be done to get programs to run. In order to run a program, you will need all the dependencies. So, you need to download the tarball (has txz extension) with the program you're interested in plus the tarballs with the dependency libraries aka dlls. The bldepend.txt file in the build script has a list of what dependencies are needed to build a program or library. The depends.txt file in the tarball package has a list of all the dlls needed for the program to run. Pick a directory on your system. ( I use \mingw\msys\ ) Unpack the required tarballs to the same directory (holding the executable program and libraries/dlls). ( This puts the programs and dlls in \mingw\msys\opt\bin ) Programs like 7zip, 7za, gzip, bsdtar can be used to unpack tarballs. You can run them from the command line or the msys bash shell. If it's a program with a GUI, you can also create a shortcut or run from the file explorer.

I use some tricks to make programs more portable including a couple of specialized libraries and some patches so that the programs don't have to run from the directory they're built for. I don't have those libraries uploaded and ready to share yet. For now, I'm using the standard libintl instead of my modified version. So, internationalization probably won't work well until I can switch to my libraries.

While I'm not interested in changing package managers/build systems, I'm open to suggestions on better/easier ways to make the programs available/accessible to people. The plan was to eventually put together an ISO with several programs and a GUI front-end plus more documentation on how the programs work, but I'm not far enough along in the project to do so yet.

It's a lot of work to try to port programs and keep the build scripts up-to-date. I've just been doing this for myself. So, don't expect any official support on the project. However, I would like to share some of the results with others in the chance that it might be useful to someone besides myself now. If you'd like to encourage the project or get more involved, you're welcome to do so from the CppDesign mailing list ( http://www.distasis.com/connect.htm ). I have Windows builds for several command line utilities, SDL, FLTK and pdcurses based programs and even an X Windows port.

For a long time now, I've been wanting to put together an ISO with Free, Libre and Open Source software similar to the kind our Linux Users Group gave out on Software Freedom Day. I'd like to gear it specifically toward educational software so that groups like Schoolforge may make use of it. If you'd like to help, I would love to have suggestions for lightweight, portable software that can run in console or framebuffer mode. I'm specifically interested in educational, hobby-related, utility, information/organizing and/or word processing programs. Have any recommendations? Please let me know ( http://www.distasis.com/connect.htm ).

Since I'm creating this to promote FLOSS software, I thought it would be great if I could distribute the software on a remastered Linux ISO that could be run from VirtualBox or Qemu or that might boot from a DVD or flash drive. I'd like to try to stick with a console based distribution so that it's lightweight and runs well on older computers with low resources. That means all programs need to be command line, console based (ncurses/pdcurses) or work in framebuffer mode (using SDL 1.x, nano-x, nx11, FLTK, etc.) in order to run on the system without X Windows or Wayland. For efficiency, I'd prefer compiled programs (such as those written in C) to ones that require an interpreter to run. I'd also like to make it as accessible as possible as far as internationalization and for users that may have disabilities. I'm using internationalized language support when possible via gettext. There are utilities like flite and espeak for text-to-speech support. My goal is to put together a lightweight, low resource distribution that will work well for users with older computers and users with no or limited Internet access. There are plenty of things you can do with a computer even if you can't get access to the Internet. Why not make some of those options more readily available?

I'll list some of the software I'm currently considering for the distribution. I'm still missing functionality in several areas, so if you have any recommendations for programs that would fit the criteria I've mentioned, please let me know.

Graphics applications

grafx2 - graphics editor
lodepaint - graphics editor
graphicsmagick - command line graphics editor
picaxo - graphics viewer
perigee slideshow - slideshow viewer
gifsicle - command line tool to create animated GIF files
GLE - command line tool to produce charts
nanosvg - includes lightweight SVG viewer

Music creation/audio applications

I'm still looking for a good Karaoke program (written in C or C++). TiMidity++ does some lyrics display, but I've yet to see it display lyrics created by abc2midi using the console version of TiMidity++. Some educators have found Karaoke to be a good way to help students improve their reading skills.

abc2midi - create your own music using music notation and convert to midi format (command line)
abcm2ps - creates sheet music (command line)
sox - sound exchange, audio file converter and player (command line)
milkytracker - create and play music
TiMidity++ - plays midi files

Readers

Still need several suggestions in this area. I'm currently looking for lightweight PDF and Postscript viewers. Was thinking of using mupdf but I'd still need a decent front-end for it that will work in framebuffer mode. Xpost might make an interesting alternative for Postscript display, but it's still in the works. I found a cbr/cbz library, but don't have a good framebuffer based front end for that yet either. It could be integrated with mupdf or used standalone. Would be nice to include some educational public domain ebooks with the distribution too.

bard - epub reader with text-to-speech capability
pdftxt - converts PDF to text using libmupdf (Can be used with search tools such as grep.)
qpdf - command line PDF transformation tool
sdlbook - SDL front end for libmupdf (Recently found this and it may fill my needs for a PDF viewer.)

Audio/video players

flxplay - plays flx movies
theoraplay - plays ogg theora videos and ogg vorbis

Astronomy

nightsky - displays stars
pngphoon - graphically shows moon phase (command line)
lcal - command line based lunar calendar that outputs to PostScript

Word processing

I'm thinking of using one or more of the following editors as an alternative to the popular vi/vim and emacs editors. Other suggestions welcome.

nano - ncurses/pdcurses editor
textadept - programming editor that uses scintilla editor widget has ncurses/pdcurses front-end
wordgrinder - ncurses word processor
mp (maximum profit) - editor with ncurses/pdcurses front-end

Other text related utilities

I have a few dictionaries in stardict format that are Open Source. (Created one from the Mobi project.) I'm looking for other Open Source dictionaries in the stardict format or easily converted to that format. Also still looking for a good grammar checker program.

hunspell - command line spell checker
sdcv - command line version of stardict dictionary tool
style - readability tool
diction - readability tool

Information managers/organizational tools

This section needs some additions. Anyone know a good SDL based calculator? I'd love to find a decent command line utility to avoid repetitive stress injury. There are some great desktop ones such as (workrave and prevrsi).

pcal - command line calendar that outputs to PostScript
ckpass - possible command line keepass replacement
sc - spreadsheet calculator

Hobby related

Don't have much in this category yet. There are several good HAM radio programs available. Maybe some of them that will work in console or command line mode could be added. Other hobby suggestions welcome. Also, maybe some public domain ebooks on hobbies could be useful.

nut - nutritional analysis

Educational entertainment

If you have other recommendations, please let me know.

lpairs - memory game
dual-n-back - memory tool
anagramarama - anagram language game
scramble - anagram language game
hangman - language game
concentration - memory game
tuxmath - game for improving math skills
starlanes - interstellar commerce game

That's all I have so far. I still have to look into remastering a Linux distribution. If you have tips for a simple remastering tool to use or know of some good documentation on how to remaster a Linux distribution via command line, please let me know. Would also appreciate other suggestions for lightweight, portable, useful or educational software (preferably in C). I'm also looking for Creative Commons, public domain or Open licensed educational media (ebooks, videos, etc.). Know of a Linux distribution that's already doing a similar project and would like another volunteer? Please let me know. If you'd like to discuss this project further or help out in some way, feel free to contact me ( http://www.distasis.com/connect.htm ). Thanks.

Some of the C graphics libraries are great, but I've yet to find a simple GUI that makes it easy to port some older BASIC programs that I want to be able to keep working with. I've created several iterations of my own GUI library, but have never been satisfied with the results. That's the main reason I keep investigating cross-platform GUIs, to see if someone's found a better way to do it. Of the various designs, the ideas behind the immediate mode GUIs seem the most useful for the type of programs I'm targeting. However, I can't seem to find one GUI library that provides a simple way to do what I want. So, I've decided to revisit my old GUI library designs but eliminate some of the framework constraints and some of the object oriented elements. Instead, I'm looking at a more procedural approach that uses concepts from immediate mode GUIs.

Even though I'm avoiding popular C/C++ GUI libraries, I'm not starting completely from scratch and writing everything myself. There are plenty of good graphics libraries that are very portable and make a great basic starting point for a GUI. One of the libraries I've been very impressed with is SDL. It makes a great base for porting software. I've also done a lot of work with PicoGL (a TinyGL fork). It's a convenient way to make OpenGL more portable and avoid some of the version issues. It works on low resource platforms such as handheld devices that don't have high performance video driver support. I've often found OpenGL and Mesa slow on older computers and low resource systems. PicoGL provides very good performance on these types of systems. While using Win32 is not as portable as I would like, it's not that hard to get an OpenGL window up and running on Win32. That easily allows switching between Win32/OpenGL and SDL (1.2.15 or SDL 2.x)/PicoGL. SDL can work on a variety of platforms and PicoGL can work with SDL or with other options such as nano-x, X11 or vesa framebuffer. It shouldn't be too hard to take the output from PicoGL to use with the Android bitmap API either. Another possible option for a backend is Allegro. Like SDL, it works on a variety of platforms. It would be nice to switch between SDL and Allegro as backends depending on which works best for a particular platform without needing to redesign an entire application.

The PDCurses/ncurses API provides a standard way to create console based programs that work well on a variety of platforms from DOS to Windows to FreeBSD to Linux. However, it provides only text support and no real graphics support. While it's great for porting programs written to work with it, I don't think it's the best option to use as a GUI backend. I recently came across TinyCurses which provides a subset of the API and uses SDL as a backend. PDCurses also offers SDL as a backend option. I couldn't help thinking, once a decent GUI design was finalized, it wouldn't be too hard to provide a subset of functionality similar to PDCurses/ncurses. That would allow for easy porting of some PDCurses/ncurses based applications to any platform the GUI library works on.

So, why not just use OpenGL as the backend to design a GUI library? After considering the pros and cons, I decided I don't want to be tied specifically to OpenGL as an API for 2D graphics. While it's very popular and available on several platforms, the changes from a fixed function pipeline to a programmable pipeline with its own shading language make it hard to port programs from one version to another. PicoGL makes use of old fixed function pipeline concepts. Windows OpenGL also uses the older design. Mobile devices and WebGL make use of the newer concepts and the ability to harness the GPU to do more processing. Many developers seem to be abandoning the older concepts and embracing the new programmable pipeline design. However, that leaves some nice older applications that were designed for earlier versions of OpenGL that won't port easily to the newer versions. They might require a complete redesign and rewrite. Using PicoGL is one way to make it easier to port such applications. It can do software rendering to a bitmap which can then use more modern methods (including later versions of OpenGL or SDL 2.x) to transfer the bitmap to the screen. While the idea of using OpenGL as the portable backend for a GUI library sounds good, dealing with version differences and what versions may be available on which platforms does not make it the best option for a complete cross-platform portable solution. Instead, I prefer the concept of being able to switch out backends to use what works well on a particular platform. The GUI library should encapsulate the rendering as much as possible to avoid needing to rewrite applications in order to switch to another backend.

On the other hand, many GUI libraries and some other rendering libraries (such as SDL) offer ways to interoperate with a graphics library like OpenGL. While I want my GUI library code to be cross-platform, I don't want to limit a developer to using just that API. If a programmer wants to use OpenGL or SDL2_gfx or some other library to handle 2D/3D graphics, I'd like the GUI to be able to interoperate with that choice. It would mean that the resulting application would be less portable. However, if an application is already designed to utilize SDL2_gfx, OpenGL or some other library that could work compatibly with the GUI library, it could make adding some GUI functionality to an existing application much easier.

I definitely know what I'm looking for in a cross-platform GUI. I want a simple, portable way to get text, menus, forms, file/directory picker dialog functionality to the screen. I'd like to make use of Freetype fonts. I want an internationalized way to display text and for users to input text. The text strings will probably involve a library such as gettext. I want the options to use keyboard input for those of us who prefer keyboard commands to get their work done and mouse/touchscreen input for devices such as mobile phones where a real keyboard may not be available. I need to be able to access graphics and audio information from a file system or from a zipped file (such as .apk file on Android). I don't care if the look and feel matches what's in style for a particular device or operating system. I just want it to be user-friendly and ergonomically designed.

If you're interested in GUI design or working on a GUI or gaming library of your own, I'd love to compare notes on the subject. Have an idea for what C library might make a good backend for a portable, cross-platform C based GUI? Let me know. Feel free to discuss design issues or other C/C++ topics on the CppDesign mailing list or contact me to compare design notes and share ideas ( http://www.distasis.com/connect.htm ).

I'm always on the look-out for a simple to use, lightweight, portable GUI library. I've put together several lists of available C/C++ GUI libraries. (For instance: http://www.distasis.com/cpp/scrlib.htm ) I've also tried out and experimented with several GUI and text user interface libraries. It's difficult to find one that will let you get a new application up and running or an old one ported to C/C++ quickly. Most GUIs seem to get in the way of development or complicate it.

I still keep debating whether to create my own GUI library in projects or use what's currently available. There's no point in creating your own if there's something better out there. That's the main reason I continue to look for interesting GUI libraries. However, I've yet to find that "something better" that I really enjoy working with.

With that in mind, here's another list of GUI libraries. This time I've limited the field to C only libraries that are highly portable. Since many lighter GUIs use various graphics libraries and other frameworks as backends, I'm including information on graphics libraries that can be used for GUI development as well.

Graphics libraries often used with GUIs:

Some lightweight GUI libraries use graphics libraries as backends to improve portability and decrease library code size. Popular graphics backends written in C include SDL (Simple DirectMedia Layer) and Allegro.

SDL

https://www.libsdl.org/
SDL2_ttf provides TrueType text support for SDL.
https://www.libsdl.org/projects/SDL_ttf/
SDL2_ttf provides internationalization support using a UCS-2 character set. I have patches to support the UTF-32 character set.
http://www.distasis.com/cpp/lmports.htm

Allegro

https://www.allegro.cc/about

AGG

Anti-Grain Geometry library is also used as a graphics backend. Some projects stick with the older version of AGG 2.4 which has a BSD license.
https://en.wikipedia.org/wiki/Anti-Grain_Geometry

Nano-X/Microwindows

Nano-X is highly portable and can work on a wide variety of platforms including DOS and embedded systems. It makes it easier to port X11 and Win32 applications by providing a subset of those APIs (with nano-x/NX11 or microwindows).
https://github.com/ghaerr/microwindows
https://github.com/georgp24/microwindows-android-bin
https://github.com/ghaerr/nxlib

OpenGL

I've seen several lightweight GUI and screen libraries designed for OpenGL. However there are issues with portability to different versions of OpenGL or OpenGLES. Projects like freeglut and GLFW try to make OpenGL easier to use for cross-platform development. There are also several libraries that work with the freetype library and add TrueType font support including ftgl, ftgles, GLTT, freetype-gl, OGFLT
http://freeglut.sourceforge.net/
https://www.glfw.org/

PicoGL

I like PicoGL (a fork of tinyGL) for OpenGL development. It's a subset of OpenGL. It supports several backends including SDL, nano-x, X11 and vesa framebuffer. Since it's software based, it ports well to hand-held devices and other systems that may not have rich hardware support for graphics.
http://people.openmoko.org/jserv/graphics/

I've made several updates and additions to PicoGL including adding some missing OpenGL functionality, SDL 2.x support, bug fixes including a fix for lighting bug in the gears demo. It includes enough OpenGL support to port Emilia pinball. I haven't uploaded my changes to the Internet yet, but if anyone's interested, feel free to contact me about it.

GUI and text user interface options:

PDCurses with SDL backend

This is an option I really like. I've been experimenting with using this for development. I have BSD libmenu and libform working with it too. PDCurses can be used to create a text user interface and SDL can add graphics capabilities.
https://github.com/wmcbrine/PDCurses

TinyWidgets

Lightweight GUI with graphical screen designer. Uses nano-x as a backend. While the original project is dated, there's been some recent development by some of the nano-x developers.
http://tinywidgets.sourceforge.net/
https://github.com/ghaerr/microwindows/tree/master/src/contrib/TinyWidgets

nuklear

This looks promising. Has several backends including GLFW, SDL, Win32, X11, SFML, allegro, nanovg.
https://github.com/Immediate-Mode-UI/Nuklear
https://github.com/vurtun/nuklear
https://github.com/vurtun/nuklear/issues/202
There are also projects that combines nuklear and raylib:
https://github.com/RobLoach/raylib-nuklear
https://github.com/tcfunk/raylib-nuklear

raygui

Another promising cross-platform option. It has support tools to help create layouts. It works on a variety of systems including mobile devices. There's also raylib (a graphics/video game library used by raygui) and raudio (for audio support). The raylib library uses OpenGL/GLFW for graphics support.
https://github.com/raysan5/raygui

c_ugui

Immediate mode GUI using Raylib.
https://github.com/Aurumaker72/c_ugui

nanovg

nanovg is a 2D vector drawing library by the developer of nanosvg (popular svg parsing library). The examples show GUI elements. Other GUI libraries (including nuklear and oui-blendish) also use this as a backend option.
https://github.com/memononen/nanovg
https://bitbucket.org/duangle/oui-blendish/src

GTK+

GTK+ is one of the more popular GUI libraries. However, while each new major version came with added features, it also came with a lot of added complexity. Some distributions use older versions of GTK+ (no longer in development) in order to cut down on complexity. While there were several applications written with this library, it's hard to find up-to-date, supported applications that still use an older version of GTK+.

Amigo Linux is still using GTK 1.2 and has patched some applications to keep them working.
ftp://distro.ibiblio.org/amigolinux/misc/Amigo%20Linux%20Project.html

I've also seen some patches to GTK 1.2 to keep it more up-to-date.
https://github.com/dimkr/gtk
https://github.com/tindzk/GTK

Another interesting GTK+ based option, there were some ports of GTK+ that use the ncurses backend.
https://atrey.karlin.mff.cuni.cz/~pavel/cursed/cursed.html
https://sourceforge.net/projects/zemljanka/files/

If you're interested in more up-to-date GTK+ versions that try to avoid some of the bloat and unneeded dependencies, check out these forks for GTK 2 and a minimal ATK to use with GTK 3:
https://github.com/stefan11111/gtk2
https://github.com/stefan11111/atk

XForms Toolkit

http://xforms-toolkit.org/

LessTif

https://sourceforge.net/projects/lesstif/

Kiss_sdl

GUI toolkit for SDL.
https://github.com/actsl/kiss_sdl

kiss-nanovg-sdl

Based on kiss-sdl but modified to support svg using nanovg.
https://gitlab.com/Mis012/kiss-nanovg-sdl

KiWi

GUI toolkit for SDL.
https://github.com/mobius3/KiWi

RetroGui

Minimalistic GUI library based on SDL.
https://gitlab.com/Pix3l/RetroGui

rouziclib

Works with SDL and other libraries.
https://github.com/Photosounder/rouziclib

Green-GUI

GUI for SDL 1.2 written in C99.
https://github.com/Laurefinwe/Green-GUI

swk

Minimalist widget kit for SDL.
https://oldgit.suckless.org/swk/files.html

WidgetSDL2

C99/SDL2 Cross-platform GUI using include headers.
https://github.com/nuchida7727/WidgetSDL2

uGI

Micro Graphical User interface. Needs SDL2.
https://github.com/wernsey/uGI

SDL GUI

Simple SDL GUI libraries, mainly targeted toward Windows.
https://github.com/David-H-Bolton/sdlgui

CGUI

GUI toolkit using allegro.
http://cgui.sourceforge.net/index.html

Win32

I've seen several C applications written with the Win32 API. That might not sound very portable for platforms other than Windows. However, keep in mind that X11 users have access to winelib and Microwindows offers some Win32 API compatibility. I have been able to get some programs written using a Win32 backend to port and run fine on Microwindows/nano-x.

Otk (Open Tool Kit)

C and OpenGL GUI.
https://sourceforge.net/projects/otk/

IUP

https://sourceforge.net/projects/iup/

LCUI

https://github.com/lc-soft/LCUI

sgui

https://github.com/AgentD/sgui

libui

https://github.com/andlabs/libui

libui-ng
https://github.com/libui-ng/libui-ng

GraphApp

http://enchantia.com/software/graphapp/

Microraptor GUI

https://github.com/hodefoting/mrg

Micro-GUI (ugui)

https://github.com/ryankurte/micro-gui

microui

https://github.com/rxi/microui

FTK

https://github.com/xianjimli/ftk

EasyGui for embedded systems

https://github.com/MaJerle/EasyGUI

m2klib

https://github.com/olikraus/m2tklib

Milkymist Gui Toolkit

https://github.com/m-labs/mtk

mGui

http://web.tiscali.it/morello/MGui/index.html

RGFW

https://github.com/ColleagueRiley/RGFW

RSGL

https://github.com/ColleagueRiley/RSGL

Yzone

http://lifesoft.chat.ru/yzone/

GUISlice

https://github.com/ImpulseAdventure/GUIslice

newt

https://pagure.io/newt

notcurses

https://github.com/dankamongmen/notcurses

vtk

https://github.com/vktec/vtk

Agar

GUI toolkit using SDL. I've read several posts about it being buggy and not well supported. I've personally had no luck porting it to certain platforms.

STFL

Use with PDCurses, ncurses or similar libraries to provide common controls and widgets.
http://www.clifford.at/stfl/

CDK

Curses Development Kit.
https://invisible-island.net/cdk/cdk.html

Widget Curses ToolKit

Ncurses TUI widget toolkit library.
https://github.com/stfsux/libwctk

This list is in no way comprehensive. If you know of other highly portable, strictly C GUI or text user interface libraries, please mention them. If you're working on your own GUI library, would like to discuss C/C++ GUI libraries and development or other C/C++ related topics, feel free to continue the conversation on the CppDesign mailing list.

Let's talk about Free and Open Source games. I thought I covered some of these when I discussed programs that work with various GUIs such as SDL and FLTK. However, looks like I left many out of my lists. So, here are some games I've found interesting. They're cross-platform and don't require a ton of resources to build and run. So, they should work fine on low resource or older machines as well as the newer ones. I tend to prefer educational games, but there should still be a good mix of different types of games in the list. If you have other lightweight cross-platform favorites, I would be interested to hear about them. You're welcome to discuss the topic of C/C++ games further on the CPPDesign mailing list ( https://groups.yahoo.com/neo/groups/CppDesign/info ).

I have patches for several of these to fix bugs such as memory leaks and to add support for later versions of libraries. Some of my patches are available online. If you're interested in others that I have not uploaded yet, you can let me know via the CppDesign mailing list.

FLTK BASED GAMES

Checkers and sudoku come with FLTK as examples.

fltkmm

Mastermind game. This is one of the more lightweight versions of Mastermind that I could find that's still intuitive to play. There are some ncurses/PDCurses alternatives and some SDL alternatives, but I haven't found any I like yet.

I have patches to make this work with the latest version of the FLTK library.

https://www.muquit.com/muquit/software/fltkmm/fltkmm.html

wordsearch

I've been able to port this to DOS using DJGPP. It also works fine on Windows, Linux and BSD.

http://agtoys.sourceforge.net/wordsearch/wordsearch-2.2.html

qubix

While this ports without modifications to several platforms using Nano-X support for FLTK, I've been experimenting with patches and a port to use OpenGL/PicoGL as an alternative GUI. The program was originally written for a system that had Display Postscript support so it ports very easily to a graphics API like OpenGL.

https://www.fltk.org/links.php?V153+Q

npuzzle

http://jlehtinen.net/agenda/

SDL BASED GAMES

SDL is great toolkit for games and there are several nice games that work with it. Many of the games I've listed were written for SDL 1.2.x. I have patches in various states to get them working with version 2.x as well.

lpairs

http://lgames.sourceforge.net/LPairs/

scramble, hangman, concentration, torrent

These games are by the same author and use a similar back-end. I've made a library out of the shared code and am in the process of debugging ports to SDL 2.x.

pong

A copy of the original source and my SDL 2.x patches are available from the archive link at:
http://www.distasis.com/cpp/lmports.htm
Was also able to get this working for Android, but it requires a tablet with a keyboard.

drac

Basic solitaire card game.

I have patches for porting this to SDL 2.x as well. Was also able to get this working on Android systems.

https://github.com/ricoz/drac/

yahtzee

Works with SDL, ncurses/pdcurses or via command line. I have patches for using this with SDL 2.x.

https://www.muppetlabs.com/~breadbox/software/yahtzee.html

dual-n-back

This is a game, but it's also supposed to help improve memory.

https://sourceforge.net/projects/dualnbacklite/

tuxmath

A copy of the source and my SDL 2.x patches plus several memory and bug fixes and some modificiations for library updates are available from the archive link at:
http://www.distasis.com/cpp/lmports.htm
My patched version runs on Windows as well as Linux/BSD. The original source crashed on Windows.

Emilia pinball

I have patches porting this to SDL 2.x. I also improved Allegro support enough to build on DOS with DJGPP. I have an alternative build that works with SDL and picogl for systems that may not have easy access to an OpenGL library or mesa.

https://sourceforge.net/projects/pinball/

jooleem

I was looking for a bejeweled style game and this was the only one I found so far that I really liked.

https://sourceforge.net/projects/jooleem/

eremit

http://www.murga-linux.com/puppy/viewtopic.php?t=8724

anagramarama

https://github.com/Anagramarama/anagramarama

ReMined

https://sourceforge.net/projects/remined/

sopwith

http://sdl-sopwith.sourceforge.net/

PDCURSES/NCURSES/BSDCURSES GAMES

There should be several good games in this category but so far I just have one on my list. Please feel free to recommend your favorites in this category.

starlanes

This started out as a game written in BASIC with a few variants available. The version mentioned here is a variant that's been ported to C.

https://web.archive.org/web/20191230071944/http://www.barnsdle.demon.co.uk/game/starlanes.html

WIN32 GAMES

To make WIN32 applications work cross-platform, you'll need nano-x or winelib. The win32api is available with Open Source compilers such as MinGW on Windows sytems.

pyramid

This is a public domain solitaire-style card game. I'm currently working on converting this to run with SDL/OpenGL as the backend (instead of Win32) so I can more quickly and easily port it to other systems such as Android. It will make a nice test case for the GUI library I'm working on. If anyone's interested in status of the port, feel free to contact me about it.

http://jdmcox.com/

I've covered SDL and FLTK based applications. Now I'd like to discuss pdcurses and ncurses based ones. ncurses is found on many POSIX systems especially Linux. pdcurses was used primarily on DOS and Windows systems. Support for X and SDL was later added. The X support uses some legacy functions, so it doesn't build well on modern Linux systems. However, the SDL support allows pdcurses to be ported to any system that supports the SDL library. That means it can run on systems like Syllable and Haiku not just POSIX systems with X Windows. ncurses worked only on POSIX systems for a long time, but more recently support was added for Windows and MinGW32.

So which is the better library to use? Depends on your needs. ncurses is very stable, provides good Unicode support on many operating systems and offers added functionality like panels, menus and forms. On POSIX systems, it runs in console mode, so you can run applications outside X Windows (or Wayland) or on systems with no X Windows installed. Applications built with ncurses can also be used via ssh and telnet. Unicode support for pdcurses is currently limited to UCS-2 (16 bits). It designed in such a way that expansion to UTF-8 or UTF-32 would mean major changes. It works in console mode, but on DOS/Windows only. You'll typically need X Windows if you run pdcurses on a POSIX systems. There are some work-arounds to this. You can use DirectFB or nano-x to run SDL in framebuffer and use pdcurses with the SDL backend. However, applications run in framebuffer mode aren't usable with ssh and telnet. You'll need something like vnc to remotely access them. There is also a pdcurses fork called win32a which provides native Windows support and better support for colors. pdcurses has some functions that are not typically standard with ncurses/curses such as specific mouse and clipboard functions. However, it lacks a lot of the extras that ncurses adds such as menu and form support. Both pdcurses and ncurses have functions for the standard ASCII character set and for wide characters (wchar). However, keep in mind that wchar is 16 bits on Windows (and DOS djgpp) systems and 32 bits on most POSIX systems (such as Linux and BSD). Personally, I prefer to use UTF-8 whenever possible for Unicode. I also prefer the new char32_t (or uint32_t if not available) in place of wchar_t in all my applications with internationalization support. However, pdcurses/ncurses aren't designed for these options. Of the two libraries, ncurses better supports characters in a Unicode character set beyond the initial 16 bits and is better designed to handle large character sets.

Even though ncurses has many advantages over pdcurses, I still like to work with pdcurses. It's a more compact library, with the backend code separated from the rest of the code to make it easy to port to other platforms. With this design and with its SDL support, it's easy to get pdcurses working on a wide variety of operating systems including some places ncurses has not been ported. As mentioned, libform and libmenu are not a part of pdcurses, but their functionality is available with ncurses. It turns out that other versions of curses did not originally have support for forms and menus and they were separate libraries. BSD still has libform and libmenu that work with its version of curses. I found it very easy to port libform and libmenu to work with pdcurses. There were some bugs in the libraries which I'm surprised no one has fixed yet, but I have patches for them. One other advantage of pdcurses built with SDL is that you can intermix SDL and pdcurses commands. pdcurses/ncurses are primarily console/text libraries. SDL offers graphics support. You can mix graphics from SDL with text from pdcurses and use pdcurses as a text user interface (GUI alternative) for SDL. That's a really nice option when developing SDL applications.

I've added SDL 2.x support to pdcurses, so it will port to systems that support SDL 1.x or SDL 2.x. pdcurses with the SDL backend, used bitmaps to represent characters. That curtailed Unicode support. I've added support to use SDL_TTF for drawing characters. Now the only limitation on characters that can be used with PDCurses is the 16 bit limit to the character size built into the system. It should be possible to expand that to 32 but it would require modifications that would affect the entire design. Also, since curses only supplies ASCII and wchar support for routines, a Windows (or DOS) system would still be limited to 16 bits. One would need a new set of routines with UTF-32 support or UTF-8 support. The current routines could not be used to support 32 bit characters on systems where wchar is limited to 16 bits. The ASCII functions are designed to work with one character at a time not several which UTF-8 might require.

Some of my patches for better internationalization support for pdcurses have been added back in to the official version of pdcurses. All of my pdcurses patches plus documentation on them and my build scripts can be found by following the archive link at http://www.distasis.com/cpp/lmbld.htm I'm interested in adding some of the win32a patches and continuing to improve support for internationalization in the future. If anyone wants to discuss design ideas for continuing to add better Unicode support for pdcurses, please contact me.

The good news with ncurses/pdcurses based applications is that it's relatively easy to port them from one version of curses to another in many cases. It may require changes in the names of header files. Non-portable functions such as those supporting a mouse may not be available on some systems. However, one can typically use any application designed for a particular version of curses with another version of curses. That does not mean ncurses/pdcurses applications can easily be ported to other operating systems. For instance, if an application uses functions that aren't very portable across platforms (such as fork which isn't easy to emulate on Windows and doesn't work on DOS), it will be very difficult to port that application. Unfortunately, many ncurses applications do just that and use POSIX functions that aren't widely ported to non-POSIX systems.

So, let's talk about some of the applications that I've found that do port across a variety of operating systems and can be built with pdcurses.

There are several ncurses based hex editors available. I personally like the interface for ncurses hexedit. It reminds me of the kzap program I used to use with DOS, so I find it user-friendly. shed is another interesting option. It handles large file sizes extremely well.
You can find the programs here:
http://www.rogoyski.com/adam/programs/hexedit/onlinedoc/hexedit.html
https://sourceforge.net/projects/shed/

I have patches/build scripts for ncurses hexedit to work with pdcurses and port to other platforms. I've built shed on Windows before, but haven't created my own build scripts/patch set for it yet.

There aren't a lot of music applications that work well in console mode and provide a text user interface, but there are some. The ones that come to mind are TiMidity++ and GramoFile. Make sure if you intend to work with TiMidity++ that you start with the source from version control not the very old, outdated tarball at Sourceforge. Many features, including better Karaoke midi support, have been added since the tarball was created. I find it discouraging that distributions such as Debian refuse to update to the latest supported version of this project. I always build TiMidity++ from source myself to make sure I have the updates I need. I'm currently working on a build script for TiMidity++ that will allow me to build it as a library so it can be used with other applications. I currently have build scripts for TiMidity++ and freepats (Open Source sound fonts used with TiMidity++) and gramofile.
https://sourceforge.net/projects/timidity/
http://www.opensourcepartners.nl/~costar/gramofile/

I originally looked for library versions of libform and libmenu because I thought a lot of curses applications would make use of these features. Turns out, not as many use it as I originally estimated. One program that makes use of the functionality for these libraries is ckpass. It's a console based password keeper that is compatible with KeePass 1.x format. That means, if you want a lightweight alternative to the earlier versions of KeePass or KeePassX, you can still have console access to your passwords. The program looks great and it's easy to use. Unfortunately, it offers just read-only support for viewing password information. There's no easy way to modify password information using the program. However, it isn't that hard to add code to allow editing as well as viewing of passwords using libform. I'm working on some modifications to ckpass to give it more functionality, so it will become a useful, more lightweight replacement to other password storage alternatives. There are other command line based password storage options available and some even use portable formats so that you can find cross-platform solutions. However, I like the idea that ckpass supports the KeePass 1.x format which many other GUI password programs also use. This is the link to the original ckpass project:
https://sourceforge.net/projects/ckpass/

The final category I'll cover is the text editor category. There are a great many text editors that work in console mode or build with ncurses as can be seen from the listings at TextEditors.org ( http://texteditors.org/cgi-bin/wiki.pl ). However, the large majority of them are not highly portable.

When the competition between vi and emacs comes up and people start debating what should be the default editor on a Unix or Linux system, I typically skip both and go with nano. nano was based on the pico text editor. It wasn't a fork. It was coded from scratch, so there would be no issues with code licenses. pico was the main editor for the alpine mail system. Compared to other editors with unusual key sequences that you need to memorize to get anything to work, I find it very user-friendly. It has a menu and easy access to help if you forget what command keys you need to perform a specific function. My personal preference is to use a programming editor that will allow you to map key commands however you see fit. That avoids large learning curves if you didn't originally use vi or emacs as your first text editor and memorize their commands. However, if a text editor with keymapping support is not available, a user-friendly text editor with easy to access command menus and help descriptions is a good second choice. Most POSIX systems I work with have either pico or nano available or they can be installed fairly easily. So, if I need to do a quick edit from the console on a POSIX system, my default editor is typically nano or pico. One major drawback to pico is that it only handles one file at a time. You cannot have multiple files open and flip between editing them or cut and paste between them. nano adds support for multiple files, but the commands to switch aren't particular easy to remember.

I did a port of nano to Windows several years ago. There's a lite way to build nano (tiny) and a way to build it with more functionality. Building it the lite way and adding some modifications for porting, I was able to compile it successfully on Windows. So, while it didn't provide all the functionality I used on POSIX systems, it did work on Windows. A few years ago, I found a Windows port of nano on github. It didn't provide extra functionality, but it was interesting to see how the author went about porting the application and the differences between my port and that one. According to the nano editor FAQ, it now looks like there's some official support for Win32. However, when I tried to build the latest version, I still ran across a lot of the same issues as when I built previous versions. Only the lite version is supported for Windows. There were some assumptions about MinGW types that aren't true for all versions of MinGW. Rather than using configure for what it was designed for and testing if there needs to be a work-around for a particular system, the code has ifdefs that assume MinGW always handles things wrong and tries to fix the situation. In the process, it causes errors in the build for MinGW systems that do handle the situation properly. Guess I'll need to stick with my port or a Windows specific port like the one at github if I want nano to build properly on Windows.

nano is a great lightweight alternative for a text editor that works on a large variety of operating systems. When I need to modify a file and want an editor to quickly call from the command line, it is often my editor of choice. You'll find the source code and more information on nano at:
https://www.nano-editor.org/

As I mentioned, I prefer programming editors that have good support for key-mapping. The scintilla text editing component offers just that. A large variety of Open Source editors, including SciTE (my favorite GUI editor) and fxite (lightweight FOX Toolkit based GUI editor), use the scintilla text editing component. While fxite is lightweight and works well on older systems, it requires X Windows on POSIX systems and the FOX Toolkit to build it from source. I wanted something even more lightweight. I did a search of the various editors that make use of the scintilla text editing component and I ran across textadept. It is a GUI text editor, but there's a ncurses based version that works from the console. I found it relatively easily to build the editor on Windows using pdcurses. So, it's rather portable. If I had to pick a console based editor besides nano and pico, textadept would be it.
https://foicica.com/textadept/

There are ncurses front ends to some applications I work with such as hunspell and prozilla, but I typically don't use the front ends. I prefer using hunspell via command line or integrated with a programming editor. There's a nice FLTK front end for prozilla that is highly portable. One other ncurses based application I'll mention is WordGrinder. I typically see it mentioned on sites and blogs that specialize in discussing console based applications. It has many of the features of a word processor. The current web site for it is:
http://cowlark.com/wordgrinder/

I haven't tried it out, but nanotodon looks like a useful cross-platform client for Mastodon. Was able to get it to build on Windows using pdcurses.
https://github.com/taka-tuos/nanotodon

If you have other recommendations for useful, cross-platform portable ncurses/pdcurses/curses based applications, I'd love to hear ( http://www.distasis.com/connect.htm ) about them. It would be great to add more helpful applications to this list. I'm also very interested in the possibilities of using pdcurses/libmenu/libform as a text user interface (GUI alternative) for SDL applications.

It's fun to discover new lightweight applications. They work well on newer computer systems as well as older or slower computers and low resource machines like many mobile devices. You can run more of them at once. If they're not well-known, they can actually be more secure sometimes (using the security through obscurity principle). I also personally prefer portable applications. That way, you can use the same programs on any operating system. You don't have to relearn new programs for each system you work with.

It can be quite a challenge to find new lightweight applications. I've read several threads on forums where users post their favorite lightweight applications. Many truly are not lightweight by standards that take into consideration memory usage, lines of code, compilation time and/or number of dependencies (libraries).

One way to find lightweight applications is to look for programs built with lightweight GUIs. I've seen a few comparisons of GUI performance. This one is particularly good because it tests the various GUIs and gives statistics:
https://www.pismotek.com/brainout/content/gui-toolkit-resources.php
I was rather surprised by the SDL2 results. Generally, the time it takes to build a GUI from source is one good indication of complexity. FLTK and SDL both build quickly from source compared to the other GUI frameworks mentioned. So, I was surprised that SDL2 scored so badly on the memory usage tests. I'd be curious to know if SDL 1.2.x (which many systems still use) would show a large improvement. Another surprise was how well Tcl/Tk did in the tests. I typically think interpreted languages have worse performance than compiled ones. It would be interesting to see some statistics on response times for similar applications created with these GUIs.

I often go through various source repositories such as Sourceforge, github, etc. looking for code written using specific user interfaces in order to find new and interesting applications. Standard search engines are another way to search for programs. The user interfaces I'm personally most interested in at this point are FLTK, pdcurses/ncurses, SDL and command line programs. These types of applications are typically more lightweight or designed to do one thing well. Know of any other lightweight GUIs or TUIs (text user interfaces)? Please share your recommendations and why you like them.

There are some nice blogs for finding and discussing minimalistic (or in some cases maximalistic) programs. Unfortunately, many are no longer very active. Some favorites are:
https://kmandla.wordpress.com/
https://inconsolation.wordpress.com/
https://web.archive.org/web/20160304000554/http://www.jaredandcoralee.com/CLIapps.html
http://macrofig.blogspot.com/

If you know of others, I'd love to hear about them.

One can also look for lightweight distributions and see what programs they have in their repositories or read their forums for more suggestions. Some of the interesting distributions to check are TinyCore Linux (uses several FLTK programs), Nanolinux (uses more interesting FLTK programs), Rogue Class Linux (uses several SDL programs), Puppy Linux, AntiX (Debian based), INX ( http://inx.maincontent.net/ ), Absolute Linux (Slackware based), 4MLinux ( https://sourceforge.net/projects/linux4m/ ), OLPC. Typically DSL and Puppy get mentioned when people list lightweight Open Source systems. There's been no active development on DSL in a long time and the forums are very quiet. I also found Puppy a little too resource intensive on one of my older machines. FreeBSD performed much better on that system. Puppy Linux has some interesting discussions in their forums.

Linux systems that work in framebuffer mode using DirectFB, nano-x and other alternatives also typically contain many interesting, unusual and lightweight applications. Nanolinux and Rogue Class Linux are in this category.

One can also look at operating systems and development projects that use more lightweight C libraries (such as uclibc and musl). Those projects typically gravitate to choosing lightweight applications, command line and console based programs and lightweight tools like Busybox and Toybox.

Alternative operating systems often offer interesting lightweight application choices. Syllable and Haiku often use SDL programs and other lightweight applications that are easier to port to those systems. Systems like Minix and ELKS are also interesting to investigate. Minix 3 uses a lot of the programs that BSD systems do, but earlier versions of Minix include some interesting alternatives. XFDOS includes many interesting FLTK applications. Plan 9 is interesting as well, but not many of the programs used on this system have been ported to other systems. Another good place to look for unusual applications is on mobile devices.
Here are some application lists from Syllable and Agenda:
https://sites.google.com/site/syllablesoftware/
http://agtoys.sourceforge.net/

I'd love to find more places to discuss lightweight applications. If you've written an article on the topic, please share it. If you know of a good blog, forum, mailing list or other resource, please let me know ( http://www.distasis.com/connect.htm ). If you'd like to discuss your favorite C/C++ applications further, you're welcome to check out the mailing list: https://groups.io/g/distasis I had a mailing list on Yahoo Groups called CppDesign, but Yahoo is no longer supporting mailing lists. So, the new list on Groups.io replaces my old lists on Yahoo Groups.

If you've tried to run Windows console programs (such as pdcurses based applications) using a terminal emulator (rxvt, mintty) via msys (including msys2), you'll probably have I/O issues. Output may not appear properly on the screen.

There are two work-arounds for the issue.

1. Use software from a project that deals with console/terminal incompatibilities.

Winpty - provides and interface similar to a Unix pty-master for communicating with Windows console programs.
https://github.com/rprichard/winpty

Alternative to MinGW and Cygwin and build scripts for various Open Source tools:
http://midipix.org/

2. Run the program in a console instead of a terminal.

I have an article on setting up msys to work with the standard Windows console instead of a terminal at:
http://www.distasis.com/cpp/msys.htm

For alternatives to the standard Windows console, take a look at these projects.

ConEmu Console emulator - Unlike Console 2, this has a build file for gcc.
https://conemu.github.io/

Console 2 - Command prompt replacement. May be used with cmd.exe or rxvt or other shells.
https://sourceforge.net/projects/console/

ConsoleZ - Console 2 fork with improved support for Windows Vista/7/8/10.
https://github.com/cbucher/console