BlaatBot2025

BlaatBot2025 is the fifth generation on BlaatBots.

It is currently under development. It is written in C++ (--std=gnu++26)

In its current phase, the IRC protocol is being implemented. The IRC implementation will include IRCv3 and Modern IRC features, as well as IRCX features.

Currently the project is a single binary, but the planning includes making it modular akin BlaatBot2009. Initially there will be another IRC bot, but using the IRC implementation for an IRC client is considered.

Compiler Support

BlaatBot2025 is developed to compile with the gcc compiler and tested to build with clang as well. Being developed on ArchLinux, the compiler version will get updated during the development. At the time of writing, the g++ version is 14.2.1 and the clang++ version is 19.1.7.

Operating System Support

BlaatBot2025 is developed on ArchLinux, and primary testing happens on Arch. Thus the primary target OS is GNU/Linux.

However, the code is expected to be able to run on any operatering system that implements POSIX APIs. When the project matures, it is planned to test on OpenBSD, NetBSD, DragonFlyBSD as well as HaikuOS.

It is also planned to perform testing on musl/Linux, thus a Linux kernel with a musl C library in stead of the GNU C library. A Linux distro using the musl C library is for example Alpine Linux.

As for non-POSIX operating systems, Microsoft Windows (and ReactOS) might be supported, but is no priority.

musl/Linux support is investigating what the impact of the fact musl does not implement unloading libraries (https://wiki.musl-libc.org/functional-differences-from-glibc.html#Unloading-libraries). One thing we know, it won't call destructors. We can detect that and call them manually, so big deal. But when loading an updated version of the same library, will the remains of the previous version in memory cause issues. Will it re-use the previous symbols? Eg. when the same symbol name was used, but a struct got additional members.

For the BSD family, it's mostly that their socket structs include a length field. Just some #ifdef in the TCPConnection class. Trivial, no problems expected here. Perhaps an issue could be older compiler versions. I'm not really using C++26 features so switching back to an older version should not be an issue.

For Windows support, the main difference is expected to be library loading, and some trivial things such as initialising WinSock. Some features only interesting during debugging, such as setting a thread name, require Windows 10 version 1607 or later. Removing that feature should drop the minimum required version. The challenge for Windows, how low can we go? What's the earliest version we can support?

Planned Features

The initial planned feature set includes: IRC bot functionality, with loadable bot modules. The commands the bot supports will be loaded as a library.

For these libraries, it is planned they'll include two API. A C++ API and a C API. For the C++ API/ABI it will have to turn out if crossing library borders causes issues. It will have to be sure they're linked to the exact same version of the classes. Might have to implement some checking there.

For the C API, when calling from/to the library, some wrapper code will have to run, but otherwise, less strict checking is required when crossing library borders. the C API will allow for language bindings to other languages. It is planned to at least include Pascal bindings, as this was the language BlaatBot2005 was written in.

Language Bindings

The support of language bindings will be a research project. The last required is as follows: Load a library written in another language from C++, call into that library and register callbacks, have the library call back into the C++ code.

Calling into another language is one thing, but also being able to call back makes it not all languages can be supported easily (there may be a workaround running in a separate process and communicating over sockets, but that ain't the goal here)

The C++ code will offer a C and a C++ API/ABI.

It should be rather easy to get D language bindings, as D can directly bind to C++, and D is also supported by the GNU Compiler Collection. So, language bindings to D are expected to be trivial. https://dlang.org/spec/cpp_interface.html

Another language supported by the GNU Compiler Collection is go. As my compiler already supports it, I might give it a try. https://go.dev/doc/install/gccgo#C_Interoperability

Since Rust is getting popular, I might have a look at that language as well. https://docs.rust-embedded.org/book/interoperability/rust-with-c.html

So far, these languages produce libraries native to the operating system they're built for. Next we consider some languages that do not compile to native code:

Take for example Python, as it is a scripting language, once cannot simply create an .so file and load that. It seems the solution Python gives to this is called Embedding. See https://docs.python.org/3/extending/embedding.html

For JavaScript, or formally, ECMAScript, it is also possible to embed an engine https://duktape.org/guide.html#introduction

As for Java, it compiled to byte code, runs in a VM. However, it offers an interoperability layer called JNI. It seems to support calling into, as well as being called, across language barriers. See https://nachtimwald.com/2017/06/17/calling-java-from-c/

As for C#, when running on Windows, calling managed code from unmanaged code can be done easily. https://www.codeproject.com/Tips/695387/Calling-Csharp-NET-methods-from-unmanaged-C-Cplusp However, it won't be trivial to do the same on other operating systems.

Other languages have been proposed include Lua and AngelScript.