lmemsm | Entries tagged with windows

Let's talk console based software and FOSS operating systems. First, some console based software resources I've liked over the years include:
https://inconsolation.wordpress.com/
https://termux.dev/en/
https://archiveos.org/rogue/
http://inx.maincontent.net/

I have some other resources and console program recommendations in other articles I've written here.

I've seen a lot of FLOSS projects try to convert Windows users to Free Software by sharing GUI based Free operating systems that look a lot like Windows. I really don't know if this is the best strategy to convert people to using something else. Wouldn't it be nice to offer something better and more intuitive rather than just copy what another system can do? I certainly do not think this a good strategy for getting die-hard Windows command line users to switch to FLOSS operating system alternatives. Users that started on DOS and graduated to Windows should be a great market to tap into. Many Unix and Linux systems emphasize console based interactions. However, when Free Software advocates try to reach Windows users and get them to switch, they often end up showing off Windows-like GUIs. They leave out a portion of the market. They leave out the Windows users who don't use Windows because of its GUI design.

What about those of us who still prefer a good old-fashioned command line and want to use console or terminal sessions to get the majority of work done? What kind of conversion path to a Free OS is there for us?

FreeDOS is a wonderful option if you just want DOS. Unfortunately, a lot of current hardware support and drivers are lacking. For years, I've had trouble switching to Linux due to hardware incompatibilities and driver issues. Of all the FOSS operating systems I've tried (BSD, FreeDOS, Minix, etc.), Linux has the best driver support. So, if Linux can't support someone's hardware, it's very likely other options like FreeDOS can't either. FreeDOS does do a very decent job of supporting legacy software and hardware though.

ReactOS is a great path for people who want to use a Free Operating system but want the familiarity of Windows. It runs many Windows programs natively. You can continue to write programs using a Win32 API and have them work on the system. Like FreeDOS, it also doesn't have the drivers and hardware support a commercial system does. Theoretically, when they have something fully compatible with Windows, Windows drivers should just work. It's not at that point of development yet. The biggest drawback I had when trying to use ReactOS was stability. Some Windows programs worked perfectly out-of-the-box. Some crash. I would have liked to get more involved with the project and possibly debug some of my issues. I didn't find it an easy project to join in on if you wanted to help with development.

Using Linux with Wine is another option for people who want to keep using their Windows programs on a Free operating system. I even read about a ReactOS side project where someone used Linux and Wine as a starting point for a ReactOS like system. I love the idea of being able to compile Win32 programs on Linux natively with winelib and have them work on Linux. However, the usual usage is to run Windows programs (closed source) with Wine which emulates a Windows system. They don't even encourage building programs from source with winelib. Personally, I've always found winelib hard to build from source and Wine hard to install on my systems. Some Linux distributions support working with it better than others and some Linux distributions come with Wine already installed.

The X Windows alternative nano-x also offers some Win32 support so you can compile some Windows programs and use them on a system with nano-x libraries. You can build nano-x like an X Windows alternative with client/server support. Projects like NanoLinux and XFDos have created desktop environments using it. You can also build everything into one application (the client and server support) and run applications without a separate nano-x based desktop environment. Most projects have used nano-x to build X11 applications without requiring X11 libraries. However, the potential to port some Win32 applications using the micro-windows part of nano-x is there. Also, nano-x works with a wide variety of operating systems and on a wide variety of hardware.

There are several options for Linux distributions that try to attract Windows users either with Windows look-alike GUIs or with WINE offering the ability to continue to run real Windows programs. However, what is there that's been designed to appeal to those of us who are command line users and want to make a switch? Other than distributions used for restoration or rescue systems like grml and distributions that target minimal systems such as Linux distributions you can run from a floppy or CD, there really aren't many distributions that emphasize a command line interface. There are even less if you're looking for active distributions. Termux is an exception and it targets Android users.

Shells like bash or ash may offer more functionality than batch files, but what competes with Powershell on Linux? At least Mono offers an alternative to .NET. Also, someone who works with a lot of batch files may not find the switch from batch to a shell script all that easy. Backslashes are replaced by forward slashes. Commands like cp and mv are similar to copy and move but don't quite work the same way. Type copy filename in a command line on Windows or DOS and it copies the file to the current directory. Try that in a bash shell with cp and no target file name and you could end up with a mess. Similar syntax that works on Windows may end up corrupting files on Linux/BSD/Unix. If a user isn't already familiar with bash, ash or some of the other shells used on Linux, it's not an easy switch. Just switching between a csh and bash can be a real nuisance to Linux users. Imagine switching from batch to bash.

FreeDOS used to be able to run embedded with Linux systems much the way Windows used to allow users to switch between Windows and DOS. I don't know if that's still an option with Linux distributions and FreeDOS, but DOSBox can make a useful alternative if you want to run Linux and some form of DOS together. Using FreeDOS or DOSBox with Linux allows people to keep working with batch and already created batch scripts. The one drawback with DOSBox is that it doesn't allow for long filenames (beyond the 8.3 convention). There may be some patches to DOSBox that fix this. If so, I would love to find them.

I like the idea of using JavaScript at a command line. It makes an interesting alternative to a shell script. Windows offers this option as part of its wsh system. However, the JavaScript used by Windows is non-standard. It has several extensions not used by other JavaScript implementations such as commands to work with the file system. I looked into projects like TeaJS that work on both Windows and Linux systems as a scripting option. NodeJS seems to have become the de facto standard for command line JavaScript. Plus, it's a cross-platform solution. The main drawback I've heard regarding NodeJS is that the API changes rapidly. So, it's not a very stable system to create command line scripts that you want to be using for years to come.

What are some FOSS operating system options that might appeal to command line users? One could start with a minimal system like Debian netinst or AntiX or TinyCore Linux or possibly some of the musl based distributions. Distributions with large software repositories may have some useful command line applications. Inconsolation showcases many console based apps available from repositories. However, some applications may be dated, not actively supported or have such limited usage that they aren't easily found in a repository. In those cases, it may require building them from source if someone wants to work with them. So, no particular Linux distribution really stands out to me as the best migration path for console users who want to switch to a FOSS system.

For me, the easiest migration path is to have FLOSS programs that work on multiple operating systems. I can use them on a FLOSS operating system, but I can also use them at work where we are required to use closed and proprietary operating systems. If a cross-platform FLOSS program saves data in a particular format, it's likely to use the same format across multiple operating systems. It makes it easier to work with and transfer data. It also helps when the commands you learn, function the same in multiple environments.

Here are some command line tools I use on multiple platforms. I do a lot of my music creation using abc2midi and abcm2ps. I use TiMidity++ in console mode or via command line to convert midi files to wave files. I use diffh and a web browser to view file differences. lxsplit is nice for splitting and joining large files. I use lynx to check if a web page is browser-friendly and accessible. I use a lot of archive tools, communications tools such as curl and putty's plink and psftp, database connection tools, etc. from the command line. There are calendar programs like lcal, dictionary and grammar programs such as sdcv and diction, timer programs and more. There are even programs to draw or edit graphics such as gle, netpbm, imagemagick and graphicsmagick and programs to create DVDs such as dvdauthor.

There is a pattern I've seen with Linux for a long time now. There are great FLOSS program options that appeal to many types of users including those who prefer the command line. With software, having lots of choices can be a positive. However, with operating systems, choice isn't always so positive. There are so many Linux distributions and FOSS operating system options, it's difficult to find one that's user friendly and a good fit. With Windows, there's just one source for it and programs that work on one Windows system work on another Windows system. With Linux, it's not one size fits all. There are so many alternatives and often, none seem to be just right. It's hard to use software from one Linux distribution in another, let alone try to get your Windows executables to run properly. Maybe if more of the Linux community adopted the Linux from Scratch motto of your operating system, your way, it would be easier to switch. However, with lots of Linux operating systems, each with their own niche and their own emphasis on certain features and distinct avoidance of other features, it makes it hard for a user that doesn't fit a specific demographic to use a particular distribution. It's even harder for someone who wants to volunteer efforts to help out a distribution to find the right distribution that would accept the type of help he or she would like to offer.

FOSS is supposed to give users a way to get off the merry-go-round of continually needing to pay to upgrade hardware and software. However, it's not always easy to make that switch. Just offering an operating system that outwardly looks similar to a Windows solution so it will seem familiar isn't always desirable. It can be harder for users when software seems almost alike but certain parts don't work the same way or may potentially have devastating results. The cp command overwriting files that copy wouldn't is a good example. Offering GUI solutions to attract Windows users who primarily use the command line is just not an effective strategy.

What techniques or features would make the switch from another operating system easier for you? If you're like me and prefer working in a console based environment, what would your ideal operating system look like? Have you found a FLOSS distribution or FLOSS tools that fit well for you? Please feel free to share some of your more useful FLOSS finds with me on Mastodon.

I remember sending in a bug report to the developers of GNU make. They refused to fix the bug because cygwin and msys bash were, in their opinion, the only viable shell options on Windows and the only environments they wanted to officially support. When I tried to build autoconf with a natively built version of make on Windows, it just hung. There's also the problem of using make on Windows without a shell. The command prompt has a limitation of how many characters can be passed to it. Typically, it's not enough to be able to run many of the commands used in standard makefiles. So, using make with a shell on Windows is a requirement to work with typical makefiles from many Free, Libre and/or Open Source software projects.

Several years later, the landscape for Windows has changed. It's still incredibly hard to find a standard port of POSIX shells outside of Cygwin, msys and now msys2 projects. However, there are options. Some of the older options that were around when I reported the bug are winbash (an older version of bash natively ported to Windows) and winZsh (which has not been maintained for a while). More recently, with the port of busybox to Windows in the busybox-w32 project, we have access to a modern shell. That project makes the ash shell available. It can run natively in Windows. The one drawback is that you need to build busybox-w32 on a Linux machine with a cross-compiler. I did recently manage to build ash natively on Windows with a lot of patching and my own custom makefile. Another option is to use midipix to build bash or other shells but it has similar licensing constraints to Cygwin and the msys projects. An alternative that I haven't seen a lot of information about is using bash from WSL via the Windows command prompt. You actually don't need msys or similar environments with this option. You can run a cross compiler and Linux tools via WSL and access them all from a standard Windows command prompt outside of WSL. That opens up a lot of possibilities. There were other projects that were supposed to port shells to Windows that still haven't shared much in the way of results. I remember offering to work with the developers of the mksh to port it to Windows. They said they already had someone working on the port. I've yet to see a publicly available, natively built mksh running on Windows. Plus, with all these Windows shell options, I still haven't seen a fix to the GNU make project. I do continue to patch my builds of make with my own patch for the issue.

WSL is great for development on Windows. Even with WSL, Busybox-w32 and environments like Cygwin, msys2, msys and midipix, I still like the idea of a minimal native build system and shell. I'd like something I can build from source for myself on Windows. I'd also prefer to use tools with more lenient Open Source licenses over GNU GPL and AGPL options. I'm going to be experimenting with replacing the msys environment on my system with more native options that don't obscure my actual file path names and don't require compatibility with GPL licenses to get POSIX style core utility programs to work. I will still need some standard POSIX style utilities and programs if I want to build FLOSS projects that use GNU autotools. However, I've been avoiding using cmake for FLOSS projects that use it by creating my own build files. I may start doing that in the case of some FLOSS projects that use GNU autotools. libressl comes to mind since a change to their build scripts made them no longer work on Windows and I've yet to hear if they'll fix the issue or not. I've been using cDetect, GNU make and pkgconf for my build scripts. I wish someone would come up with a simpler replacement for GNU make that still offered enough flexibility to build FLOSS projects that require make.

The build environment I'm working towards will probably look like the following... I'm building ash from Busybox-w32 natively with my own scripts. I'm using a combination of POSIX style core utilities from projects such as Minix, sbase and BSD. I'm hoping for compatibility with Open Group standards not necessarily with GNU standards for the various utilities. At the moment, I'm using the GNU gcc compiler built from source. However, llvm is a nice option. I just haven't seen an easy way to build it from source on Windows. My main goal is to be able to build all parts of my environment from source code. It may not have as many features or as much compatibility as other development environments available on Windows. However, I like the idea of being able to modify and change the source code of every tool I use whenever I want to. One other thing I'd like to look for is a console program that I can build natively with my C compiler. If I get everything working for Windows, a lot of it will probably port to other environments fairly easily.

I know most people prefer to just download a prebuilt environment or let their package manager do that for them and they don't care about the ability to build every part of their development environment from scratch. However, if this does sound interesting to anyone else, if you're working on something similar or if want to discuss parts of this project with me further, feel free to contact me. You can reach me via Mastodon or Bluesky.

Slow Android emulators to test Android programs may be a thing of the past on my current Windows system. I downloaded and installed Windows Subsystem for Android. It's a convenient way to test out apps you've created without having to resort to installing VirtualBox and Android x86 or using other alternatives such as Qemu or some of the very slow Android app emulators.

If you want to try out other Android apps on your Windows system, you can do that as well. It may not look like there's a wide variety of apps to choose from at first glance. Windows Subsystem for Android comes with Amazon Appstore instead of Google Play store. I've seen some reports of getting Google Play store working but it doesn't seem worth the effort and really isn't necessary. If you're just going to test your own apps, you don't need an entire app store. However, it is fairly easy to get F-Droid installed on Windows Subsystem for Android. Most of the apps from F-Droid work very well in an emulator. F-Droid had more than enough apps for my needs. Also, there are other repositories such as IzzyonDroid that can be added to F-Droid giving even more options to choose from. Finally, there are sites, such as APKPure, that will allow you to download apk files directly. Once you have the apk file, you can install the app yourself.

The basics for installing apk files in Windows Subsystem for Android follow. First, download a copy of the Google Android platform tools for Windows. adb is the program that is required from the platform tools. Start up an Android app, any Android app, in Windows Subsystem for Android. This makes sure that Windows Subsystem for Android is currently running. At the command line, type:
adb connect 127.0.0.1:58526

Once a successful connection is made, most apk files can be installed from the command line using a command similar to the following:
adb install file.apk
Substitute the actual name of the apk file for file.apk in the command.

What if you have an xapk file instead of an apk file? Rename it to a zip extension. Use a tool like unzip to extract the files in the xapk. Use the command adb install-multiple with a list of the extracted apk files.

That's all there is to it. Once that's done, you can easily install Android apps and run them on Windows. I found some actually run better on Windows than on a phone. However, some did not fit the screen well and some required Bluetooth which is not yet supported in Windows Subsystem for Android. Still, you can run quite a nice selection of apps and you can use it to test your own Android apps as you develop them.

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.

While WSL is great, I've always wanted a native POSIX environment for developing on Windows. I wanted one that didn't require specialized DLLs with GNU GPL licenses such as as Cygwin and MSYS do. There are other options available. Midipix provides a POSIX environment for easily porting and developing POSIX compliant applications on Windows. The licensing isn't any more lenient than Cygwin though. It does use the MUSL C library which is a nice feature. There's AT&T's Uwin project which is now available as Open Source: https://github.com/att/uwin The license for the project isn't exactly compatible with GPL software. I've looked into native POSIX shell alternatives to those found in projects like Cygwin and msys. Bash is not easy to port to Windows without Cygwin or msys DLLs to support various functionality. It isn't exactly easy to port to DOS either. Most bash ports to DOS and Windows are older ones. One Windows port that builds successfully on Windows with MinGW32 is: http://win-bash.sourceforge.net/ I investigated the mksh project at one point and even offered to work on a Windows port. They were not in the least bit interested and already had some commercial company looking to create a port to Windows using there own proprietary code to provide a POSIX compatibility layer. So even if their plan was successful, it wouldn't exactly provide a native Windows port anyone could use in their projects. Tcsh has support for Windows. Zsh was also very popular on Windows. Checking the versions of zsh, the latest Windows version I could find that compiled with no issues using MinGW32 was 3.0.8.1: https://github.com/oldfaber/wzsh The zsh project seems to have progressed to a much later version since then. I've also experimented with Swiss which provides a Busybox-like set of tools with a shell. Speaking of Busybox, there is a port of it to Windows which provides an implementation of the ash shell: https://github.com/rmyorston/busybox-w32 Unfortunately, the build system works in such a way that you need to cross-compile it to get anything to build properly. Even after attempting to cross-compile using the source code, I still ended up with a program that crashes on exit. The busybox-w32 executables at the official sites don't seem to have that problem though. So much for being able to reproduce an executable others are distributing just from the source code.

I have several programs that could replace a lot of the core and basic utilities found on POSIX systems. I even have an older version of make patched to work with a shell of my choice rather than requiring Cygwin or msys DLLs or producing a crippled native version of make that can't handle long command lines. I had discussed the option of getting make to work with other shells besides Cygwin or msys with the developers of make at one point. I had sent them a patch for an issue with using make natively on Windows without a shell. The developers weren't interested in Windows support beyond using Cygwin or msys bash shells. I have older versions of GNU autotools patched to run natively and work around the slash versus backslash file delimiter issues. So, I think I could put together a native POSIX environment for Windows that could be used for development with a command line compiler. However, I'm still left with the decision of how to replace the msys bash shell. It would be very nice to avoid Cygwin and msys and not have the limitations on directories that these programs impose. For instance, they assume / and /usr are in the same locations so /bin is the same directory and in the same physical locaton as /usr/bin. A Windows native POSIX shell option would be ideal. The only question is which shell to go with.

Likely Windows shell candidates at this point are older versions of bash, zsh and ash. It would be nice to find some other options or hear from others interested in native Windows development as to what their POSIX shells of choice might be. If anyone else is interested in developing natively on Windows using a POSIX-like environment, feel free to contact me to discuss the situation further, add your suggestions or brainstorm some new ideas: http://www.distasis.com/connect.htm I'd love to be able to put something together similar to the gnuwin32 or unxutils projects but with more up-to-date utilities. It would be great to have input from others looking to create or piece together their own POSIX development environments on Windows.

I've been reading a lot about WSL. It's a great way to run Linux in Windows without needing a virtual machine like VirtualBox or Qemu installed. However, the earlier versions of WSL only ran command line or console based programs. If you wanted to run X Windows programs, you needed an X server. Well it just so happens, I've built the X server on Windows from source and all the packages for it. I've recently been testing remote access to X Windows programs on an AIX machine at work. From those tests, I found X forwarding using tools like putty and a Windows based X Windows server can be rather slow. My experiments with sixel weren't very satisfactory. The other protocols I investigated were vnc and xrdp. Both offer faster alternatives to X forwarding or other techniques I'd tried.

I did not make a lot of progress with the vnc protocol. I was able to build sdl_vnc from source. I had issues with building libvncserver because they're using cmake which never works properly for me. Was able to find an older version that uses GNU autotools and get that working though. Another interesting project is spiritvnc which uses libvncserver and provides a front end using FLTK.
https://sourceforge.net/projects/sdlvnc/
https://sourceforge.net/projects/libvncserver/
Eventually I was able to build two SDL based vnc clients from source code. Unfortunately, there isn't much in the way of documentation and I really couldn't get theTto do much. If anyone finds any decent documentation regarding vnc and either of those clients, please let me know.

Xrdp looked like a very promising option especially when I read that performance was even better than vnc. There isn't an xrdp package for AIX, but there is one for Debian via WSL. So, I decided to investigate. I found several articles on how to set up xrdp for WSL. That was surprising since so many articles I've been reading discussed how hard it was to access WSL based X Windows applications and the need for Microsoft to add GUI support in WSL 2.

It was also surprisingly easy to get working. I used sudo apt-get install xrdp to install it. I added my window manager of choice, jwm, and a few X Windows based test programs, SciTE and tuxmath. The documentation said to add the xrdp user to the ssl-cert group:
sudo adduser xrdp ssl-cert
Then it said to edit /etc/xrdp/xrdp.ini. I did so with nano. I changed any instances of 3389 to 3390. I commented out max_bpp=32 and added nmax_bpp=128. I added nxserverbpp=128 after #xserverbpp=24 which was already commented out. I started the system using:
sudo /etc/init.d/xrdp start
Then, all I had to do was use the remote desktop connection program on Windows and connect using my WSL username and password. When you connect, use computer name: localhost:3390 Everything came up with no issues. I tried out Xfireworks, SciTE and tuxmath. They ran very efficiently considering they weren't running as native Win32 applications. (I also have Windows versions of all these programs.) I was really pleased with the results. I think this method probably works even better for me than upgrading to the latest WSL and using the Microsoft GUI support (which I have tried on one of my computers). Now if I could just get a solution like this working on our AIX system at work, we'd be all set. It would also be interesting to see how this works with Wayland and rdp support in place of xrdp.

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.

We're using PostgreSQL at work. We've been using PGAdmin3 for a while now even though PGAdmin4 is available. PGAdmin4 is mainly browser based and can run slowly compared to the previous incarnation of PGAdmin. PGAdmin3 is a C++ program that uses the wxWidgets API and runs locally on a computer. PGAdmin3 is cross-platform, so it works on Windows, Linux, BSD and other systems where wxWidgets will run. My main issue the PGAdmin4 other than the slowness is the lack of the server status functionality which we use quite a bit with PGAdmin3. I did recently notice a dashboard option in PGAdmin4, but it doesn't give any real information on queries. The server status page basically gives a sortable table with the information from pg_stat_activity. I'd love to find a similar utility to provide this functionality, but so far, have not been able to. Suggestions would be greatly welcome.

Since I haven't been happy with PGAdmin4 and I do prefer PGAdmin3, why not keep running PGAdmin3? Debian has patches for PGAdmin3 to help keep it working with later versions of PostgreSQL. There are several forks of PGAdmin3 that attempted to keep it working once the official developers stopped development and switched to PGAdmin4. Combining some of these patches, I'm able to get a working version of PGAdmin3 built from source on Windows using wxWidgets (and the standard wxWidgets configuration settings I use on my system including --enable-stl). We needed a 64 bit version, so I built it with MinGW64 even though I typically prefer the original MinGW project and use it whenever possible. I should mention that the original PGAdmin3 source code never supported wxWidgets with STL enabled. I've also seen some reports of issues building for 64 bit systems instead of 32. Looking at the code, I can certainly see why those are issues. I went through and patched for both issues, including fixes for some problem areas that did not use best practices when converting from integers and longs to pointers and back. It's not perfect, but I have PGAdmin3 working with PostgreSQL 12 and providing the same functionality I used when I was working with PostgreSQL 9 databases.

I would love to find a fork that intends to actively continue development of PGAdmin3. Would be happy to add my efforts to such a project. If you know of a viable project, please advise. If there are no active forks, I intend to keep what I have running for as long as I need it at work. If others would like to help in that effort, it would be great to hear from them.

I also have PostgreSQL 12 built from source using MinGW64. We wanted to use pg_repack. I have not been able to find the pg_repack plug-in on Windows, so I built it from source as well. It needed some patching to compile successfully on Windows. I've been investigating what other PostgreSQL tools build on Windows using MinGW. So far, I have pgstats ( https://github.com/gleu/pgstats ) compiling. I may put in the effort to get pg_top working natively on Windows as well depending on whether we need the functionality or not. Suggestions of other cross-platform Open Source programs and utilities that would be useful with PostgreSQL would be greatly appreciated.
You contact me at: http://www.distasis.com/connect.htm
Write me if you want to help out.

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

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:

eglibc:
http://www.eglibc.org/home
uclibc:
https://www.uclibc.org/
musl:
https://www.musl-libc.org/

Linux from Scratch build instructions (including musl)
http://clfs.org/view/clfs-embedded/arm/
midipix
http://midipix.org/
BSD regular expression library
(Musl regular expression support was forked from this library.)
https://github.com/laurikari/tre

PDCLib:
http://pdclib.e43.eu/
Original Public Domain C library:
https://sourceforge.net/projects/pdclib/
https://sourceforge.net/projects/pdos/
Another fork of PDCLib:
https://github.com/DevSolar/pdclib
libTom Public Domain libraries for math and cryptographics functions
(Some of musl's functions were forked from these.)
http://www.libtom.net/
libc11:
https://github.com/dryc/libc11
Eltanin-OS simia:
https://github.com/eltanin-os/simia

Bionic:
https://github.com/android/platform_bionic

Newlib:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree
libgw32c:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

Windows CE cross-compiler:
http://cegcc.sourceforge.net/
https://sourceforge.net/p/cegcc/code/HEAD/tree/

ELKS
https://github.com/jbruchon/elks

FUZIX
https://github.com/EtchedPixels/FUZIX

lib43:
https://github.com/lunixbochs/lib43

Embedded Artistry's libc:
https://github.com/embeddedartistry/libc

GNO
https://github.com/GnoConsortium/gno

Sortix C library:
https://gitlab.com/sortix/sortix/blob/master/libc/

MentOS:
https://github.com/mentos-team/MentOS/tree/master/libc/src

olibc:
https://github.com/olibc/olibc

CloudABI's standard C library:
https://github.com/NuxiNL/cloudlibc/

cc65 - C for 6502 systems:
https://github.com/cc65/cc65

kLIBC fork for OS/2:
https://github.com/bitwiseworks/libc

clib2 for Amiga
https://github.com/adtools/clib2

welibc:
https://bitbucket.org/wrelam/welibc/src/master/

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

There are two work-arounds for the issue.

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

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

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

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

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

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

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

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

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

This post includes a list of resources for building applications and libraries for Windows using MinGW or similar projects.

Just wanted to note some of the native Windows porting projects I've worked on before I list some of the other projects out there. I've compiled the X server code and built a X server on Windows (similar to the Xming X server but with all my own patches). I'm looking into porting msh to Windows and other platforms (including patches for better handling of internationalization/UTF-8 character codes). I'm working on porting various core utilities based on Minix, BSD and custom implementations. I have patches and build scripts for several Open Source libraries and programs. See http://www.distasis.com/cpp/lmbld.htm for further details and a link to some of the scripts and patches. I work with regex and fnmatch libraries based on MIT licensed code from musl. musl uses regex code from the BSD licensed tre library. I also work with a BSD gettext implementation based on code put together for PostgreSQL. The libiconv and iconv implementations I use are written from scratch using custom UTF-8/internationalization code. I also have my own custom implementations of libmman, libdl and pthreads as well as other libraries I use to help with porting applications.

Places to download builds of various Open Source software and libraries for Windows and MinGW:

http://gnuwin32.sourceforge.net/
Many of the GNU libraries and programs patched and recompiled for MinGW.

http://devpaks.org/
Devpaks repository Libraries for the Dev-C++ compiler which uses MinGW. Could also be used without Dev-C++. Files should be standard tar.bz2 files renamed with .devpak extension.

http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/
OpenSuse Windows Packages has windows packages cross-compiled using MinGW on OpenSuse and the OpenSuse Build System (OBS).

https://sourceforge.net/projects/ezwinports/
ezwinports has ports of Unix and GNU software to MS-Windows.

https://sourceforge.net/projects/mingwrep/
MinGW packages repository

https://sourceforge.net/projects/takeoffgw/
TakeoffGW - Cygwin style package manager and native Windows packages built with the OpenSUSE Build Service.

Patches and build scripts to build Open Source software for Windows:

https://github.com/Alexpux/mingw-builds
https://github.com/mxe/mxe

MSYS and Cygwin alternatives:

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

https://github.com/bmatzelle/gow/wiki
GNU on Windows - lightweight alternative to Cygwin. Native Win32 programs.

Busybox port for Windows:
https://github.com/pclouds/busybox-w32
Lightweight versions of core utilities.

Busybox-w32 fork:
https://frippery.org/busybox/

http://unxutils.sourceforge.net/
UnxUtils - Native Win32 ports of core utilities.

https://github.com/rubenvb/UnixToolsForWindows
Unix Tools for Windows - Native Windows implementations emulating core utilities written in C++.

http://sourceforge.net/projects/win-bash/
Native Win32 port of an older version of bash.

https://steve.fi/Software/bash/
GNU Bash for Windows

https://sourceforge.net/projects/zsh-nt/?source=directory
WinZsh - Z shell for Windows

http://www.straightrunning.com/XmingNotes/
Xming X Server - Windows native X server

Open Source libraries patched for Windows:

http://waterlan.home.xs4all.nl/libintl.html
Relocatable libintl for MinGW.

https://github.com/dlfcn-win32/dlfcn-win32
POSIX dynamic runtime library loading (libdl) compatibility routines.

https://code.google.com/archive/p/mman-win32/
POSIX mmap functionality.

http://synesis.com.au/software/unixem.html
Various POSIX functions implemented for Windows.

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

Pthreads and C/C++ 11 threads compatibility patches and implementations:

https://sourceware.org/pthreads-win32/
pthreads-win32 - Red Hat's POSIX thread library for Win32.

http://jmhartsoftware.com/Pthreads_Emulation.html
Simplified Pthread Emulation with Macros - Minimal pthread emulation.

https://tinycthread.github.io/
TinyCThread - C11 threads implementation

https://github.com/jtsiomb/c11threads
c11threads - GNU compatibility headers for C11 thread support