X Windows is designed to work well on older systems or systems with minimal resources. However, it's quite complex to build from source. I've built it completely a few times. I've done so on Linux/BSD systems, but I've also built it natively for Windows. Despite the fact that it was designed when systems might not have a lot of resources (thus the client/server design), it still seems to run rather slow compared to other options such as the console or framebuffer. It also runs quite slow on Windows compared to native Windows applications.

Wayland looks like it will be a popular replacement for X Windows and it will also have backward compatibility allowing users to continue to run X Windows applications using XWayland. Wayland is designed specifically for Linux systems. So, it'll be interesting to see how much work it will take to get this going on other POSIX systems like BSD and how well it will be adopted by users of those systems.

Another alternative to X Windows on Linux is to use console or framebuffer based applications. Since POSIX systems multitask, you can run multiple terminals with an application in each. However, if you want more than one application on your screen at once or an easier way to switch between applications, you have to use a terminal multiplexer. Screen is the most well known, but there are several others such as tmux, dvtm, twin. There are also options like splitvt, terminator and mtm (Micro Terminal Multiplexer). This can be a speedy solution, but it's not always as intuitive to use as a windowing system such as X Windows.

DirectFB is another option. Unlike SDL 1.x which had backend support for the Linux framebuffer, the best solution for running applications in framebuffer for SDL 2.x is DirectFB. Despite it being an interesting project, the development site for DirectFB is no longer available. Even when it was available, the mailing lists for it weren't very responsive. There is a patched and working version of DirectFB among the Debian packages but with the advent of other options like Wayland, who knows how long it will continue to be included/supported by larger Linux distributions.

So if there still a viable middle ground between X Windows/Wayland and console/framebuffer applications? There are some other projects that might fill that void.

First off, I'd like to mention nano-x. It works on a variety of platforms. It has basic API support for porting X11 applications (with nxlib) and Win32 applications. You can use it to build single programs, but it can also be run in client/server mode similar to X Windows. That way, you can display multiple programs on the same screen. It's actively developed (even though the number of developers is small). XFDos (which runs on DOS/FreeDOS) and nanolinux are some good examples of what can been done with nano-x and just how portable it is. It also works on Android systems. On systems where X Windows won't build easily or just won't run, it's hard to beat nano-x.


If you want to create your own windowing system on the style of DirectFB or nano-x, I've seen some developers start with libraries like AGG. Typically the older 2.4 version is used because it's still available under the BSD license.


Finally, if you really want X Windows, but you still want something that uses less resources or might perform better on older systems, there are a fewer lighter versions of X that may be of interest.


There are other windowing systems, however, most of them aren't very portable and are limited to a particular niche operating system. Know of other portable Open Source windowing systems or other good options for POSIX systems like Linux and BSD? Please share the information. I'd be very interested to hear about them.


Mar. 18th, 2019 03:49 pm
TinyGL is a subset of OpenGL with a zlib license. It uses software rendering. For systems that cannot take full advantage of GPUs or high performance graphics drivers, TinyGL gives decent performance. It's been used on several small handheld devices and on less standard operating systems like Amiga clones and BeOS. It offers much of the functionality of OpenGL 1.1. PicoGL is a fork of TinyGL with several backends including SDL 1.2.x, nano-x, Vesa framebuffer and X11. More can easily be added. I've already added support for SDL 2.x. PicoGL also attempted to add fixed point support for systems that had issues with floating point representation.

I've been patching PicoGL since 2013 and have added several features. It's currently stable enough to use with an OpenGL application such as Emilia Pinball. I've looked at several TinyGL forks with similar licenses and attempted to add the best of these forks into my version of PicoGL. I've updated the math-ssl library to a later version that uses a MIT license instead of the original GPL 2 license.

Other modifications include switching to 32 bit internal representation. I added some missing functions. I coded support for blending textures. I fixed a lighting issue that's visible in the gears demo. The gears are now displaying as red/green/blue as expected instead of white/yellow/cyan. After a lot of research, I found a way to work with power of 2 sized textures that are represented with sizes other than 256 internally.

I still have several modifications I want to make. In order for simple font atlases to work, I needed support for glTexSubImage2D. I recently added that and it appears to be working as long as textures are sized by a power of two. I'm currently working on refactoring the texture related code and cleaning up how to handle conversions between different formats (such as RGB, RGBA, BGRA).

Was surprised that the various forks of TinyGL have not fixed many of the bugs in the code. After I fixed the lighting issue for the gears demo, I ran across a few forks that mentioned the lighting problem. I also found a texture mapping bug. It's very easy to notice when you're using a font atlas. I had a letter next to a box character. When drawing the letter section of the texture, it went over by one pixel in the x direction. The first pixel of the box was displaying along with the letter. None of the forks I've looked at have made mention of the issue. The bug is in the s and t transforms in the gl_transform_to_viewport code. Assuming the texture has a width of 8, then the code should transform the x texture coordinates ranging from 0 to 1 to the texture bitmap coordinates 0 to width - 1 which in the example is 7. The PicoGL code is attempting to convert from one coordinate system to the other and then shift left by 14. However, the formula is combining the coordinate transformation with the shifting into one formula. It takes the highest shifted coordinate as ZB_POINT_S_MAX and the lowest shifted coordinate as ZB_POINT_S_MIN. The TinyGL code looks like s * (ZB_POINT_S_MAX - ZB_POINT_S_MIN) + ZB_POINT_S_MIN. In the texture routine, the bits of the s coordinate are ANDed with a mask to remove fractions and then shifted back to get the transformed coordinate. The problem appears to be in how the transform and shift were combined in the formula. I believe the transform should be using 0 as the minimum and then doing the shift. The formula for the example texture should be (s-0/(1-0))*(width-1 - 0)+0 and then the shift is applied. That means the added minimum value should be 0 and even after it's shifted should still be 0. The maximum (width - 1) can be shifted once before it's multiplied with v to save time calculating (which is similar to what the original formula does). Thus, the formula should look more like s * (width - 1 << 14). Actually, the formula in the program is a little more complicated. It does the equivalent of adding in .5 to the maximum texture coordinate (width - 1) during the multiplication process for better rounding and then lops off the fractions from the result using a mask (in this case, width - 1 << 14) during the texture rendering phase before shifting the results to the right. However, I try to go through the formula or calculate this, adding in ZB_POINT_S_MIN in the original formula moves everything off by one pixel. The coordinate system should be 0 to width - 1 not .5 to width - 1. Fixing the coordinate system, fixes the bug. With a coordinate change in place, I no longer see an extra line of pixels when I use texture mapping to display parts of a font atlas to the screen.

It's difficult to find good documentation on how to create a rendering engine similar to the one used by PicoGL to render triangles and perspective correct textures. There really aren't any useful details on how the rendering works in documentation within TinyGL. That can make it difficult to figure out what the intention of the programmer was and whether there are any issues with the implementation (such as the texture mapping being off by a pixel) or whether they are 'intended features'. Best information I could find on how texture rendering engines work is in the Perspective Texture Mapping articles at http://chrishecker.com/Miscellaneous_Technical_Articles
There is also a discussion of some techniques here:
http://www.phatcode.net/~fb/forum/viewtopic.php?t=24889 If anyone runs across other good documentation on the subject, please let me know.

If there are any other projects, groups or developers using or investigating using TinyGL, PicoGL or a similar fork, I would love to share development ideas and code and/or discuss design issues. Have you worked with or done something interesting with PicoGL or TinyGL? Please let me know. I'm also in search of useful, portable applications that will work with a TinyGL or PicoGL backend. Have any favorites? Please share some details about them. Feel free to contact me: http://www.distasis.com/connect.htm
Along the lines of investigating portable C GUI libraries, I started looking at cross-platform library options for font rendering in C. This area is particularly useful if you're investigating creating your own GUI library or game library. I was most interested in the TrueType font rendering libraries and techniques. It was rather surprising to read just how difficult it is to get simple internationalized text to the screen especially using graphics libraries like OpenGL.

Here's what I've located. If you have other recommendations for C font rendering libraries, please let me know.

GUI library options like nuklear and nanovg use stb_truetype.h:
They also use some kind of font stash, such as this one used with nanovg:

Other GUI libraries use FreeType2.

For instance, SDL2_ttf uses FreeType2.

Allegro also has font libraries available that are based on FreeType2.

Here's one that works with Allegro or SDL:

There are several font libraries for OpenGL, but there aren't many options written in C. Some are for older versions of OpenGL and some only work with later versions. Here's what I found so far:


Here's another C option that works with FreeType2 and embeds fonts in C programs:

The most recommended technique used by OpenGL developers seems to be texture mapping. A texture can be used like a hash table to store various characters and other pixmaps that need to be rendered. An OpenGL function can draw a piece of the texture or update/change parts of it in memory without affecting performance too much. While software renderers have no real trouble copying or blending a bitmap graphic or pixmap, the newer OpenGL versions send the textures to the GPU for rendering. So utilizing a texture instead of bitmaps/pixmaps and minimizing the number of textures one is working with can improve performance.

I personally find it easier to render text with SDL. It handles copying and blending bitmaps (as an SDL_Surface) and offers a useful library (SDL_ttf) to do most of the work. SDL 2.x does use OpenGL underneath on some platforms, so some of the texture concepts used by OpenGL programmers might improve font rendering performance on some versions of SDL as well.

Freetype seems to be the library for working with TrueType fonts. SDL_ttf uses freetype to interpret the Truetype font format and create bitmaps/pixmaps to represent characters (converting them from vector format to bitmap/pixmap format). I found working with SDL_ttf a lot more user-friendly than trying to use Freetype directly.

Another viable option is stb_truetype.h. The license for this software is definitely an advantage. However, from what I've read the rendering still isn't quite as good as Freetype. I look forward to testing this out on my own at some point.

At this point, I'm still investigating SDL_ttf, stb_truetype.h and OpenGL texture mapping. A combination of these might be just what's needed in a font rendering design for a cross-platform GUI library.

Know of some other font rendering options that work well for Truetype fonts or have a better way to get fonts to the screen, I'd love to hear about it?
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.


SDL2_ttf provides TrueType text support for SDL.
SDL2_ttf provides internationalization support using a UCS-2 character set. I have patches to support the UTF-32 character set.




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.


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).


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


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.

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.


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.


This looks promising. Has several backends including GLFW, SDL, Win32, X11, SFML, allegro, 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.


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.

I've also seen some patches to GTK 1.2 to keep it more up-to-date.

XForms Toolkit



GUI toolkit for SDL.


GUI toolkit for SDL.


GUI toolkit using allegro.


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.









Microraptor GUI


Micro-GUI (ugui)



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.


Use with PDCurses, ncurses or similar libraries to provide common controls and widgets.

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 ( http://groups.yahoo.com/group/CppDesign ).
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.


Checkers and sudoku come with FLTK as examples.


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've have patches to make this work with the latest version of the FLTK library.



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







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.



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.


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


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.



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



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



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:
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.



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











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.


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.



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.


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.

I've been investigating Open Source C/C++ PDF viewers/rendering libraries. There really isn't a lot available out there. Most projects use poppler. It was developed as a fork of xpdf and is supposed to be somewhat more efficient than it. Both are licensed under GPL. The only other real competitor is mupdf. There have been some comparisons done on efficiency between mupdf and poppler and mupdf seems to be the clear winner. Just running mupdf versus a poppler based PDF viewer on a very large PDF file being viewed on a slow computer gives a good idea of the differences between the two. Mupdf was originally licensed under a GPL license and is now using AGPL which is even more restrictive. There are also commercial licenses available for poppler and mupdf which companies hope that projects will use if the GPL and AGPL licenses are too limiting. Projects would need to make all of their source code freely available if they want to include either of these libraries and don't want to purchase a commercial license. With AGPL, the source code needs to be available even if the program is not distributed, but it is used by someone over a network.

One possible alternative to these options is pdf.js ( https://github.com/mozilla/pdf.js ). The license is Apache 2.0 which doesn't require that you distribute your own source code. pdf.js as the name implies is written primarily in JavaScript. So, to run this with a C/C++ program, one could use an embedded web browser that can handle JavaScript. One such alternative that works with SDL, FLTK and other graphics or GUI libraries is the wkccc library (based on webkit) in Netrider ( https://sourceforge.net/projects/netrider/ ). Another alternative would be to convert the JavaScript code to C. This should greatly improve rendering efficiency and speed if done properly. It's an alternative I'm seriously considering should I need a PDF rendering library with a more liberal license at some point.

Since I just wanted a simple, efficient Open Source PDF viewer that I could freely distribute (along with its source code) if needed, mupdf seemed like a good possibility. However, I'd prefer to avoid AGPL licenses. Occasionally I see developers keeping an older version of an Open Source software project alive because they prefer the license used by the older version. When I ran across a GPLv2 version of mupdf at Github ( https://github.com/technosaurus/mupdf-GPL2 ), it encouraged me to consider the option of using an older version of mupdf with a more lenient license. I investigated using the GPLv2 version at github, however, it was missing several features of later versions of mupdf and it used jam as a build system. Going back to the last GPLv3 versions of mupdf provided many more features than the GPLv2 version plus a more standard build system. Searching for mupdf GPLv3 on github even yielded a handful of projects that went on to add new features. So, assuming ebook rendering isn't needed (and I already use applications like bard for that), the GPLv3 version of mupdf really has all the features needed for creating a fast, basic, cross-platform PDF viewer. My next step was to investigate what was working in the GPLv3 version, what was missing and what could be easily added using the various GPLv3 forks or other Open Source projects.

After further investigation and some prototyping, I now have a GPLv3 version of mupdf. It already had basic cbz support. However, I really wanted a cbr viewer as well. I have been searching for a decent, open licensed cbr library for a long time and I finally found an Open Source LGPL library that is part of sumatrapdf. I removed much of the cbz code in mupdf and substituted code that uses the unarr library from sumatrapdf for cbz and cbr access. If one can view graphics in cbz or cbr format, one can also view graphics that aren't archived, so I made sure support for that was working properly. I also added support for SVG format using nanoSVG. Viewing SVG files with a later version of the mupdf application and comparing that with my results, my version actually seemed to do a better job using the nanoSVG code for rendering than the mupdf AGPL licensed rendering engine did.

I happen to like the Unix philosophy of finding and working with programs that do one thing well. Since unarr is LGPL licensed, I realized I could have a cbz/cbr viewer completely independent of any mupdf code and the whole project could be licensed under LGPL. I have the basics working with unarr and SDL, I just need to create a user interface to handle choosing files and navigating through the pages. However, my original goal was a PDF viewer. It would still require a library such as mupdf whether I split off cbz/cbr viewing functionality or not. That currently leaves me with two choices for PDF viewing. I can use the mupdf GPLv3 library with a mupdf or custom SDL front end or I can attempt to port a library such as pdf.js to C and create a SDL front end for it.

I can't help wondering if I'm the only person looking for a lightweight, efficient, C based Open Source PDF viewer that can be used with a Linux distribution (or on other platforms when needed). There are some interesting lightweight Linux distributions being developed with goals such as working on older computers or making the most of their hardware. There are projects where developers build everything themselves (such as Linux from Scratch). Simple to build programs with limited dependencies are often preferrable in those cases. There are some alternative free operating systems in the works (like FreeDOS and Haiku). There are also users who like to specialize in finding light, efficient, limited dependency software for their desktop computers. Plus, with cross-platform programs, it would be nice to run the same familiar software on mobile devices as well as on desktops and laptops. Considering all that, there should be other developers and users who might be interested in similar goals. If that's true, I'd love to hear from you and compare ideas on how best to accomplish the goal of creating a simple, lightweight Open Source C PDF viewer. You can contact me via the CppDesign mailing list ( http://groups.yahoo.com/group/cppdesign ) or other methods and share notes on development and building software. It would be nice to combine resources on a project of this nature. Would also be happy to discuss finding/working on/building other useful, lightweight Open Source C/C++ projects.

I haven't fully decided which way to go for a PDF viewer, so I haven't made my source code enhancements to mupdf (GPLv3) available as yet. Not much point taking up web space to share code if no one's using the project at all. If there are others interested in this route, please let me know.
Wanted to wish everyone a Happy Halloween. Check out the Halloween Holiday Tour at:

Catch it before it mysteriously disappears next month.
I've been searching technical books and articles to find out more about writing programs for Android using the native development toolkit (NDK) and C/C++. Finding relevant information is extremely difficult. Most sources just say to use Android Studio (or for older articles, use Eclipse) and do not go into any details as to how things work beyond the IDE or wrapper script. It's extremely difficult to find documentation that explains what's going on underneath.

I'm working on porting some Open Source projects already written in C/C++ to Android. So, I find it extremely frustrating when the typical advice I read is to avoid the NDK and use Java (or Kotlin). References that state that usually go on to say that Java (or Kotlin) really is not that much slower than C/C++, so you would be getting no significant gain in performance by using it. That leads me to believe that there has to be some gain in performance (even if it is not what the authors deem 'significant') or the articles wouldn't be mentioning that C/C++ was considered faster in the first place. Such articles typically go on to state that it's much harder to work with the NDK and one is better off using languages recommended by Google. However, for developers who prefer C/C++ over Java or Kotlin development and who are already aware of potential pitfalls of the C/C++ languages and how best to avoid them, those developers could be far more proficient and productive using C/C++ over other options. So, why recommend avoiding the NDK and C/C++? Why not encourage developers to use the languages and tools they can leverage to their best advantage?

Speaking of using tools that developers are most productive with, I already have a cross-platform build system that greatly reduces the time I spend building and porting Open Source libraries. I wanted to be able to use my build system. However, IDEs (like Android Studio) don't integrate well with automated build systems. It took a lot of digging through articles and books on Android, but I was pleased to find out how to create a standalone tool chain to build Android C/C++ applications.

I was surprised at the lack of support for cross-platform compiling of certain Open Source libraries. It's difficult to find Android builds and patches to common Open Source libraries. Also, based on my experiences porting Open Source projects to Windows, I wonder how many Open Source library developers would welcome adding patches to make builds of their libraries for Android work out of the box. My past experience has proved that many library developers would prefer not to add support for more platforms. That means I'll probably end up adding my patches to my LM BLD scripts ( http://www.distasis.com/cpp/lmbld.htm ) rather than seeing the fixes I've submitted added in to the libraries themselves.

So, as I work my way through porting various Open Source applications to Android, I thought I'd share the few useful resources I found that help clarify how to build and share C/C++ Open Source applications on Android.

The best documentation I've located to date and the one I'd refer anyone interested in C/C++ programming for Android to is this one:
It explains where to get the NDK and other needed libraries. It walks you through how to create an Android package (apk file) via the command line. It gives a good example of how to build a C application that can get a developer started.

If you're on a Linux system, you can use the package manager to download a version of Java. You'll need it to create Android packages. For Windows users, one option is to download a portable version of Java and make sure it's in your development path.

The Android developer web site actually has some decent information on how to create a stand-alone C/C++ toolchain. You currently need Python to create the toolchain, but they actually supply a version of Python for operating systems that don't easily offer one.
See also:

When creating the stand-alone toolchain, you'll need to know what API you're targeting. More information on that is provided elsewhere:
Typical choices are to target the latest if you want to use all the newest features in Android or target an early enough version that the results will work on a majority of the Android devices out there. Which version is best will change over time as the majority of users buy newer devices and new innovations are added to newer APIs. Even though you mention the API when creating the standalone toolchain, the only place the information seems to be stored is in the llvm wrapper. So, you may need to add -D__ANDROID_API__ and the API you want to support to your compiler flags.

You'll also need to decide whether you want to target 32 or 64 bit platforms. Keep in mind that 32 bit code will work on 64 bit platforms, but the reverse is not true. There seems to be better support for large file access on 64 bit platforms though. Note that Google is pushing for latest API targets and 64 bit support for projects that will submitted to the Google Play Store. You'll need to build your application for each target you wish to support. So, if you want your programs to work on Android devices with arm chips or x86 based chips, you'll need to build libraries and applications for more than one system.

Google is also moving toward unified headers so they don't have to support a version of the C and C++ header files for each API they support. Depending on what version of the NDK you're using, you may want to add --unified-headers when creating your standalone toolchain.

I find it useful to know what native C/C++ functionality/which libraries are supported for various versions/APIs of Android:

I thought this site had a good series of posts on how to port a SDL based application to Android:

If you're interested in using dynamic libraries, this site had some useful information:

Testing the results you built may be difficult. My experience with using MoSync to build C/C++ Android applications showed how slow testing an application with an emulator could be. If you install Android Studio, it gives the option to install Intel HAXM (hardware accelerated execution manager). This can help speed up Android emulation. You can find HAXM and more information on it at the Intel web site.

You can also use VirtualBox and an Android virtual machine image for testing.
Android-X86 ( http://www.android-x86.org/ ) can provide images that work with targets compiled for x86 machines.

Another option is to use adb (Android Debug Bridge) to test the results on an actual Android device. Here are a couple of articles that give examples of how to work with adb:

One thing to keep in mind if you're going to test on your own Android device is that Developer options must be activated on that device first. Here's an article on how to do that:

You can also build or access Open Source console applications (even without turning on developer options) when you have a terminal emulator app installed on your system. This gives applications you're running in the terminal emulator (even one's you've built from source) the same rights at the terminal emulator. You can use command line or console based applications (such as those built with pdcurses/ncurses/netbsd-curses) with a terminal emulator. There are several terminal emulators available from the Google Play Store or F-Droid. Try some out and see which you like best.

One of the terminal emulator projects has a github project with information on some common Open Source library packages including commands for building and patches needed to compile. One thing to watch out for is that some of their patches are made directly to the standalone toolchain header files. If you don't have similar patches or add extra patches to the library's build script, you may not be able to compile successfully. One of these fixes is to help work-around 64 bit file handling support on 32 bit systems. Some Open Source projects don't build properly or need major work-arounds to handle this with earlier versions of the Android API for 32 bit systems. More information on how the Termux terminal emulator project builds their Open Source libraries and programs is available at their github site:

Another interesting resource if you want to see how various C/C++ projects are built and what patching might be needed is this one:
It uses SDL 1.2/1.3 ported to Android and includes several Open Source libraries and several popular Open Source applications including DOSBox, Milkytracker, grafx2 and a SDL based X server.

A developer I correspond with wrote his own tutorial on how to build C/C++ applications using Allegro and Nano-X. He covers a lot of useful material about the NDK and C/C++ development including how to call Java functions from C/C++ and vice versa. He also explains how to use Allegro on Android.

Libraries such as SDL, Allegro and Nano-X provide support for building GUI applications on Android. Nano-X offers a subset of X11 functions so GUIs like FLTK and WxWidgets will work. PDCurses can be used in conjunction with SDL. Applications built using any of these libraries could potentially be ported to Android. Not all C/C++ applications provide interfaces that are user friendly for Android or for smaller screens and devices that may lack physical keyboards. However, if you create a well designed, portable interface for your program, there's no reason why it shouldn't work well on Android systems as well as PCs (Linux, Windows, BSD, etc.). Here's more information on some GUI libraries that work on Android:

That's pretty much all my searches have turned up as far as resources I've found useful for building C/C++ applications targeted to Android devices. If you have other reference recommendations that explain how things actually work (rather than glossing over the details and using a GUI interface), please let me know. If you'd like to share or compare notes on patches, compiler/linker options for building various Open Source libraries and applications, I'd enjoy hearing from you. You can discuss C/C++ Android development further with me and other interested developers on the CppDesign mailing list.
I only recently checked the OpenSSL site and found out that they've changed their license from 4 clause BSD to an Apache style license. Many sites mention a license conflict between BSD 4 clause licenses and GNU GPL licenses. Several programs I use try to avoid the issue by adding a waiver to their license to allow linking with OpenSSL. Some examples are Dillo and D+. The issue can also be avoided in many cases by using software with a license other than the GNU GPL. So, the new switch to an Apache style license solves the license conflict issue in many cases (although it may cause new license conflict issues).

There's a useful reference on license information at the curl site:

There was an interesting thread about the GPL/BSD 4 clause license conflict on the lynx development list. Various SSL library options such as OpenSSL, gnutls and nss were discussed. It was mentioned that parts of the gnutls library (the compatibility layer) was licensed under GPLv3 which is incompatible with GPLv2 only ( https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ). The thread concluded with a recommendation to use the nss library to avoid license conflicts. It also mentioned that contacting everyone who worked on the project to re-license lynx would be too difficult. I guess there was some accommodation made after the thread because the latest version of lynx includes a COPYHEADER file that includes permission to use libraries such as OpenSSL and gnutls.

With the license change to OpenSSL, I hoped that the various license issues one might run across when building and distributing software that need SSL support had been solved. I've been using OpenSSL for a long time and it's always been highly portable and worked on a variety of platforms. However, when I downloaded the latest version of OpenSSL, I found that was no longer the case. With the various OpenSSL security issues in the news, work has been done to update the library and make it more secure. It appears, in this particular case, the security enhancements have come at the cost of portability. I used to be able to build OpenSSL using the ActiveState version of Perl. Now, OpenSSL is designed to only allow use of ActiveState or Windows native Perl builds using the Visual C++ compiler. If I continue to use the mingw compiler, I need a msys or cygwin based version of Perl. I'd previously built OpenSSL for DOS with no issues. Looking through some of the code, I'm afraid to even give it a try with the latest version of OpenSSL. OpenSSL is also much more dependent on Perl than it used to be. If I'm building a C library, it would be nice if it was only dependent on C code to build instead of requiring an interpreted language that's rather complicated to build.

I found it was time to either redesign my build of Perl (since a native Perl could no longer be used with MinGW to build OpenSSL) or to look for a new SSL library alternative. I'll share some of the results in my search for SSL library alternatives.

The major SSL options are OpenSSL, gnutls (with GNU GPL license) and nss (from Mozilla with Mozilla Public License). There are OpenSSL compatibility layers for gnutls (GPLv3 license) and nss ( Nss_compat_ossl originally from Fedora and no longer supported ). From some of the articles I read online, OpenSSL and nss were mentioned as more secure than gnutls. I also read that gnutls was a popular option on certain Linux systems such as Debian.

However, these aren't the only SSL libraries. There are several other options for embedded systems and other specialty uses. It's actually hard to track the options since the names of some of them keep changing. Typically, a program needs to offer support specifically for one or more of these library options because there usually isn't a compatibility layer to use that SSL library in place of a more common SSL library. Curl is a great example of a program that supports multiple SSL library options. D+ included support for cyassl. However, cyassl is now known as wolfssl. axtls looked like an interesting possibility because of its BSD license. It supposedly builds on Windows, but I didn't have any luck with it. Of all the various lightweight and/or embedded options, the only one I was able to get to build out of the box on Windows was mbedtls (formerly polarssl). mbedtls is available under a GPL license. Rather than try to track all the options and library name changes, I'll refer to the Wikipedia list:

After the recent security issues with OpenSSL, there were also forks of OpenSSL. These include LibreSSL (a fork by the OpenBSD developers) and BoringSSL (by Google). I tried building BoringSSL, but it required an interpreter (similar to OpenSSL), so why not stick with OpenSSL instead of switching to BoringSSL. I also tried building some of the various SSL options with cmake and had no luck at all.

I'd tried building LibreSSL in the past with no luck either. The fork was originally just designed for BSD systems and support for other platforms was added later. There are even some posts on the Internet about how early versions of LibreSSL include issues that made it insecure on Linux and other non-BSD systems. Once support was added for other platforms, I ran into an issue with what platforms were supported. The developers only supported the MinGW64 project on Windows. I use a version of MinGW based on an earlier version of the original MinGW which has a more lenient license. I've been adapting the mingwrt and w32api libraries, but they're based on the original public domain licensed versions of the libraries. So, when I previously tried to build LibreSSL, it wasn't compatible with my MinGW compiler. However, after the various changes to OpenSSL, I decided to give LibreSSL another try. Was pleasantly surprised this time when it only required minor patching with my particular version of MinGW in order to get it to build. It also uses the standard GNU autotools style configure/make/make install rather than requiring Perl just to configure and build it. If anyone's interested in the patches, feel free to contact me about getting a copy.

At this point, I'm considering switching to the LibreSSL fork. Several Linux distributions that use musl as their main C library are using LibreSSL as their SSL library of choice. They included patches to get various libraries and programs to build with LibreSSL instead of OpenSSL. There are also some patches at the LibreSSL site.

However, there are still some issues with switching. Many of the programs that included a waiver for OpenSSL, do not provide a similar waiver for LibreSSL. I certainly be interested in hearing how others are handling this particular issue. It would be nice if LibreSSL users could contact some of these projects and ask about a waiver for LibreSSL as well as OpenSSL. Some of the projects that come to mind are D+, Dillo, lynx, opusfile. Curl, libarchive and libssh2 can also use LibreSSL instead of OpenSSL, but there aren't any issues with license conflicts unless one adds a GNU GPL licensed library or a similar incompatible license to the mix.

I'd be interested to hear what others use as their SSL library of choice when building cross-platform applications and why they chose that particular library. You can find further discussion of this topic on the CPPDesign mailing list ( http://www.distasis.com/connect.htm ).
Was at a PHP meetup where the group was discussing Docker. Members and the presenter knew certain Linux distributions had a smaller footprint for use with Docker. I was surprised to find out they really didn't know why that was. One of the key factors is the C runtime library. Basic C runtime libraries just cover the functions and data structures that are part of the ISO C standard. Many C runtime libraries also add functions and data structures that are part of the POSIX standard as documented by the Open Group. Some C runtime libraries are rather bloated and provide a wide variety of functions (even beyond those documented by the ISO C and POSIX standards). Others provide a bare minimum. Some, especially those targeting embedded systems are designed for efficiency. Others are designed for functionality. Some provide no Unicode support (locale 'C' only). Some like musl, concentrate on UTF-8 support. Some try to support a large variety of characters sets and internationalization features. All these factors can affect code size and efficiency when compiling programs.

Alpine Linux previously used the uclibc runtime library and now uses the musl library. Most major Linux distributions use glibc. It was a big step, but a positive one when Debian (and Ubuntu) made the switch to eglibc. The choice of C runtime library can make a huge difference for the operating system.

For Windows developers, if you're using MinGW, the GNU compiler on Windows, you're using the Microsoft runtime libraries. The original version of MinGW used crtdll.dll but later versions use msvcrt.dll. Windows systems typically have one of these runtime libraries already installed. So while, you can't distribute Microsoft's libraries, you really don't have to. At least one is already on any particular Windows system. It gets even more complicated because different versions of Windows have different versions of msvcrt (such as msvcr70.dll, msvcr80.dll). MinGW uses a subset of the runtime functions based on Visual Studio 6.0. There are ways to access runtime functions from later versions of Visual Studio, but the application becomes less portable to various versions of Windows. Cygwin which also works on Windows, avoids the problem of dealing with multiple Windows runtime libraries and dlls and provides better POSIX compatibility for their runtime library by using a runtime library based on newlib.

There are a wide variety of runtime libraries designed for embedded systems. They're typical more compact and less bloated than a library like glibc and many are easier to port to various platforms. Of the runtime libraries available for embedded systems that are highly portable, I thought the newlib design was interesting. newlib is currently maintained by Red Hat. There are a limited number of syscalls (typically functionality provided by the kernel) that one needs to provide code for to get the library to work. Newlib uses a combination of public domain and BSD style licenses. Cygwin uses a runtime library derived from newlib, but adds several POSIX functions. It also uses a GNU GPL license. That means whenever you distribute programs linked with their runtime library you must also distribute the source code in order to be compliant with the GPL license.

As mentioned, the standard C library on most Linux distributions is glibc which was developed by the Free Software Foundation. The glibc project was slow to take patches and is a rather large library, so some distributions switched to eglibc which is binary compatible with glibc. The binary compatibility makes it easy to switch between the two. Some Linux distributions wanted to avoid bloated C libraries and work well on low resource or older systems. They chose uclibc which was designed for embedded systems. When I worked with a uclibc based distribution, I found myself making several patches to Open Source programs just to get them to compile. Many Linux distributions such as Alpine Linux are now using musl. It's designed for efficiency and standards compliance including full POSIX standards compliance.

musl was designed to work with a Linux kernel. So unlike choices such as newlib, it is not easy to port to other operating systems. The midipix project is endeavoring to create a POSIX compatible layer for Windows, so that musl will work out of the box on that system. Musl uses a MIT license. The midipix project will use a more restrictive license similar to Cygwin. Many basic embedded system libraries tend to use less restrictive licenses like MIT and BSD so that they will be adopted by companies. However, project or company adapts a C library to a particular system and adds a lot of functionality, they typically tend to use GNU GPL or other more restrictive licenses. Many projects dual license in hopes of selling companies a commercial license with less restrictions.

Google developed the Bionic C library for it's Android operating systems. It has a BSD license. It's also designed to work on low resource systems so it tends to offer less functionality than other C libraries such as glibc. It has partial POSIX support.

I've been hitting many limitations with the MinGW runtime libraries when it comes to porting. Alternatives such as Cygwin's or midipix's runtime libraries would overcome the issues. However, the licenses are much more restrictive. I know I definitely wanted more POSIX compatibility on Windows than MinGW offers out of the box. As a cross-platform programmer, it would be nice to take whatever C runtime library I end up with on Windows and reuse it on Linux and other systems. I looked at C runtime libraries for embedded systems which typically port well. Of those, newlib seemed the most interesting, because according to some of the documentation it only requires 17 syscalls to port it to an operating system. Some Windows CE compiler ports use newlib with added functionality for the Windows CE operating system to derive a working C/C++ compiler. When I investigated the newlib code, I did not particularly like the design, especially the way it handled threading by providing standard and threaded versions of functions. The implementation of file I/O looked like it had been modified several times and at this point could use a major refactoring. When I read some of the comments in that section of the code, I felt very uncomfortable using the library. I wanted a simple, clean, basic design that I can add to.

Another option I looked at was PDClib. I love the idea of a public domain library. MinGW original licensed their WIN32 and runtime code (which integrates with Microsoft's code) as public domain.
PDCLib was based on an earlier Public Domain library project originally at Sourceforge. I tried PDClib on Windows (which the developer says he uses it with), but I was unable to get file I/O to work properly. I contacted the developer to see if he needed with the project, but he really didn't seem to need any assistance at the time. PDClib only supports standard C functions. It does not provide any POSIX functionality. So, it would have limited usage as is for running most Open Source programs.

A number of original operating systems use their own C runtime libraries. I figure, if they can reinvent the wheel and create a C runtime library for their particular purposes, so can I.

I've been coding functions that are typically part of the C runtime library in order to provide better porting support for Windows. I wrote a C11 compatible thread library, several BSD and POSIX string functions, some POSIX file functions, etc. That left me with the dilemma of how best to integrate the additions with the runtime library. They really should be part of the library and part of the C standard headers. I currently have them implemented as supplemental libraries that have to be added separately. It's easier to test and integrate on various operating systems that way. Ideally, it would be nice to have everything accessible as one library though.

I'm very familiar in the various methods of connecting to the kernel in Windows. Some projects such as midipix just use ntdll.dll. Other projects connect to other Microsoft dlls such as kernel32.dll. One can use LoadLibrary, GetProcAddress to connect t a dll or if the library is already linked in, one can skip LoadLibrary. A few Open Source projects I've seen actually implement the LoadLibrary functionality from scratch. I'm not as familiar with the techniques to connect to the Linux, BSD and other kernels and would love to find more clear documentation on this subject. If you run across any good materials, please let me know ( http://www.distasis.com/connect.htm ). Linux uses techniques such as vdso, vsyscall, syscall to call kernel functions.

I find it fascinating to consider the design trade-offs of various C runtime libraries. With that in mind, here's a list of some of the C runtime library options:


Linux from Scratch build instructions (including musl)
BSD regular expression library
(Musl regular expression support was forked from this library.)

Original Public Domain C library:
libTom Public Domain libraries for math and cryptographics functions
(Some of musl's functions were forked from these.)



Windows CE cross-compiler:




Embedded Artistry's libc:
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:

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.

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:

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:

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.

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:

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.
The last post mentioned other groups' projects with dictionaries and language resources. I thought I'd mention some of the projects I've been working on in this area.

I've been creating build scripts with the LM BLD project ( http://www.distasis.com/cpp/lmbld.htm ) so that I'll have automated, repeatable steps to build programs, libraries and other types of packages. Here are some of things I've been working on.

The Moby project is a very nice dictionary resource. Using their thesaurus, I was able to create a word list and a simple dictionary in stardict format. I use it with Open Source programs like scramble.

The Strongs concordance is in the public domain. I've created a translation dictionary in stardict format with it.

I happen to like the stardict dictionary format. There are several nice programs that can work with that format. I wanted something lightweight that would work well on older systems or let me create my own GUI interfaces. The closest thing I could find to what I wanted was sdcv. However, there were a few issues I had with it. The biggest is that it requires glib as a dependency and I didn't want to install GTK+ related dependencies on my systems. The second issue I ran into was that it couldn't handle some of the newer versions of the stardict format. Since the code is GNU GPL licensed, I started with it and made several modifications and customizations. The result is sdcv2 which can be linked to my own Unicode shared libraries in place of glib if desired and can work with dictionaries in more recent stardict formats. It may not make use of all the latest features in the newer formats, but it can at least access information from them.

I've seen other projects that use the sdcv library as a back-end and create their own GUI for a dictionary program. It makes sense if the program uses GTK+, but it seems awkward for Qt or other GUI programs to require GTK+ related dependencies. With sdcv2, there are no GTK+ related dependencies.

I would love to find a dictionary with a FLTK GUI, especially if it can handle stardict format. Since, I haven't been able to find one, I may try to write one at some point. I've also been thinking about creating a pdcurses front end. When I use sdcv (or sdcv2) from the command line, certain systems like Windows can't handle input or output of certain Unicode characters correctly. I've added support for SDL 2.x, SDL2_ttf and the ability to work with a range of Unicode characters within the UCS-2 character set to pdcurses. I think pdcurses would make an interesting front end for a program using the sdcv2 library. It would work on any system that supports SDL 1.x or 2.x, including more unusual operating systems like Syllable and Haiku. Would like to hear from others who may be interested in or are working on similar projects.

The dictzip program compresses dictionary files. It uses an extension to the gzip format with extra fields to include information about the compressed dictionary. Files compressed with this format often use the .dz extension. You can use dictzip with stardict files to save space. dictzip is primarily a POSIX compliant program, so it doesn't convert well to certain systems. I was able to find a Windows port that limited the program's functionality, but did enough to get the job of compression done. I've made some modifications to it and am using it as a cross-platform method of compressing stardict dictionary files.

Several utilities and conversion programs were created for stardict in the stardict-tools project. Similar to stardict and sdcv, glib is a dependency for stardict-tools. There are a few tools that use a GTK+ front-end as well. I personally only use the stardict-tools to convert tab delimited files and files in babylon format to stardict. So, I modified the command line tools that do those conversions to build without glib. I also created my own makefile just to build the tools I use.

I've searched and I've yet to find a rhyming dictionary in stardict format. So, I'm working on creating one. It's a slow process. I've taken a public domain rhyming dictionary as a starting point and I'm in the process of editing it and converting it to the format I need.

I've also been searching for an Open Source C/C++ grammer checker, but I've yet to find one that I like.

These are just some of the projects I'm working on. If you're interested in comparing notes on these topics or if you have recommendations of other dictionary and word related projects you like, feel free to contact me ( http://www.distasis.com/contact.htm ).
It's hard to find public domain, Open Source and Creative Commons licensed language resources in formats that are easy for programs to work with. There are growing resources of scanned public domain books. Among them, you can find all kinds of dictionaries and references. Some sites even use an OCR to translate scanned documents to text formats. However, the translated versions are usually full of typographical errors.

There are a few projects out there that use Free, Open Source or Creative Commons licensing and have a goal of creating dictionaries or other references in accessible and searchable digital format, but not a lot. It would be nice to see more projects of this sort. The results could be useful with word processors and editors (such as LibreOffice, Abiword, SciTE), electronic dictionaries (such as stardict) and games (such as anagramarama and scramble).

Here are some of the projects I've located:

XDXF, the XML dictionary interchange format, project had a collection of dictionaries and language translation word lists they were working with and converting to various formats.
They also have tools for converting between XDXF and other formats:

The Moby project is a wonderful public domain resource. It includes word lists, thesaurus and more.

The Free Dictionaries Project also provides downloads. If you want to translate one language to another, this is a useful, free resource:

SCOWL (Spell Checker Oriented Word Lists) and Friends has useful word lists and resources for spell checker utilities:

YAWL (Yet Another Word List) is based on the updated Public Domain ENABLE (Enhanced North American Benchmark Lexicon).
You can also find Libre licensed word lists in FLOSS games such as anagramarama.

Here's a rhyming dictionary (source code and online example) that uses Moby project resources to find rhymes:

If you know of other projects or developments in this area, I'd love to hear about them ( http://www.distasis.com/connect.htm ).",public,0,,
16253,2017-03-28 07:59:00,2017-03-28 11:59:20,"My projects with rhyming and language translation and other dictionaries, word lists and thesauri","The last post mentioned other groups' projects with dictionaries and language resources. I thought I'd mention some of the projects I've been working on in this area.

I've been creating build scripts with the LM BLD project ( http://www.distasis.com/cpp/lmbld.htm ) so that I'll have automated, repeatable steps to build programs, libraries and other types of packages. Here are some of things I've been working on.

The Moby project is a very nice dictionary resource. Using their thesaurus, I was able to create a word list and a simple dictionary in stardict format. I use it with Open Source programs like scramble.

The Strongs concordance is in the public domain. I've created a translation dictionary in stardict format with it.

I happen to like the stardict dictionary format. There are several nice programs that can work with that format. I wanted something lightweight that would work well on older systems or let me create my own GUI interfaces. The closest thing I could find to what I wanted was sdcv. However, there were a few issues I had with it. The biggest is that it requires glib as a dependency and I didn't want to install GTK+ related dependencies on my systems. The second issue I ran into was that it couldn't handle some of the newer versions of the stardict format. Since the code is GNU GPL licensed, I started with it and made several modifications and customizations. The result is sdcv2 which can be linked to my own Unicode shared libraries in place of glib if desired and can work with dictionaries in more recent stardict formats. It may not make use of all the latest features in the newer formats, but it can at least access information from them.

I've seen other projects that use the sdcv library as a back-end and create their own GUI for a dictionary program. It makes sense if the program uses GTK+, but it seems awkward for Qt or other GUI programs to require GTK+ related dependencies. With sdcv2, there are no GTK+ related dependencies.

I would love to find a dictionary with a FLTK GUI, especially if it can handle stardict format. Since, I haven't been able to find one, I may try to write one at some point. I've also been thinking about creating a pdcurses front end. When I use sdcv (or sdcv2) from the command line, certain systems like Windows can't handle input or output of certain Unicode characters correctly. I've added support for SDL 2.x, SDL2_ttf and the ability to work with a range of Unicode characters within the UCS-2 character set to pdcurses. I think pdcurses would make an interesting front end for a program using the sdcv2 library. It would work on any system that supports SDL 1.x or 2.x, including more unusual operating systems like Syllable and Haiku. Would like to hear from others who may be interested in or are working on similar projects.

The dictzip program compresses dictionary files. It uses an extension to the gzip format with extra fields to include information about the compressed dictionary. Files compressed with this format often use the .dz extension. You can use dictzip with stardict files to save space. dictzip is primarily a POSIX compliant program, so it doesn't convert well to certain systems. I was able to find a Windows port that limited the program's functionality, but did enough to get the job of compression done. I've made some modifications to it and am using it as a cross-platform method of compressing stardict dictionary files.

Several utilities and conversion programs were created for stardict in the stardict-tools project. Similar to stardict and sdcv, glib is a dependency for stardict-tools. There are a few tools that use a GTK+ front-end as well. I personally only use the stardict-tools to convert tab delimited files and files in babylon format to stardict. So, I modified the command line tools that do those conversions to build without glib. I also created my own makefile just to build the tools I use.

I've searched and I've yet to find a rhyming dictionary in stardict format. So, I'm working on creating one. It's a slow process. I've taken a public domain rhyming dictionary as a starting point and I'm in the process of editing it and converting it to the format I need.

I've also been searching for an Open Source C/C++ grammer checker, but I've yet to find one that I like.

These are just some of the projects I'm working on. If you're interested in comparing notes on these topics or if you have recommendations of other dictionary and word related projects you like, feel free to contact me ( http://www.distasis.com/contact.htm ).
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:
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:

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:

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 use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum.
I've been looking for useful, efficient, user-friendly alternatives to build tools like GNU autotools and cmake. I've even created lists of build tool alternatives at various wikis and sites related to programming and compilers. If there's interest, I can post some of that information here along with pros and cons of various tools. I think, during my searches, I've found some good alternatives for my own projects and to use with my own build script generator.

If you're looking for build tools for your own projects, you may want to try the following tools. I'm also doing some active development and patching to some of the tools and would be interested in comparing notes with others on ways to use and improve them (see below for details).

GNU autotools is probably the most popular build system for most C/C++ programs. So, what's wrong with it? Just to build a C program, you need two interpreters (m4 and Perl). You also need autoconf, automake and make. The input to these programs is not necessarily intuitive to a C programmer. Many C programs, especially those using Qt make use of cmake which has less dependencies, but I've also found it less than intuitive. What if you want to build a system from scratch. You can get make to build without any other build tools. I've done it. From there, you can work to build the rest of the gnu autotools toolchain. To build cmake, you need to bootstrap the build using another instance of cmake. So where do you get the original build of cmake for the system? There is a way to build cmake with gnu autotools, but I've found it rather buggy.

After looking through several make alternatives, I really have not found a good replacement for it. The syntax takes some getting used to, but I've been able to find ways to get it do whatever I need it to do. There are situations where make is very inefficient, but there are work-arounds. Efficiency really depends on how well you craft your makefiles. I attempted to find some alternatives to the GNU version of make. BSD make has very different syntax, so only the simplest make scripts work with both tools. I find GNU make used more often than BSD make for building Open Source projects and it has features that were never added to BSD make. There's a Perl implementation of make, but that requires a Perl interpreter. My main issue with GNU make is that it is only supported on certain platforms. I sent in a bug report about GNU make not working properly on native Windows and I even sent in a patch. The developers were not interested in supporting native Windows. They thought it was enough that there were versions that worked with Cygwin and msys. Unfortunately, I've yet to find an alternative to make that handles the GNU makefile sysntax and doesn't require installation of an interpreter.

I've decided that until I can find anything better, I will continue to use GNU make. Since it is Free Software, I can modify the code to work on other systems that GNU make developers don't care to support. I can distribute the modified version if I distribute the source code. So, I use a modified version of GNU make that fixes platform specific bugs that I've encountered.

After searching through many alternatives, I've found a wonderful replacement to configure/autoconf. It's also more compact and I find it more intuitive than cmake. It's called CDetect. It's written in C and is comprised of only 3 files. The project is no longer actively developed. However, I've been making several modifications of my own to get it to suit my projects' needs. I've implemented some of the items on the original developers To Do lists. I'm still making modifications as I find features that are lacking, but it makes a useful replacement to configure. I've converted some of the Open Source projects I build from source regularly to use CDetect and custom makefiles instead of their build systems. If you're building from source, such as with a Linux from Scratch system, using CDetect means you don't need Perl, and several other programs installed just to build a C/C++ program.

Freedesktop.org advocates the use of pkg-config. It's used by many GNU projects as well. While I originally thought it was yet another complication when building from source, I've found pkg-config rather useful in simplifying build scripts. You don't have to worry about finding the right library, pkg-config can tell you where to find it. If you're cross-compiling, you can get have two sets of directories with pkg-config information, one for cross-compiled libraries and one for regular libraries. Change the path in an environment variable and your build script knows where to find the appropriate libraries. What I really didn't like about pkg-config was the complexity of the program and that it required a circular dependency with glib. I don't even want glib on my system at this point. Luckily, there is an alternative with friendly licensing called pkgconf. It's a drop in replacement for pkg-config. It's very helpful in finding where the right libraries are on a system. I've gone from never using pkg-config to use pkgconf in almost all my build scripts.

So, between CDetect, pkgconf and make, I now have all the tools I need to use with my build system in order to build the Open Source programs and libraries I use most in an automated fashion. The tools are all written in C, so they require no special interpreters or other languages just to build them.

If you'd like to try out CDetect with my patches or see some of the build scripts I'm using with these tools, check out the archive link on my LM BLD system page:

I've added several features to my patched version of CDetect. Check the notes.txt file for details. I'm currently making some new modifications and would love input from other developers/users. If you'd like to make suggestions or compare notes, please contact me through the CppDesign mailing list or my web site:
There are some great Open Source applications out there for desktops and laptop machines, but it's much harder to find Open Source for mobile devices. Most mobile devices require their users to go through a proprietary app store just to get software onto their devices. This is a setup back for the Open Source movement since more and more people are turning to mobile devices as their primary computing source.

If you have suggestions and/or recommendations for FLOSS alternatives in the mobile space, please share them with me and other Free, Libre and Open Source advocates on the Schoolforge mailing list ( https://schoolforge.net/ ).

I'll share some Open Source options I've found to date for developing mobile and cloud based applications.

Cross-platform Mobile App Development

Here are a couple of very interesting projects that let developers create cross-platform mobile applications:

Developers can use C/C++ which can be compiled to run natively on certain platforms or converted to Java bytecode output that can run on phones that only support Java applications. One can also develop HTML/CSS/JavaScript applications for phones that support those formats (similar to Cordova).

This project supports HTML/CSS/JavaScript development of applications that will work on a wide variety of mobile platforms.

C/C++ Mobile Development

If you want to port your own C/C++ programs or interesting Open Source C/C++ applications to mobile devices such as Android, these projects may be useful.

Information on using libSDL 2.x with Android.

Port of Nano-X/MicroWindows to Android. Nano-X/MicroWindows supports a subset of simple X11 and Windows applications. Many FLTK applications port easily when run with Nano-X.

Article on building and running Allegro based applications on Android.

C/C++ CGI Development

As a C/C++ programmer, I was surprised by how few CGI applications were built with these languages. Originally, I read that the reasoning behind this was that one would have to spawn a new process every time one wanted to run a C/C++ CGI program. Interpreted languages could be built into the web server and avoid spawning new processes. However, with the introduction of libraries such as FastCGI, the inefficiencies of running compiled programs as CGI applications is no longer an issue. From everything I've read, C/C++ CGI programs are much faster than other CGI programs if they avoid the process spawning issue. If you want a highly efficient CGI program, it's a good time to revisit using C/C++ with the proper libraries.

Here's some more information on FastCGI.

If anyone's interested, I have builds of FastCGI and Apache with fcgid support for Windows/MinGW (including patches to get them working on later versions of Windows).

Wt is one of the few projects I've seen that tries to provide useful CGI functionality and routines for C/C++ programmers.

C/C++ on the Web

One can also use projects like emscripten to compile C/C++ code into JavaScript that will run on the web. It's an easy way to port your own C/C++ applications or run popular Open Source applications to the web.


Another area of web development that surprises me is when I see so many language alternatives to JavaScript. JavaScript is supported (in some fashion) by most browsers. However, other programming languages are not. In order to get other languages to work in a browser, they typically need to be converted back to JavaScript. In a case like emscripten, it can be useful to convert C/C++ to JavaScript for porting purposes. However, many new web projects are choosing other languages besides JavaScript (because developers prefer the language) and then using tools to convert those languages back to JavaScript so they'll work via the Internet. Often the conversions introduce a lot of unnecessary code or provide slower implementations than the original. If I'm porting a project that's already written, it's great to be able to move it over with projects like emscripten. However, if I'm writing something new for the web that requires a programming language, I always use JavaScript. It's more efficient to write something specifically for that language than rely on generated code converted from another language.

It's also nice to be able to write CGI in JavaScript and share the same functions, objects and code between the client (browser) and the server. This is one of the major benefits provided by projects like CommonJS. The CommonJS site used to maintain a very nice list of server side JavaScript implementations. Unfortunately, the CommonJS project appears to no longer be active. It's been replaced by more implementation specific solutions like node.js.

There are alternatives for running server side JavaScript other than node.js if you don't want to be locked into a particular web server.

One option is TeaJS which uses FastCGI and works with a variety of web servers including Apache and Nginx.

Another option is jsc which is a JavaScript implementation that is a part of Webkit (one of the most commonly used browser libraries).

There are also some interesting TinyJS implementations and forks at various code archives such as github. You'll find more details under my Scripting Languages post ( http://lmemsm.dreamwidth.org/2239.html ).
Some interesting Open Source command line programs output their results in Postscript and/or PDF format. That makes it useful to have lightweight PDF and PostScript viewers that don't require a lot of dependencies to build so you can view their output quickly. It's also nice on Linux systems if they work in framebuffer mode, so you don't have to start an X Windows session just to view results. Cross-platform viewers work on a variety of systems from Linux and Mac to Windows to DOS and even Android. Having tools to edit/modify PDF and PostScript output is also useful.

I've been searching a lot lately for lightweight PostScript and PDF viewer options. Thought I'd share some of what I've learned about cross-platform PostScript and PDF support. If you know of any other viewers or PDF/PostScript related programs with minimal build dependencies that I may have missed, please let me know. I'm always looking for additions for my Open Source applications list: http://www.distasis.com/cpp/osrclist.htm

First, here some of the programs I use that output to PDF or PostScript.

This does have a lot of build dependencies (needs Qt and webkit), but it's one of the few programs that I've been able to find that does a good job of converting HTML to PDF.

Other HTML to PostScript/PDF alternatives are html2ps ( http://user.it.uu.se/~jan/html2ps.html ) which requires Perl and PhantomJS ( http://phantomjs.org/ ).

I use abcm2ps to convert songs in ABC notation to sheet music. Later versions of abcm2ps have the ability to output to SVG as well as PostScript. I have a lightweight SVG viewer based on nanosvg and SDL that displays SVG, so that should be an interesting display option if a PostScript viewer isn't readily available. I can upload the build scripts for it to my archive if anyone wants to try out the SVG viewer.

lcal and pcal
Personal calendars and lunar calendars can also be output to PostScript format.

The graphics layout engine outputs charts and graphs to PostScript, PDF and some graphics formats.

Other applications can output starcharts, barcodes, graphs, etc. to PostScript format. The applications I listed above are the ones I personally use the most in this category. If you have other favorites, would be interested to hear about them.

Next, I'll mention some PDF libraries and viewers.

The two main PDF rendering libraries/applications are mupdf and poppler.

Poppler is a library based on the xpdf viewer, so in most cases you really only need one of these on your system. They both have a lot of the same utility programs. When building poppler, there's additional support for GTK and Qt frameworks if you have those on your system. I typically build with these turned off to lower dependencies.

Mupdf was written by the developers of Ghostscript. It renders very quickly and is supposed to be very lightweight. However, what I dislike about it is its growing list of dependencies. Newer versions of mupdf provide more and more functionality, but they're requiring more dependencies to do so. Later versions of mupdf now require harfbuzz which I typically don't use with any other applications. (I'm not using Opentype fonts.) Also, the developers recommend you use their third party libraries rather than system libraries. There are work-arounds to use the system libraries, but it's a nuisance to modify the build scripts each time the program is updated. The API is not very stable either. Every time I download a new version, it seems to break third party utilities built using the mupdf library.

Mupdf has example viewers that come with it. The latest example includes an OpenGL based viewer. I did some work on a SDL based viewer using mupdf, but the API kept changing, making it difficult to maintain. When the OpenGL based viewer was added, I looked into using picogl in place of OpenGL/Mesa as a backend for the viewer. Using a viewer that comes with mupdf meant the mupdf developers would be responsible for dealing with the API changes. I got the OpenGL based viewer to build with picogl, but picogl still needs additional functionality to provide clear rendering of the text displayed by the mupdf viewer. Hope to work on this further in the future and would love to hear from anyone else who'd be interested in helping on this project.

There are some SDL and framebuffer based PDF viewers. However, they were either not easy to port to other platforms or had heavy dependencies I didn't want to add to my system. I found it interesting that some viewers used SDL as the actual graphical user interface (and could run in framebuffer mode on Linux), but still required GTK or Qt as an additional interface when rendering pages.

I finally found a lightweight, cross-platform PDF viewer that uses FLTK as a front end. It's called SpRead ( https://github.com/muranoya/SpRead ). It can be run in framebuffer on Linux using FLTK built with nano-x. The viewer is very lightweight and does seem to render quickly. Dependencies are really minimal compared to other viewers I've looked at. However, mupdf renders faster in many cases. SpRead uses poppler for PDF rendering and libarchive for zipped/archived file access.

Some other interesting PDF libraries available for editing and creating PDFs are qpdf ( http://qpdf.sourceforge.net/ ) and libharu ( http://libharu.org/ ).

Poppler and xpdf both come with PDF to text conversion utilities. This is very useful if you want to work with grep to search for a word or phrase in a collection of PDF files. Mupdf has added the ability to convert to text in more recent versions. However, their help/man pages on how to use their tools could use improvement. When I was searching for a lightweight PDF to text converter, I ran across pdftxt at https://litcave.rudi.ir/ As I mentioned, the mupdf library API keeps changing with newer releases, so typically when I update my version of mupdf, the pdftxt build breaks. I've uploaded patches to build pdftxt with the version of mupdf that I've most recently updated to. You can find patches and build scripts at the archive link on this page:

Since lightweight PDF viewers are more plentiful than PostScript viewers, I searched for PostScript to PDF converters. The main option in this category is Ghostscript. Like mupdf, it requires several dependencies and uses its own versions rather than system versions of libraries. It's actually worse in this area than mupdf. The only viable option to Ghostscript that I could find for PostScript rendering was xpost ( https://github.com/luser-dr00g/xpost ). It has less dependencies that Ghostscript and is easier to build. However, it's still a work in progress. I'm hoping at some point that it will replace Ghostscript for the functionality I'm interested in, but it at this point, it still doesn't have all the functionality I require. It does look like a promising project though.

Those are some of the interesting libraries and applications I've found on my search for PostScript and PDF related utilities. Hope you find some of them useful. If you know of other lightweight, cross-platform alternatives, I'd love to hear from you about them.
This is a list of mono-spaced fonts, Unicode fonts, font resources in general and useful FLOSS font sites.

Monospaced fonts are particularly useful for programming. They can help improve readability. Some programming editors (like PFE) only work with monospaced fonts. Other editors allow the use of more varied fonts. However, monospaced fonts are useful when working with PRE tags in HTML, ASCII art and in other areas.

Other useful fonts include Unicode fonts for internationalized projects and fonts for people with handicaps or disabilities such as fonts designed for people with dyslexia.

Using a Free, Libre or Open Source font or a public domain or Creative Commons licensed font makes it easy to reuse fonts in Open Source (or even commercial) projects.

Bitmap Fonts

Fonts for DOS and Windows Command Prompts

Free Monospaced Fonts (Bitmap)

Dina Programming Font

Electronic Font Open Laboratory

Envy Code A

Envy Code B


Liberation Fonts


MIT license

Proggy Fonts

Raize font

Sans Forgetica


Terminus font
Includes a large size font especially useful for terminals in framebuffer mode on Linux systems.


Free Truetype Monospaced Fonts

Adobe Fonts


Bitstream Vera

Available with Povray software.

Cutive Mono

DejaVu Fonts

Droid Sans Mono

Envy Code R

Font Squirrel Monospaced fonts

GNU FreeFont

GNU Unifont


Unicode font for medievalists

Lucida Sans Typewriter Regular - included with Oracle's Java SDK

Matthew Welch's MIT licensed fonts
White Rabbit worked as a monospaced font


Oxygen Monospace
Oxygen Fonts

PT Mono

Roboto Mono
Google's Roboto fonts

SIL Encore Fonts
Several unicode fonts including some monospaced ones.

Source Code Pro
Adobe Font

String Literal

Ubuntu Fonts
Ubuntu Mono

Xerox Alto mono-spaced font

Hack font

Hacked fonts

Other Fonts

EB Garamond



Lato Fonts

Libertine Open Fonts Project

MPH 2B Damase Font


Simon Tatham's Fonts Page

Sorts Mill fonts


Font Related Links

Several monospaced fonts (TrueType, bitmap, OpenType) for developers.

Cufon Type Converter
Convert TTF fonts to cufon font format for web sites. With a few text changes, fonts can be used with Raphael.js too.

Create your own fonts.
Example fonts in sfd format including Monospace, Caslon and Caliban:

Font Library

Font Squirrel
Handpicked Free Fonts

Google Fonts

Monospace/Fixed Width Programmer's Fonts


SIL Open Font License (OFL)

Wikipedia Open Source Unicode Typefaces

Unicode Font Guide For Free/Libre Open Source Operating Systems
I covered SDL based applications. Now, I'd like to cover FLTK based applications for desktops and/or productivity.

While there isn't as much FLTK application development going on as I would like, there are some projects that specialize in using FLTK. TinyCore Linux is probably the most well-known Linux project that uses several FLTK applications. Nanolinux is based on TinyCore but uses nano-x as a lightweight alternative to X Windows. The developer of NanoLinux uses mainly FLTK applications and has modified and updated several FLTK applications to give them new life. He's also created some of his own where good alternatives did not exist. The Equinox Desktop Environment also uses FLTK, but it typically requires another EDE specific library along with FLTK support. Also, EDE users don't always look for FLTK applications for their desktops. Some will typically use anything they consider lightweight (whether it really is lightweight or not). A few mobile devices use FLTK as their main GUI. Users of those systems have developed some interesting applications for their devices.

There are several versions of FLTK. Applications may work with one version and not another. I've spent a lot of time searching for applications and porting applications to the latest version. I did try to update the FLTK software links list at the official FLTK web site with information on what worked with the latest version of FLTK and with information on newer FLTK applications, but was unable to add some of the newer, more interesting FLTK applications out there. So, this is my definitive list at this point in time of the best FLTK applications available. For more information on FLTK and applications, see also http://www.distasis.com/cpp/scrlib.htm#fltk

I'm sure I haven't covered everything and as mentioned, check NanoLinux and Tiny Core Linux for more FLTK based applications. I'm always looking for new, portable, lightweight FLTK based applications. If you know of something I may have missed or you're working on a new FLTK based project, please contact me.


Shows disk usage. Works on POSIX systems with du command. I have patches to port this to Windows.

Calculator. The FLTK web site link includes information on some of my patches to get it to build successfully as well as link to the original source code.

Graphical diff program.

Traverse directories and find file differences. Some of it was based on fldiff.

Password manager. I ported this to work with the latest versions of FLTK and tinyxml2. It's interesting, but at this point, I'd prefer a Keepass compatible password manager. I'm looking into chkpass as a lightweight alternative for password management.


prozgui for prozilla
Fast file downloader. I have patches for building and to port this to Windows. I use a version based on GNU GPLv2 development instead of the GNU GPLv3 development.

IRC client. Based on MegaIRC, but with a lot of cleanup. I have patches to add gettext/libintl support. This is the best option for IRC using FLTK that I've found to date.

This has good potential as a threaded IRC client. It can handle multiple connections. I could get it to build on Windows either with patches or a build of MinGW with POSIX instead of Windows native threading support. It needs some work on storing IRC connections. Doesn't seem to remember any connections once you leave the application.


There are two webkit based browsers for FLTK. That's great news for FLTK applications users. What's not so great is that they don't port well to non-POSIX systems. If you want the most lightweight webkit based browser (and webkit browsers are not by nature lightweight), I'd go with either of these options instead of the many other webkit ports out there.

I was able to get the original version of netrider to port to Windows and a Windows version of it is available at Sourceforge. However, when I upgraded the version of my MinGW compiler, I was no longer able to build netrider. Seems the webkit developers took some shortcuts in the older code that really weren't up to C++ standards. Netrider upgraded to a later version of webkit (which fixed the compiler issue), but the newer version was never ported to Windows.

This was never ported to Windows although it might be easier to port that the latest version of Netrider. It uses makefiles created by the developer instead of cmake.

When people talk about FLTK based web browsers, Dillo always comes up. However, Dillo is the opposite of what I think of when I think about portable code. One developer decided to fork Dillo and make it more structured and easier to port. He's really done a wonderful job on cleaning up the code. I'd recommend this browser over Dillo if you're interested in doing anything with the source code or need a lightweight HTML viewer for FLTK. DPlus is also the lightest browser I could find that could display output from diffh properly. Most console browsers like lynx had trouble rendering the color differences in the output.

While this is meant as a utility rather than a web browser, I used DPlus as the starting point for my HTML/CSS based dialog replacement.

Mail clients

The developer of Nanolinux wrote a nice, basic, stable e-mail client. (He also reused part of my Open Source POP3 e-mail code.)

This has a lot of potential. It took a long while to get it to build with the latest version of FLTK and it's still kind of buggy. I also needed to update helper libraries fl_toggletree and fleditor to work with the latest FLTK. The interface is a lot of like sylpheed and foxmail. I would love to see some new development on this and would be happy to help update it.

There was a nice, very basic, stable e-mail client at Sourceforge. Doesn't appear to be available from there any longer.

RSS reader
Gautier's RSS reader
This one has a lot of potential. It has an attractive user interface that's easy to work with. However, it does have the ability to sort RSS posts at this point at time. It needs to be used in conjunction with a script and tools like curl to download the RSS feeds. It's basically just a reader. It uses SQLLite to store the RSS data so it can potentially provide fast access to RSS posts. I'd love to see some further development done on this project.


Cross-platform VLC based media player.

Unfortunately, this only works on POSIX systems so far. I have been able to build it on Cygwin as well as BSD and several Linux systems. This might be portable to more platforms using nano-x (and possibly SDL as the backend for nano-x), but I did not get very far in investigating this option. It is my favorite xine front end and is more lightweight than many of the other xine front end options. It provides a variety of features including a nice visualization component for use while playing music.


Simple Audio recorder and player based on Sox. I have done some work to port this one to Windows.

Midi keyboard.

Audio effects program to stretch sounds.

After more than one try to get this to build with the latest version of FLTK, I finally managed to get this working. It's a nice, lightweight audio editor. It doesn't display multiple tracks like Audacity. It does not have good support for playing or recording wave files. It's basically just a wave file editor. Was considering using libsox or another Open Source sound library to add support for playing wave files.

There is a fork of FLTK called NTK. It isn't as portable as FLTK and requires POSIX/X Windows support. A suite of audio applications were created with it.


This is a great, lightweight graphics editor. I really like this one.

Specialized graphics editor for coloring old photos.

Other graphics and drawing options include Antipaint and Cinepaint. Antipaint was updated to work with the lastest version of FLTK and to improve portability by the developer of Nanolinux. You'll find it at the Nanolinux web site. At one point Cinepaint decided to port their project from GTK to FLTK. You'll find some older versions with some FLTK support and utilities. However, the FLTK port is not actively developed.


The Daily Journal is a Personal Information Manager (PIM). It has several nice features including the ability to set alarms to remind you of appointments. I use one of the older versions (0.7) which ports well to newer versions of FLTK and, per my recommendation, so does NanoLinux.

Simple todo list. Haven't used it in a while, but if you're looking for a todo list program, it's an option.

PDF/Ebook Readers

A functional, basic PDF viewer and archived image viewer. I really like this one. It requires a compiler with later C++ support to build. Needs minimal dependencies, mainly libarchive and poppler. While poppler isn't as fast as mupdf at rendering, this still works pretty fast.

Image viewer with plugin support for mupdf and poppler.

There's also flaxpdf which is optimized for efficiency and uses mupdf. However, it's not at all portable to non-POSIX systems.

I tried BDReader as well but there are a lot of dependencies involved in building this.

File managers

I don't use any of these and personally prefer the SDL based file manager mentioned earlier. However, they're nice lightweight GUI file managers. I'm sure there are a few others not mentioned below as well.



Other POSIX only FLTK applications

GUI front end for synaptics touchpad controls.

FLTK ALSA Mixer front end.


I've yet to find a FLTK based editor I really like. For now, I'm still using SciTE, Fxite and nano.

I would love to find a Scintilla based FLTK editor. The closest I've found is https://github.com/cyantreeguo/Fl_Scintilla

There are many FLTK editor controls out there, including the one used by Postoffice.

Nanolinux offers flwriter.

The most interesting editor option I've found so far is fldev. There's a link to the original at http://www.fltk.org/wiki.php?V235+TC+Q and further development by the developer of NanoLinux at https://sourceforge.net/projects/fldev/ The main drawback is that it only opens one file at a time. The original author began to add support to use it as a debugger in conjunction with gdb. I'd love to get that support working properly and in a cross-platform manner and have been experimenting with it as time allows.

flabc is an editor specifically designed for ABC notation, but it appears to be a stable, well-written editor and may be useful for other editing purposes.

April 2019

141516 17181920


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 20th, 2019 12:15 pm
Powered by Dreamwidth Studios