One thing that is easily noticed is how many builds were never mentioned in R3-Alpha's makefiles.
As someone with an interest in emulators/simulators and things of that sort, the idea that a platform is "dead" doesn't necessarily mean you shouldn't tinker with it. A lot of people are curious about getting software running on legacy systems, it's an interesting stunt. One that still brings in some interest...even sometimes, money (?)
I thought given the Amiga's history--for instance--it would be a particularly interesting thing to run modern Rebol on. That never came together, but we did get it on Haiku. And for the lulz, I built it for Syllable as well.
The main reason I think it's still worthwhile to hold the line and stay building on older platforms is really about trying to stay true to the idea that it's a language that tries to reign in total footprint. That means measuring not just the size of the interpreter, but the size of the toolchain used to build that interpreter. One advantage of building on old platforms is you don't have to invent a fake small system to help prove your point of footprint, you use a system that people have in the past used for real work.
But, how many of those do we need? Did R3-Alpha basically cull all the uninteresting systems?
Basically I'm wondering if there are feelings anyone has about this. Is FreeBSD/OpenBSD pointless? How about QNX? Should the makefiles just drop mention of some things, and they not be taken into account going forward? Does anyone see a platform they are interested in enough to try tinkering to see if it works, and then outreach to that community to see if they care?
There has to be a point to all of this .. no point at all building for systems ( which means also providing a place to store the builds ) if there are no users. Then it becomes sort of a vanity project.
There's some excess verbiage I added to %host-main.c to explain that it's possible to tell the windows.h file what your minimum targeted version of windows is. In theory, that should give you errors at compile time if you use an API that is "too new":
//
// On Windows it is required to include <windows.h>, and defining the
// _WIN32_WINNT constant to 0x0501 specifies the minimum targeted version
// is Windows XP. This is the earliest platform API still supported by
// Visual Studio 2015:
//
// https://msdn.microsoft.com/en-us/library/6sehtctf.aspx
//
// R3-Alpha used 0x0500, indicating a minimum target of Windows 2000. No
// Windows-XP-specific dependencies were added in Ren-C, but the version
// was bumped to avoid compilation errors in the common case.
//
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#include <windows.h>
I'm moving it here for archival records. But I think I can skip saying all that and just #include <windows.h> like literally every other project does.
First, I'm skeptical Microsoft is careful about making sure a modern MSVC builds EXEs that run on old systems. The only way you'll know when you compile with something like Visual Studio 2017 if your executable will run on Windows XP is to try it. There's a lot of reasons it might not work...and if someone is going to want to keep things running there it's going to be an effort to make sure it is.
Plus there aren't any Windows includes in the interpreter core. And with the API you can now make a bare-bones standard I/O console on any system. There are enough controls for making sure the language itself isn't getting out-of-hand dependent on modern Windows APIs. If you need to compile on Windows 95 or whatever you'll be able to.
UPDATE: Okay, I keep the define but I link here for reference of what it's about...and the relevant conversation about how much work actually needs to be done about this.
I use Windows and Debian. I will try a build on OpenBSD, provided I'm migrating on this system instead of Debian.
OpenBSD and Debian also support a lot of odd architectures. The reason is a way to identify vicious bugs that pops only because you write a system for a single architecture, so you don't code for a special case. It prevents the "limit cases".
It's a work in progress. Some professional obligations and the delivery of another free software of which I am responsible oblige me to postpone for February, being realistic.
