C-Kermit 10.0 Beta.11 for Unix and VMS is released, dated 2024/08/08. At the same time C-Kermit for Windows Beta.06 is released too, based on C-Kermit 10.0 Beta.11. There is nothing earth-shaking in Beta.11 but it took me a long time because last December I came down with Long Covid and it is NOT brain-friendly! And still, 9 months later, it's not safe for me to try to write or fix code.

The changes in C-Kermit 10.0 Beta 11 are detailed here:

and you can download it from that page where it says DOWNLOAD LATEST BUILD just under where it says "Best viewed in a wide window".

The changes in C-Kermit for Windows are listed here:

The Windows version from David Goodwin in New Zealand is now available for virtually any version of Windows on any platform that Windows ever ran on, and ditto for IBM OS/2. By popular demand, beginning with the *next* Beta test, its name will be changed back to the original one: Kermit 95 (K95 for short). Calling it C-Kermit for Windows was too confusing.. You can download the new Beta from either of these sites: Before C-Kermit 10.0 (and therefore also K95 3.0) can be released, some issues need to be addressed. I wish I could address them myself but programming is still too confusing for me. I hope the fog will clear soon, but can't count on it. So VOLUNTEER PROGRAMMERS ARE NEEDED.

C-Kermit's functionality is fine. There are very few bugs that still need fixing and very few missing features that are needed. The barrier now is the changing external landscape: the Clang compiler, the new APIs in OpenSSL 3.0, and the chaotic and unmonitored proliferation of quirky Linux varieties.

1. OpenSSL APIs... Somebody with OpenSSL expertise needs to change the API calls to now-"deprecated" functions into #ifdef .. #else .. #endif code that works for both old and new OpenSSL APIs. Here are the warning messages:
   https://www.kermitproject.org/OracleLinuxServer.txt
2. The Clang compiler... is not-so-gradually assassinating the installed base of software written in C over the past half century. Each new Clang release diagnoses more and more common C programming idioms (as practiced by the very creators of the language) as bad practice to be warned about. And then later turns the warnings into fatal errors. Meanwhile more and more OS's are adopting Clang as the favored or even only C compiler, most disappointingly the BSDs. Most of Clang's complaints about C-Kermit code fall into these three categories:
   1. Clang hates anything that is "deprecated", such as OpenSSL version 1 APIs that were replaced by new ones in OpenSSL 3.0, but with the old ones left in place so existing software could still work without having to be rewritten. Most compilers were unperturbed with the arrangement, but not Clang, which for a time screamed bloody murder when programs used the original APIs, and now (e.g. in Clang 16) invoking a "deprecated" API is fatal error. If OpenBSD wants to change some of its APIs, that's their privilege, but they kept the old ones available for a reason. Where does Clang come off refusing to compile programs that use these APIs? Especially when you consider that some software performs functions vital to society.

   2. while (*s++;) — This is a classic idiom of the C language, extolled by its creators (Kernighan and Ritchie), now on the chopping block.

   3. Requiring parentheses around elements of arithmetic expressions. The creators of C understood the precedence of arithmetic operators and programmers did too, everybody learns this in school.

   4. Similarly for expressions like 'if (p = getenv("SSL_CIPHER)) {...}'. This has always meant "do the assignment and then evaluate the result", not "oh my goodness, did you really mean '=='?"

   5. Braces are now required around the IF and ELSE parts even when they have only one statement, e.g.:
      if (!askmore()) return(0); else n = 0;
      Braces are not necessary for an IF or ELSE part that has a single statement. This is a FEATURE of C that C programmers have always known.
   To get an idea of the scope of the problems in this category, look at the C-Kermit 10.0 Beta.8 compilation log on OpenBSD 7.5 with Clang 16.0.6:
   https://www.kermitproject.org/OpenBSD75.txt
3. Chaotic Linux proliferation... As Unix (and especially Linux) variants proliferate, the packagers seem to be shuffling /usr/include header files around at random, or renaming them, or moving prototypes from one header file to another, or maybe even losing the prototypes. With increasing frequency C-Kermit compilations don't pick up declarations for important system functions like utimes(), timeval(), wait(), tgetent(), wgetstr(), tgoto(), ioctl(), etc; they have their prototypes in some header file that the Kermit makefile doesn't know about. This seems to be another new fatal error in recent Clang releases. Here are some examples of this trend from OpenBSD 7.5:
   https://www.kermitproject.org/OpenBSD75.txt

Somebody with a steady hand and clear head needs to rewrite all these statements to "comply" with Clang. I'm pretty sure that adding more braces and parentheses won't cause trouble with older (or even ancient) C compilers, but only so long as they don't interfere with the original purpose of the code.