lmemsm | Entries tagged with c/c++

I was tasked at work to find some monitoring tools for AIX. I'm familiar with AIX Toolbox and a few third party repositories. I wanted to build some programs from source code. I use a lot of portable programs and can port them to wide variety of platforms including AIX. However, monitoring tools in general are usually not too portable.

We already have nmon on the system. I also found source code for a related program njmon, but it's mostly for gathering statistics and then some kind of reporting utilities are needed to make sense of the data. I looked for top, but couldn't find it. Read that topas is available instead. I couldn't locate any source code for topas, so I guessed it was closed source. Just confirmed that. It's based on nmon for AIX code which is closed source. So nmon in AIX is not Open Source either. I would prefer to use Open Source tools so the source code can be modified if needed and so I can maintain and patch the software if necessary. Decided to try to build htop and it built on AIX with some patching. However, it didn't display anything and said platform unsupported. I found some old patches for AIX for an older version of htop that's not even in the current htop repository. I was able to incorporate the older patches into the latest version and get system related information to display. I contacted the htop project, but they're not at all interested in adding AIX support even if patches to do so are supplied to them. So, I'm debating whether to use a patched htop on AIX or whether I should look for another utility that can do a similar job but would be a better option for AIX systems. I found an old version of top that had AIX 5 support. It works fine on AIX pretty much as is. I've used saidar on BSD systems. It's part of libgrabstat. It built fine from source on AIX. I know there's an uptime utility on the system, but it should also be fairly easy to create a simple, portable uptime program that would work on a variety of platforms including AIX and Windows.

We also installed nano on AIX at some point. I think it's been removed from the AIX Toolbox since then. It's an old version of nano and seems rather buggy. When using nano via ssh, the scrolling gets really messed up. Rebuilt nano from a later version of the source code. It seems to work fine.

I'll be looking for other command line utilities that are somewhat portable and may work on AIX. Will add the results of my search here. If anyone runs across some useful tools that have AIX support or that port easily to AIX, please let me know. If anyone's interested in sharing code, patches or programs, contact me. Would also be very interested to hear what FLOSS programs others are using often on AIX systems.

I do a lot of Open Source development just for me. Basically, it's the philosophy of scratching an itch. If there's something I want and no one's working on it, I work on it on my own. True to Open Source philosophy, if I want something done, I do it myself. I typically assume not many other people will be interested in what I'm interested in anyway.

However, it is nice to have a community. It's helpful to have other developers to discuss designs with or other users to test out new programs or people to help find new and interesting code and resources to explore. I've asked before in various places, but I'm going to ask again here and now. If anyone knows of a FLOSS project in need of volunteers, please share information about it with me. I'd be happy to add them to my list of FLOSS projects looking for volunteers. I also really want to find a project that's a good fit with my own goals and donate some of my time and expertise.

I work a lot with lightweight, cross-platform FLOSS applications and build them from source, modify them, fix bugs, add features, etc. I've ported applications to a wide variety of platforms including more unusual operating systems. I would love to get involved with a small Linux or BSD distribution or even an original or unusual operating system and port and/or build some programs for it. I also use Windows a lot and would be happy to help out a Windows or DOS project that's involved in building FLOSS applications. I have a lot of experience porting FLOSS programs to operating systems like these. I do have my own build system/package management tools and I'm not interested in switching to another system at this time. I also have my own preferences as to which libraries I use when building applications. At this time, I'm working primarily with C and occasionally with C++. It would be fun to get involved with others interested in making their own distribution or putting together FLOSS applications to share with people.

So, if you know of a project that might need help or have a project you're working on that's in need of volunteers, please let me know. If you just want to compare notes on lightweight and/or cross-platform portable software or you want to talk about C programming in general, feel free to contact me. More contact information available here: http://www.distasis.com/connect.htm

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

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

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

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

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

Was recently commenting on a forum about how few Open Source alternatives there are for Android devices. The Free Software Foundation even had a wiki page about how development for mobile devices was a priority. However, when I wrote to them on the subject, they didn't bother to acknowledge or answer my e-mail (until just recently, two years later).

There are some good Open Source projects out there for Android. However, many commercial apps and even the Open Source applications appear to be trying to reinvent the wheel. They're redeveloping concepts that have already been done in other languages and with other build systems. Worse yet, they're making a lot of the same programming mistakes of earlier projects without learning from them.

I truly believe that taste varies widely as far as what people like in a program or application. To one person, an expensive commercial office suite or graphics program is a highly necessary tool. To someone else, it's too complicated and tries to do too much at once. What one person feels is a compelling, action-packed and exciting video game can be boring and mindless to another person. With that said, I'm sure my taste in programs does not match what many others are looking for. Personally, I do find the Open Source applications I ported from other operating systems to Android to be among my favorite Android apps. I'd love to find to locate other projects that are working on similar ports of popular Open Source applications.

Since I'm primarily interested in C/C++ development at this time and I've always been an advocate of cross-platform programming, I've been searching for good references and examples of C/C++ application development for Android that do not lock the developer into using a specific IDE or build system. Most books on Android development are for Java or Kotlin. There are even a good number that use web apps or web development languages likes JavaScript/HTML/CSS including projects like PhoneGap, ReactNative, NativeScript, etc.

There are very few books on NDK development for Android. All of the books I've found so far detail development with Android Studio (or Eclipse for older books that have not been updated in a while). SDL is typically mentioned with NDK development even though there are other development libraries that work with Android. Some don't mention libraries like SDL at all, but then you're limited to examples similar to those provided by Google or very basic applications. There are a few interesting articles on porting applications from other operating systems to mobile devices, but I've found no books that specialize or give much in the way of advice in this area.

I've been considering writing an e-book that fills in the gaps and gives examples of how to develop cross-platform applications that easily port to Android and use NDK plus a more a standard tool-chain. The only thing holding me back is the idea that there would probably be very few developers other than myself interested in this sort of thing. Obviously groups like the FSF weren't interested or they would have taken the time to answer an e-mail. If there is interest from other developers on sharing this type of information, please let me know.

I mentioned on a forum how much I'd like to see a list of available Open Source applications for Android (preferably cross-platform portable applications written in languages other than Java). It would be nice to see what others have done and get ideas for development based on them. Since I really haven't been able to find a resource like that, I'm putting together the start of such a resource here:

C/C++ SDL based apps ported to Android:
https://github.com/pelya/commandergenius
https://sourceforge.net/projects/libsdl-android/files/apk/
Terminal emulator in Java and cli and ncurses based applications ported from other systems:
https://github.com/termux/termux-packages/tree/master/packages
VLC for Android:
https://www.videolan.org/vlc/download-android.html
List of Open Source Android applications. Includes information on language the program was written in. While there aren't a lot of C/C++ applications listed there are some:
https://github.com/pcqpcq/open-source-android-apps
Similar list for iOS Apps:
https://github.com/dkhamsing/open-source-ios-apps
Another list of Open Source applications (unfortunately no indication of the languages they were written in or the build systems required):
https://en.wikipedia.org/wiki/List_of_free_and_open-source_Android_applications
Project for mobile devices (mainly Qt based):
https://ubports.com/
Repository and app store for Open Source apps (mainly Java apps):
https://f-droid.org/en/about/
CrystaX NDK provides and alternative to Google's NDK:
https://www.crystax.net/android/ndk

If you know of other Open Source C/C++ software for Android, please advise and I'll add it to the list.

Here are a couple of interesting articles on Android. The first is a list of alternatives to Google's online app store for Android:
https://android.izzysoft.de/articles/named/android_markets_safe_to_use
The next article is about how to make Android a little more Open Source friendly by stripping it of some of the more proprietary apps:
https://android.izzysoft.de/articles/named/android-without-google-5

Another site with information on removing proprietary libraries from Android devices:
https://microg.org/

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

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

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

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

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

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

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

The Android developer web site actually has some decent information on how to create a stand-alone C/C++ toolchain. You currently need Python to create the toolchain, but they actually supply a version of Python for operating systems that don't easily offer one.
https://developer.android.com/ndk/guides/standalone_toolchain.html#selecting_your_toolchain
See also:
https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html
http://mobilepearls.com/labs/native-android-api/ndk/docs/STANDALONE-TOOLCHAIN.html

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

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

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

I find it useful to know what native C/C++ functionality/which libraries are supported for various versions/APIs of Android:
https://developer.android.com/ndk/guides/stable_apis

I thought this site had a good series of posts on how to port a SDL based application to Android:
http://blog.stuff-o-matic.com/post/2013/10/20/ASGP-s-Android-Port-Part-IV%3A-building-the-APK

If you're interested in using dynamic libraries, this site had some useful information:
https://www.andriydruk.com/post/introduction-to-c-for-android-developers/

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

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

Another option is to use adb (Android Debug Bridge) to test the results on an actual Android device. Now that Windows Subsystem for Android is available, you can also us it to run Android apps and use adb to side load the applications you want to test. Here are a couple of articles that give examples of how to work with adb:
http://nickdesaulniers.github.io/blog/2016/07/01/android-cli/
http://codeblog.vurdalakov.net/2016/12/build-and-run-native-c-cpp-android-apps-with-ndk.html

One thing to keep in mind if you're going to test on your own Android device is that Developer options must be activated on that device first. Here's an article on how to do that:
https://www.embarcadero.com/starthere/xe7/mobdevsetup/android/en/enabling_usb_debugging_on_an_android_device.html

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

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

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

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

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

More recently, I ran across Android Apps in C. It uses Android Studio which is a lot of overhead if you just want to build an application. Also seems to use WSL on Windows instead of direct development on Windows. Seems to use the standard android_native_app_glue code. However, there may be other tips and tricks that are useful when creating a C/C++ application for Android. The project is at:
https://github.com/cnlohr/rawdrawandroid

That's pretty much all my searches have turned up as far as resources I've found useful for building C/C++ applications targeted to Android devices. If you have other reference recommendations that explain how things actually work (rather than glossing over the details and using a GUI interface), please let me know. If you'd like to share or compare notes on patches, compiler/linker options for building various Open Source libraries and applications, I'd enjoy hearing from you. You can discuss C/C++ Android development further with me and other interested developers on the CppDesign mailing list.

I've been looking for useful, efficient, user-friendly alternatives to build tools like GNU autotools and cmake. I've even created lists of build tool alternatives at various wikis and sites related to programming and compilers. If there's interest, I can post some of that information here along with pros and cons of various tools. I think, during my searches, I've found some good alternatives for my own projects and to use with my own build script generator.

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

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

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

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

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

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

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

If you'd like to try out CDetect with my patches or see some of the build scripts I'm using with these tools, check out the archive link on my LM BLD system page:
http://www.distasis.com/cpp/lmbld.htm

I've added several features to my patched version of CDetect. Check the notes.txt file for details. I'm currently making some new modifications and would love input from other developers/users. If you'd like to make suggestions or compare notes, please contact me through the CppDesign mailing list or my web site:
http://www.distasis.com/connect.htm

Recently needed to find Open Source load testing software. A couple of things surprised me. Most were written in interpreted languages or Java. Most were platform specific and only worked on Linux or sometimes POSIX systems. Since my preferences are cross-platform C/C++ programs, it was difficult to find load testing software to my liking. Here's a list of some load testing programs that looked useful.

openwebload (aka openload) - http://openwebload.sourceforge.net/
This was the only cross-platform C++ program in the group. The major limitation was that it didn't seem to handle load testing of secure web sites (URLs with https). It also hasn't been updated or maintained in a while, but that never deters me.

wrk - https://github.com/wg/wrk
This was the most interesting of the options I found. It's configurable using lua scripts. However, I was only able to get it to hit one page at a site. So, if you want to emulate things like logging in and navigating a site, that could be difficult. wrk uses code from nginx and other Open Source projects. There are some sample lua scripts, but documentation on how to write your own was rather sparse.

httperf - http://www.labs.hpe.com/research/linux/httperf/
This looked like a very useful tool, but I received web responses mainly in the 300s (3xx) range for the URLs I was testing.

autobench - http://www.xenoclast.org/autobench/
This is a Perl script that works with httperf. It can run httperf multiple times and increase the number of connections each time. It can also output a graph of the results. Since httperf was returning 3xx web responses for my tests, autobench did so as well.

curl-loader - http://curl-loader.sourceforge.net/doc/faq.html
This looked like a highly configurable program that could perform some interesting tests including navigating sites. However, it was very hard to set up even after reading through whatever documentation I could find. I actually froze the test machine where curl-loader was installed at one point and had to restart the machine.

Apache bench - https://httpd.apache.org/docs/2.4/programs/ab.html
This is typically a part of an Apache installation but it can be used to load test other servers including nginx which was my target. Some articles said the technology used by this program was dated and that results might not provide a true picture. However, the program seemed to work fine for my test cases and didn't have an issue with secure URLs. The nice thing about it was that it was fairly simple to use compared to some of the other options.

It's also useful to have curl around when load testing. Once can check URLs with curl and see exactly what's being returned before using the URLs with the load test software.

I'm working on several projects. One of my goals is to be able to port any of the SDL 1.2.x programs I use so they'll work with SDL 1.2.15 or with SDL 2.x. So far, I've added SDL 2 support to PDCurses. I believe some or all of those patches made it back into the official version. Other programs I've added SDL2 support for include bard, picaxo, sfontview, unifontview, perigee, SDL_Draw, pong, drac, yahtzee. More are in the works including Tuxmath. Bard is a lightweight epub reader with text to speech support. Picaxo is a lightweight graphics viewer. Sfontview is a lightweight TrueType font viewer. Unifontview is a font viewer that shows a font's entire character set including Unicode characters supported. Perigee is a graphics slideshow program. SDL_Draw is a graphics library for simple line drawing with SDL. I'm currently using it with wavetools to do the line drawing for a lightweight wave file viewer. The wave file viewer also builds with SDL 1.2.x or SDL 2.x.

Code/patches for many of the modifications I've made are available from a link at:
http://www.distasis.com/cpp/patches.htm
I'll be adding more modifications to various projects over time. Feel free to write if you're interesting in discussing a particular SDL 2 conversion further.

There are now several forks of MinGW and each has its pros and cons. However, there are now enough negatives to using them, that I've found it necessary to build MinGW from scratch myself. The MinGW64 project uses a later version of gcc, has better compatibility for building Open Source projects and has its own thread library instead of using Red Hat's pthreads-w32. Some custom builds of MinGW64 even have POSIX threading set as the default instead of Win32 threading. That means better compatibility for C++ thread related code (since the GNU C++ library relies on POSIX threading for parts of its implementation). The MinGW project has always been more careful about licensing and making sure that the code it was using was properly licensed and legal for usage. The MinGW project did follow the example of the MinGW64 project in one key area. They switched from public domain to a MIT license for their runtime library and Win32 API. When they did so without clearly indicating that an exception could be made similar to the GNU gcc runtime license exception, I felt it was time to stop using that version of the MinGW compiler.

I'm currently working with gcc 4.9.2 compiled from source. I'm still using the older public domain APIs, but I've made several modifications for compatibility with the Win32 API (including some modifications that aren't available in the MinGW64 libraries). I have a minimal thread library that was custom written for portability. It's based on C11 thread support and includes POSIX functionality. The gnu compiler is built with POSIX threads as the default so C++ threading works as expected.

So far, I've had no reason to want to work with any other MinGW forks. The version I have does everything I need and supports all the programs I want to compile on Windows. My particular fork is continually evolving. I continue to add support for new Win32 API changes, Win32 API omissions, new C/C++ features as I need them. At some point, I hope to completely replace the runtime library with code that better supports internationalization (better UTF-8 support), C standard compatibility and other useful features.

If anyone else is finding limitations with the compilers maintained by the various MinGW and MinGW64 projects or other related forks based on these projects, I highly recommending building the GNU compiler from source on your own with the options you need most. If you're interested in discussing the GNU compiler further or want to know more about my modifications, you're welcome to use the CppDesign mailing list ( http://groups.yahoo.com/group/CppDesign ) as a forum for further discussion.