I'm trying to locate ports of some of the more popular Unix/Linux utilities to other operating systems such as AIX and Windows. I find it helpful to have the same utility on all the systems I work on, not just on a few them.

Are you searching for other programs of this nature or creating other cross-platform utilities of your own? If so, please share your progress. It would be nice to add more options to this list.

cal
http://unicorn.us.com/cal.html

lsof for AIX
https://github.com/aixoss/lsof

top for Unix and AIX systems
https://sourceforge.net/projects/unixtop/

ntop for Windows
https://github.com/gsass1/NTop

lsblk like utility for Windows
https://github.com/tenox7/lsblk

simple cross-platform ping
https://github.com/sryze/ping

ps style tools for Windows
https://github.com/joeattardi/winpstools
https://github.com/katakk/pkill/

uptime
https://github.com/qwercik/uptime

experimental dd implementation for Windows
https://github.com/sryze/wdd

dd for Windows
http://www.chrysocome.net/dd

busybox-w32 has ports of several utilities that will work on Windows including dd, df, grep, ps, su and others:
https://github.com/rmyorston/busybox-w32

nano for Windows
https://github.com/lhmouse/nano-win
I also have a port of nano for Windows. It works with PDCurses.

An older version of htop was patched for AIX support and I've added a similar patch to a later version. When the htop project was contacted regarding patches they responded they were not interested in adding AIX support to the official version.

I have simple cross-platform implementations of uptime, nproc and free which I've been working on.

I've been investigating some of the lightweight, command line utilities that are often used to check the status on a system. In some cases, it was hard to track down the packages they were in. It's difficult to search when some of the names are so ubiquitous. Just try running a search for the free utility.

I knew that many of the utilities were in the GNU coreutils package. I found out that many others were often supplied by the procps or the newer procps-ng packages. The procps and procps-ng packages are fairly Linux specific. So, it's not likely you'll find the code ported to other operating systems. While GNU coreutils ports to many platforms, I typically prefer GNU alternatives. They tend to be more lightweight with not as many features. Also, many GNU developers don't particularly like programming for portability and often won't accept patches for their code when there are portability issues. Many of the utilities I considered have been on Unix systems for a long time and are also available on BSD systems. The GNU versions tend to add more features and functionality. BSD systems don't use coreutils, so most of the programs are part of the operating system code.

Busybox and Toybox provide a lot of the utilities as well. Both Busybox and Toybox are designed as one monolithic program that can be accessed through links to the various utility names. That's convenient because there can be a lot of repetition between what some of these programs do. Having the code in all in one place means less maintenance for repetitive tasks. In a few cases, more standard versions of some utilities took this approach as well. For instance, the w program on a BSD system is also the who program.

It seems almost random as to what stats some of these programs cover. For instance, uptime not only gives you how long the machine was up, it also gives you how many users are on the system and system load averages. Sometimes seemingly non-related information may all be returned by the same function on a particular operating system, but sometimes it requires different functions to check each statistic. So, why put it together in this particular presentation? Likely, it's just because that's how it's historically been done and changing too much could break a lot of scripts out there. Some lightweight implementations don't always show all the information of the more common versions of the utilities either. For instance, some versions of uptime just show the boot time and don't bother with the other statistics.

Command line options for invoking a program may not be the same for different versions of a program. Also, since many of the programs have been around a long time, the command line options may not be that intuitive. For instance, I typically see -h reserved for help, but in some cases, it's being used for printing a human readable format. Some other utilities use -H for human readable. Some use both lowercase and upper case for human readable but use factors of 1024 bytes for one instance and factors of 1000 for the other. Personally, I would prefer to use -h for help and -B with a blocksize to indicate what factor I might want to divide by. That way you don't need separate command line options for kilobyte, megabyte, gigabyte and kibibyte, mebibyte and gibibtye. Many programs don't even offer options for terabyte which has become much more standard. As memory sizes go up, the older hard-coded options won't adapt as well. As mentioned, one of the issues with changing command line options to make utilities more uniform is that it could interfere with backward compatibility and cause other programs depending on that functionality to fail. However, all the various implementations aren't exactly standardized to begin with. The Open Group has some standards for utility conventions. Many programs use getopt or getopt_long to help standardize parsing of command line. However, it's not enough of a standard to prevent all the differences between different implementations. So, it's not like scripts can rely on all the same options to be there on different platforms or with non-standard software choices anyway.

I was interested in tracking statistics on memory usage, disk space, CPU usage, process and user related information and when a machine was rebooted. The tools I investigated included free and vmstat which show memory usage, df and du for disk space usage, uptime for CPU usage and boot time, nproc shows number of CPUs, ps and top for process information and utilities such as w, who and whoami for user related information.

I wanted to find lightweight alternatives that I could use on multiple platforms and not just Linux. Minix 3 uses a lot of the BSD utilities, so going with those might be one alternative. However, many still have a lot of code to implement them and the code is often very specific to BSD style operating systems.

One place to find lightweight versions of some of these utilities is ubase which was designed with the suckless.org philosophy in mind:
https://git.suckless.org/ubase/files.html
The code is very readable, but can be very Linux specific. Another alternative is nbase:
https://github.com/cheusov/nbase
This is a port of NetBSD tools to POSIX systems so that makes it a more portable option. Earlier versions of Minix had some lightweight versions of various utilities in their commands/simple directory before they switched to the BSD versions. PicoBSD also had some interesting lightweight utilities programs including aps and sps which are ps alternatives and vm which is a vmstat alternative.

There are also Windows ports of utilities such as ntop:
https://github.com/gsass1/NTop However, while some of these programs look like common Unix/Linux/BSD utilities, many are completely rewritten from scratch and would not port well to other operating systems besides Windows. Alternative operating systems such as hobby OSs that some developers create may have some of these utilities as well. After all, they're simple, command line based and useful. However, since many of the hobby OSs don't support POSIX or have large differences in kernel design, their implementations probably don't port well to other platforms either.

I'm currently in need of utilities that work on Linux, AIX and Windows. I've been investigating writing some of these utilities from scratch in a more portable manner so I can use them in a consistent way on whatever operating system I may need them. Unfortunately, they can be difficult to write, since the underlying functions are not part of the C or POSIX standards and are very platform specific. They can even change with the version of the operating system. Nevertheless, I'm going to continue to work on implementing more portable alternatives for some of the more common utilities. They're useful and their functionality is sorely missed on operating systems where they are not native. It would be really interesting to discuss design issues and trade-offs further with any developers who may be working on similar projects or with users testing out these types of utilities.

Would love to compare notes on this subject. Are there other simple command line utilities that I haven't mentioned that you use to check the status of your operating system? Do you know of other alternative implementations for some of the more common utilities mentioned? Are you interested in using some of these utilities on an operating system where they may not be as readily available? Let me know about your experiences in this area.

I just got used to VirtualBox and ended up having to switch to QEMU. VirtualBox seems to run better than QEMU. I tried to load several operating systems in QEMU that ran fine under VirtualBox and they failed. Decided to try a Debian netinst because that works well with most machines. Then I had to figure out all over again how to get files between the host and guest systems. It's harder to find documentation on what you're looking for with QEMU as compared to VirtualBox.

The first step is to download and install qemu someplace. I'm assuming it's in the path. Otherwise, you need to specify where to run it from.

Next step, create a virtual disk to install the operating system to. The following creates a 2 GB image file in raw format. You can choose other formats.

qemu-img create linuximage.img 2G

I'm using an ISO for 64 bit Linux, so I use qemu-system-x86_64. For 32 bit systems, I can use qemu-system-i386. There are options like qemu-system-i386w.exe which I was wondering about. Turns out these are for use on Windows systems. They prevent bringing up a console when as well as a window when running. However, I typically run everything from the command line, so there's no advantage to this. Windows programs running in console don't create a new console. I recommend sticking with the standard versions without the w especially if you're running from the command line or on a non-Windows system.

I downloaded a Debian netinst ISO and put it in the iso directory. This is the command I used to start QEMU so I could install Debian to the linuximage.img file.

qemu-system-x86_64 -hda linuximage.img -cdrom iso\debian-10.10.0-i386-netinst.iso -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G -boot order=dc -usbdevice tablet

The -m option specifies RAM and I gave it 1 Gigabyte. Once you run the command, hopefully the operating system should boot from the ISO as if it was a CD. You can then proceed to install it to linuximage.img which should appear as the first hard drive on your system. Once the system is installed, you probably want to Power Down and/or Quit QEMU.

Use the following command to boot from the image rather than running from the ISO file.

qemu-system-x86_64 -hda linuximage.img -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

The -usbdevice tablet setting seems to help smooth out mouse support which didn't work well without it.

Now comes the hard part, I wanted to move files back and forth from the new system. If the files are fat32 (such as a ReactOS image, you can mount the image and read the files. That doesn't help much with operating systems that use other disk formats. You can load images as floppies or cdroms (typically read only) or add another hard drive. So, the idea was to add a second drive that was formatted using a format the host system could read. I created another image and attempted to format it in using the Guest operating system in a way that the host could read. That failed. I recommend mounting the image and letting the host operating system format it. Then, the guest operating system can be set to access it as a second drive.

To do this on Window, I used a program called ImDisk.
https://sourceforge.net/projects/imdisk-toolkit/
Latest versions of Windows are supposed to allow you to mount an image as well.

I created a new image using:
qemu-img create drive.img 2G

Once I mounted the image using ImDisk, the operating system asked if I wanted to format the image and I let it do the formatting. Then, I could access the image using QEMU. Make sure the drive is not mounted on the host system before using it with the guest system and vice versa.

qemu-system-x86_64 -hda linuximage.img -hdb drive.img -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

When I tried formatting the drive using Linux in QEMU, it wanted to access the new drive as /dev/sdb1. When I just use the image created from Windows, it used /dev/sdb.

Once you've created and formatted the extra image, you can access it in your virtual operating system. If you're running Linux virtually, you'll need steps like these.

mkdir -p /mnt/data
mount -o defaults /dev/sdb /mnt/data

They needed to be performed as root or you need to get sudo working properly first. Directory creation only has to be performed once. The mount needs to be done each time you activate the operating system and want to access the image unless you add the information to auto mount it in /etc/fstab. You can also unmount the drive using umount.

Once the drive is mounted, you can move files to and from it. You can see if there's anything on the image using:
ls -l /mnt/data
Copy or move files from /mnt/data or whatever location you mount the drive at as well.

While I couldn't access an image I formatted in the guest system, I did want to go through the steps. It worked fine from within the host and was readable from there.

Install fdisk. Since I'm using fat32, I also needed to install dosfstools. I found the tools in /usr/sbin and had to run from that directory since it wasn't in my path. The commands below assume programs are in the path. They probably need to be run as root or using sudo.

fdisk -l

This shows your images so you can find their names. I set drive.img as -hdb so it shows up as /dev/sdb on a Linux system.

fdisk /dev/sdb

The fdisk program will prompt for further information.

At the fdisk command prompt, I gave it the o option. This creates a new DOS partition. The next command was n to set a partition type. I chose p for primary. I chose the default partition number 1. It brought up first and last sector options and I chose the defaults for both. At the command prompt, I chose t for partition type and gave it a hex code of b which selected W95 FAT32. At the command prompt, I selected w which wrote the changes and exited the program. From the normal command prompt, I ran the following:
mkfs.vfat -F 32 -n WINSTORAGE /dev/sdb1

This should format the image and name the image WINSTORAGE. Windows prefers upper case for disk labels.

Once done I was able to use mkdir to create a directory under /mnt to mount it. In this case it needs to be mounted as /sdb1 not not sdb. The result made an image that worked fine in the guest system but wasn't recognized on the host.

If your host system is a Linux system, it might be helpful to use a more familiar format like ext2 or ext3 instead of fat32. On the other hand, many flash drives use fat32 and most systems can read them, so it might be a useful solution as well. If you create the second image before installing the new operating system, depending on the installation process, it might recognize the extra image and incorporate it automatically. Just make sure not to reformat it when installing the operating system.

The mtools programs can be used on various operating systems and can be used with emulators and images formatted for DOS. Wondering if it could be used to format a mounted image file as fat32 on systems that don't support it natively.

I was also able to successfully create an ISO image on the host system using mkisofs and load that as a virtual CDROM on the guest.

mkisofs is available on Windows with various software. I typically installed DVDStyler and used the program it supplies. Debian and some systems typically don't supply cdrtools which contains mkisofs. Many systems use another package which emulates or gives equivalents to commands cdrtools supplies. GRML is a Debian based distribution that does offer the original cdrtools package. There are some arguments over copyright which kept cdrtools from being added to some distributions. I also found a utility that worked only on Windows that could create ISO files. It was used by some ReactOS developers. Nice thing was that it built easily from source using MinGW.

Assuming my files are in the tmp directory below the directory I'm in, I can run mkisofs with the following command to make an ISO file.
mkisofs -r -R -J -l  -o test.iso tmp

I can add the image using a command like this one.
qemu-system-x86_64 -hda linuximage.img -drive id=cdrom0,file=file,index=1,media=cdrom,file=test.iso -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -m 1G  -boot order=c -usbdevice tablet

Once in Linux, the cdrom can be accessed after mounting it with:
mount /media/cdrom

I've used that technique to get Debian to install successfully with QEMU. Haven't had much luck with other systems yet including other versions of Linux. I'd also like to get Androic-x86 or Bliss OS working at some point. XFDOS would be another interesting option to try.

I did finally get ReactOS running in QEMU. Reactos is tricky to load. The Reactos version used must be 0.4.14-RC or higher.

I created an image using the native QEMU format as recommended on the ReactOS site.

qemu-img create -f qcow2 reactOS.qcow2 2G

I installed ReactOS on the image by following the prompts after using this command:

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=2,media=cdrom,file=iso\reactos-bootcd-0.4.15-dev-2847-g0ffbbab-x86-gcc-lin-dbg.iso -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -boot order=dc -serial file:reactos.log

Most of the options I picked were defaults.

After the image is formatted and the operating system is installed, power down and/or quit QEMU.

I ran the following command to complete setup after the ISO was no longer accessible from the CDROM drive. It let me set up the system.

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=1,media=disk,file=drive.img -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -boot order=dc -serial file:reactos.log

After it's set up as desired, power down and/or quit qemu.

Now, I can run the following command to move files to and from ReactOS within QEMU using the drive.img.

qemu-system-i386 -drive if=ide,index=0,media=disk,file=reactos.qcow2 -drive if=ide,index=1,media=disk,file=drive.img -m 1G -device ac97 -net nic,model=ne2k_pci -net user -rtc base=localtime -usbdevice tablet -serial file:reactos.log

It's accessible as e:. The d: drive is still reserved for the CDROM device.

At one point when I restarted the image, it asked me to press Ctrl-Alt-Delete to get into the system. I found out you can send special keys to QEMU by pressing alt-ctrl-2 to get to a screen where you can enter commands. You can emulate keys using sendkey. I entered sendkey alt-ctrl-delete. Return to the original screen using alt-ctrl-1. This actually accomplished nothing in this case, because the screen was coming due to an error with the system, possibly the registry. I ended up having to reinstall ReactOS to fix it. Sending alt-tab this way once the system was reinstalled worked well.

ReactOS is interesting and can run some great Windows programs. However, it does crash more often than I would like. Can't help thinking a Linux system with Wine would be more stable. There are several themes, but I miss the Windows XP Silver Metallic theme. Supposedly, you can copy the .msstyle file over from a Windows XP machine to ReactOS and it should emulate the style.

Still investigating what other operating systems will run under QEMU and what commands they require.

So, that's my cheat sheet of useful QEMU commands to date. It does seem to have some advantages to VirtualBox, but so far, I haven't been able to run as many operating systems on it. You also have to decipher what to use in the command line or it may fail to run. Once you have the techniques down and the images created, it seems to work well. It seems less complicated to get files in and out than using VirtualBox Guest Additions. Unfortunately, documentation for how to accomplish it is difficult to find.
I'll be interested to see if QEMU will allow access to an extra image when running an Android operating system. VirtualBox Guest Additions typically wasn't an option for most virtual Android based operating systems. Hopefully, that's all that's needed to get a virtual operating system up in QEMU and develop/build applications natively within the guest system.

Considering how hard it is to get computers (still waiting over a month) and computer parts, now is a great time to look into bringing new life to your old hardware.

While I often see information shared about how Linux brings new life to older computers, my personal experience ( http://www.distasis.com/cpp/slin.htm ) hasn't been as good as some of the glowing articles. When I investigate further, a lot of the successes have been for single purpose servers (typically command line with no desktop support) or single function usage like home theater systems. Many Linux distributions are aimed at the latest hardware and can be just as resource intensive as Windows systems. It's interesting to note that many of the low resource optimizations for Linux originated from the Android project not from the kernel project itself and they are slowly being integrated into the Linux kernel project. Some FLOSS development projects and companies like Google which produces Android don't even want to be bothered with 32 bit systems and want to concentrate on 64 bit only. It can be more efficient to run Linux or other Free operating systems on new minimal hardware like a Raspberry Pi than to try to get something working on an old computer. One can also find systems similar to the Raspberry Pi but supporting X86 so Windows CE and other Windows like software becomes an option. There's even an Android operating system port called Android-X86.

I've often seen Puppy Linux touted as a great system for older computers, but I could never get it to work with my hardware. Slackware is an interesting choice that can be lightweight, but the Lilo boot loader doesn't work for certain types of hard drives and one would need to find a way to independently get grub on those systems. TinyCore Linux is really interesting but it can require a lot of RAM to run properly. Debian has worked on many older systems and there are many great Debian variants. However, even Debian is removing some of their drivers for older hardware. Plus, they've updated to systemd. So, if you want a system you can maintain yourself with minimal dependencies where a package does one thing well per the Unix philosophy, a systemd based OS won't be the way to go.

Some Linux distributions still worth checking out for use with older systems are:
AntiX, a Debian based distribution without systemd
ToriOS, a Debian based distribution catering to older computers
NanoLinux, a TinyCore Linux distribution that uses Nano-X instead of X Windows
Grml, a Debian based distribution, command line, bootable rescue CD

I've also looked into OS options for older computers that were not Linux based. Both FreeBSD and FreeDOS can be more lightweight alternatives than Linux. However, both options typically have less hardware support than Linux. FreeDOS also tends to have more proprietary software and few active Open Source projects available for it. If you're interested in a very lightweight DOS alternative for old hardware, check out the XFDOS project. It offers several Open Source programs for DOS including a lightweight browser.

I've never had any luck with ReactOS. Again, hardware support is an issue. It can run some very complex Windows programs quite well, but it often fails on simple ones I commonly use. While I've recently seen posts that they want to hire development help, I've never found them responsive when I've volunteered to offer my programming skills. Wine seems to be able to run more Windows programs successfully than Reactos and Linux has better hardware support. So, a Linux system with Wine might be a good option for Windows users who want to switch. However, if switching to Linux, I'd personally rather rebuild my Open Source software for Linux rather than try to use it on Wine. I'd love to find some other viable options besides ReactOS. I do remember reading something on the ReactOS forum about a Wine based fork to ReactOS. Haven't been able to find any details though. Some DOS projects mentioned adding partial support for Windows programs using options like HX DOS Extender. However, they only seem to support Win32 console options. I've seen some suggestions of creating a FLOSS OS similar to a Win 3.1 system with a GUI/desktop built on top of a FreeDOS system, but have not been able to find any active projects. Without GUI support for DOS based Windows alternatives, a project like XFDOS using Nano-X seems the best way to go. Nano-X provides basic APIs somewhat compatible with Xlib and Win32 and there's enough support to build FLTK based applications. If anyone finds other viable options in this area, please let me know. I would love to add my programming skills to such a project.

If you have a Windows computer, you can keep running Windows and use FLOSS programs to improve functionality. I've upgraded Windows systems before, but the results are typically sluggish and eventually I end up having to put another operating system on to keep using the machine.
The one thing that seems consistent across platforms is that older versions of operating systems seem to run better on older hardware than newer ones. Developers continue to write software that is more bloated, more complicated and more dependent on other software. Many news sources do not recommend running older operating systems especially Windows. So using older operating systems to keep older hardware alive goes against average advice. If you don't have other options and need to run an older operating system on your hardware, two security concepts to look into are sandboxing and security by obscurity. On Linux systems, Linux containers are a good sandboxing option. You can also try to avoid running as root or admin whenever you access the Internet. You can even disconnect from the Internet completely for security purposes and use options like sneaker net ( http://www.distasis.com/cpp/snet.htm ) to update your systems when needed.

Here are some FLOSS recommendations for low resource or older computers. Some are specifically for Windows or Linux and some are cross-platform portable.


Cross-platform applications:

Web Browser - Netrider
https://sourceforge.net/projects/netrider/

Web Browser - D+
https:/sourceforge.net/projects/dplus-browser/

Web Browser - lynx
https://lynx.invisible-island.net/

Graphics editor - Lodepaint
https://sourceforge.net/projects/lodepaint/

Graphics editor - grafx2
http://grafx2.chez.com/

Command line graphics editor - GraphicsMagick
http://www.graphicsmagick.org/

Command line sound conversion/player - SoX
http://sox.sourceforge.net/

Music player - MilkyTracker
https://milkytracker.titandemo.org/

PDF viewer - MuPDF
https://mupdf.com/

Ebook reader - Bard
https://github.com/festvox/bard
I have a patched version that works better on Windows.

Windows emulator - BoxedWine
https://github.com/danoon2/Boxedwine


DOS Resources:

DOS distribution - XFDOS
https://sourceforge.net/projects/fltk-dos/

DOS emulator - DOSBox
https://www.dosbox.com/


Windows specific and Windows portable versions:

Web browser - Mozilla Firefox, Portable Edition Legacy 52
https://portableapps.com/apps/internet/firefox-portable-legacy-52

Web browser - Chrome Portable
https://portableapps.com/node/60675

Java - Java Portable
https://sourceforge.net/projects/portableapps/files/Java%20Portable/
Install in CommonFiles subdirectory at the same level as where the portable browsers are installed. Java Portable version 8 works on XP and Vista. I've used jPortable_8_Update_66.paf.exe but later versions will probably work as well.

Web browsers - other options
http://rtfreesoft.blogspot.com/
Haven't tried them, but there are several ports of browsers to older hardware.

Web browser - RetroZilla
https://github.com/rn10950/RetroZilla

Web browser - Supermium
https://github.com/win32ss/supermium

IM - Miranda NG
https://github.com/miranda-ng/miranda-ng

Sandox - Sandboxie
https://github.com/sandboxie-plus/Sandboxie
https://www.sandboxie.com/GettingStarted

Firewall - Simplewall
https://github.com/henrypp/simplewall

Host-based Intrusion Detection System - ossec
https://github.com/ossec/ossec-hids

PDF viewer - SumatraPDF
https://www.sumatrapdfreader.org/free-pdf-reader.html

Image editor - I.mage
http://www.memecode.com/image/

ISO access - WinCDEmu
https://portableapps.com/apps/utilities/wincdemu-portable
If you can't find a copy of WinXP Virtual CD Control Panel for accessing ISO files or it doesn't work on your system, you can try WinCDEmu.

CD and DVD creation - rktools
https://www.microsoft.com/en-us/download/details.aspx?id=17657
This isn't FLOSS, but it's very useful for creating CDs and DVDs from the command line.

GWBasic
https://github.com/microsoft/GW-BASIC
The original source code of Microsoft GW-BASIC from 1983 is available under a MIT license.


Linux/POSIX software:

Window manager - JWM
https://joewing.net/projects/jwm/

Terminal software - urxvt
http://software.schmorp.de/pkg/rxvt-unicode.html


If you have other alternatives (operating systems or FLOSS software) that work on older hardware that you'd like to recommend, please let me know ( http://www.distasis.com/connect.htm ). I would love to find some other options. I'm also actively looking for operating system projects that need (and actually want) volunteers to help port lightweight software to them. Would be interested in hearing how others are coping with keeping older hardware alive. Hope you'll share your own articles, blogs, projects with everyone.

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