Which operating systems to support?

[jaykrell]

Lots of things we could consider cleaning up.

Which operating systems to support?
Many of these have been obsolete for over 10 years (Irix Ultrix OSF).
Even supported systems like HP-UX Solaris seems clearly on the way out.

1 AIX
2 Darwin
3 FreeBSD
4 HP-UX
5 Irix
6 Linux
7 MS-DOS (djgpp); never been supported
8 NetBSD
9 NT
10 OpenBSD
11 OSF
12 Solaris
13 Ultrix ("DS1000")
14 VMS; never been supported?

Usermode threads? Or require pthreads or Win32?

Some of these are trivial or there is nothing specific.

But for example, netdb functions in some systems, we put a lock around, and many systems do not need it, some do.
I consider a bug that those systems do not use thread locals.

[ghost]

It would be great to get some clarification on these.

1. NT is obviously important to most current users

For my personal use,

1. Darwin
2. Linux

And I would like to support the BSDs. None of the work for me right now, but I'm willing to put in the effort to get them up and running.

1. FreeBSD
2. NetBSD
3. OpenBSD

But most of these I haven't even touched in over 20 years. I have no idea if they currently work and no motivation to get them working if they don't. I would vote to archive whatever support we have for them, and prune them going forward. ("Archive" to me means tag the most recent working version, and maybe make a tarball. They can live on in git forever, but they don't need to clutter the current efforts.)

1. AIX
2. HP-UX
3. Irix
4. MS-DOS
5. OSF
6. Solaris
7. Ultrix
8. VMS

My two-cents.

I do realize there was a directive, back when CM3 was first released as open-source, to never remove anything from the source tree. But that was before source-code control became commonplace. Even if something is broken and dead-weight (right now), it may be of interest to someone later, and we can easily preserve all that history.

[jaykrell]

I am annoying ambivalent and verbose, sorry.

AIX, HP-UX, Solaris, VMS are all under somewhat active maintenance and support.
AIX and VMS seemingly indefinitely, HP-UX and Solaris less so.
Ultrix, Irix, OSF are long dead.
MS-DOS is funny because it'd be DJGPP which is somewhat actively maintained. It has never worked though.
OSF and Solari I ran this year. They work.
VMS probably has never been run, but probably works or is close to working.
I like having the alternate C compilers to test against.

For the most part the support is all zero or very little.
To a large extent, I would like autconf to do the work, but we don't use it. e.g. "large files" and "time64".

Problem is arguably that of CI.
So they worked this year for me. Probably nobody else, and nobody will test anything not even me.

I was not aware of that policy.
I am very ambivalent about relying on Git.
Both of these opinions are widespread. Because finding deleted stuff is more difficult in history than head.
But people don't like clutter in head either.

Sticking point might later become availability of C++ compilers, C++11, etc.
For example if we use [[thread]]. But so far this doesn't matter.

[ghost]

I'm surprised to hear that so many of these work, but that's great news.

I do agree that CI is a real problem. The "cloud" is very uniform, so it's hard to test on anything that isn't currently mainstream. Right now Github gives us pretty good access to Linux, MacOS, and Windows, and yesterday I started setting up Vagrant environments that I can use for anything intel-based and freely-available, but that doesn't go a long way on this list.

I hope this isn't getting too far off-topic, but I've been wanting to ask you about autoconf. It seems like putting the bootstrap under autoconf would be reasonably straightforward, but am I to understand that what you'd really like to see is the entire system under autoconf? (I use that term in the generic.) If so, I'm trying to understand why. I don't see a fundamental problem with building the system by way of bootstrap--obviously, it could be easier--but I have seen that there's a lot of system info hardcoded into three different build systems. Is that the problem you're trying to solve? Or is there something else that I'm missing?

[ghost]

Oh, that "directive" I mentioned. I had found that here https://modula3.elegosoft.com/cm3/cm3-cm-rules.html while trying to figure out how to prepare my code to contribute to the project. I may have over-stated it, but the direct quotes are:

• Do not remove functionality unless absolutely unavoidable.
• Never remove existing versions from the repository.
• Do not move files in the repository.