BasisDoctrina Cross Platform Library for Desktops and Embedded Systems Development

**currently requires C++17 **

LICENSE.TXT contains a copy of Eclipse Public License 2.0 plus our restriction banning this library from being included in a library one charges money for. The days of companies like Qtc selling Open Source code as a commercial library end here.

Introduction

BasisDoctrina is a brand new UTF-8 based C++ cross platform library project for desktops and embedded systems. As such it is taking its first baby steps now so those wishing to help build a proper foundation for a next generation class library should hop on board.

When we get to creating the widget and other graphics classes we will be immediate mode. The one-ugly-bloated-switch-to-run-it-all application frameworks have really been used for far too long. They were created on GUI DOS (Windows 3.x) and OS/2 when single core computers ruled the land. Requiring a main event loop that runs in the primary thread through which almost everything executes makes an application operate mostly single threaded. When you create new threads, unless you force it to another core, it will run on the same core as your main event loop leaving all other cores basically idle.

Project focus is on Desktop computers and embedded systems, mostly
embedded systems that will be part of medical devices. Project does not care nor will it ever care about phones. Initial embedded development will be focused on NXP derived ArmV8 mostly because that is what we have to work with.

Ideally this library will be architected much like DEC ACMS (Application Control Management System). There will be a Benevolent Overlord on one core and vassals (or task server) spread across other core. Most likely publish-subscribe or some other, possibly persistent, message queue. Preferably these will be child processes, not threads.

Project Motto:

** Don't Insist on Building Your Own **

Reason for Existence

In the days of GUI DOS, you had no choice but to roll your own. The problem with that is you get trapped.

A manager screamed at the systems analyst, "You guys tell me you're programming gods so how can it take you six months to deliver the new system when God created the universe in seven days?"

Systems analyst thought for a moment and responded "God didn't have an installed base."

That's how we ended up still using application architectures designed in the early 1990s today, when they cannot fully use the computer they are running on. Intel started shipping Core 2 Duo machines in 2006. Today you can purchase used computers with 24-core for under $800 U.S. There are 12-core ARMv8 modules on the market with 4-core and 6-core being quite common yet most application frameworks limit you to a single core.

It's time to stop messing with Docker and other containers just to
nurse along what is a single core architecture. Yes, you can keep
throwing hardware at it, but in the battery powered medical device
world you shouldn't have to.

Philosophy

C++11 gave us a regular expression library which is well tested by now.Why have more than a wrapper around it? The same is true for map and list containers. IBM dumped a ton of resources into Xerces so there would be a free, industry standard library. We could also choose to wrap libxml++. Glib::ustring exists everywhere so why not wrap it? The library is well maintained and proven.

Why wrap? Application cleanup. One of the things the legacy application frameworks brought to C++ was some form of garbage collection. At the end, all of the objects would get cleaned up. Sometimes things would even get cleaned up during execution.

Smart pointers aren't so smart.
https://www.logikalsolutions.com/wordpress/information-technology/smart-pointers/

As soon as you need to pass the pointer to a system service call or third party library, your program has no real method of determining when it is safe to delete. If your smart pointer decides to delete the item and the third party later reaches for it you will have inexplicable crashes that could happen hours or weeks after deletion. Many of our supporting libraries were written in C, not C++.

System Requirements

We will not use C++20 or any C++ compiler standard that forces twos complement binary integers. Unisys mainframes as well as many devices in the embedded systems world use ones compliment and we have to communicate with them. Given our use of C++17 it is theoretically possible the project could support Windows XP if you used a version of GLFW from early 2025. According to check-in comments GLFW only dropped support for Windows XP during 2025.

Current development is currently being done on MX Linux.

Eratta

Files in the 3rdParty directory tree may contain source with MIT, BSD, or Public Domain license, but nothing stricter.

This project was heavily influenced by NanoGUI and NanoGUI-SDL. So much so we include their license with this distribution while using little of their code.

https://github.com/mitsuba-renderer/nanogui
https://github.com/dalerank/nanogui-sdl

You can visit the roadmap at
https://basisdoctrina.com/RoadMap.html

Project blog.
https://sourceforge.net/p/basisdoctrina/blog/

Please use the Open Source tool Apostrophe to edit all .md files for this project.