Introduction to the QOR

Part 1: Cake and other monsters. The non-technical back story of the QOR

Ten years ago I'd already been working in software for some time but was in a dead end job and not happy with either the way software was being written or my understanding of how it worked. I had a good degree and some years of experience but the control freak in me still didn't feel I had enough of a grip on what was really happening when I pushed the run button. In the spirit of inquisitive children and men in sheds throughout the ages I started taking software apart to find out how it really worked.

I'm a 'read the manual afterwards' kind of guy so when I take things apart in the physical world they tend to stay in pieces and are very seldom ever useful again. However the wonderful world of software is different. You can take software apart and still have the original operational copy. It's like having your cake and eating it as many times as you like only each time you eat it you understand and appreciate the cake more. That's if it's good cake of course.

I quickly found that 'your mileage may vary' when it comes to open source software quality should really have been expressed in light years. This is a non technical introduction but there's one thing that I learned very early on while I was still in that dead end job that's worth passing on: "Code is intended to be read by people. If we only intended it to be read by machines we would leave out all the white space and save ourselves hours of space bar bashing."

Right from the beginning of the process I experimented with the ideas and components that I found. Making my own versions of container classes and trying out different tools. The things that worked mostly got backed-up and the things that didn't mostly got lost in one hard drive failure or another. A few years of these experiments left me with a fairly large pile of reasonably useful looking code and a very much clearer understanding of a number of things.

Many if not most C++ software developers have a only a vague idea of what code actually goes into a program or where strcmp comes from, let alone what's actually in the C++ language and what's a nice to have add on the compiler vendor decided to throw in to help sell more units. I had been one of those software developers.

Many if not most C++ software developers have only a vague idea of why their code only runs only on Windows or only on Linux, let alone what it would take to make it do both. I had been one of those software developers.

Many if not most C++ software developers have never heard of Aspect Oriented Design. Some pay little more than lip service to Object Oriented Design and design itself is almost universally thought of as being most necessary on the largest of scales, least necessary at the smallest of scales and only really necessary to do properly at the scale just up from the one I'm working at. I had been one of those software developers.

That may seem like a lot of depressing self flagellation but the upside of having been one of those software developers is that I'm not anymore. That's not to say that I've reached some sort of coding nirvana merely that as the veil of ignorance began to lift I could see the potential to do things differently. I started to take my pile of software bits and pieces and put it back together again in a new way. There were numerous false starts, reworks, dead ends and distractions but like Doctor Frankenstein I kept assembling more and better pieces until the monster was beginning to look a lot like Boris Karloff.

This being all about learning from experience though I new I could neither abandon my creation nor unleash it fully formed on an unsuspecting world. I also new that the monster that was now emerging was going to be far too big and troublesome for me to handle on my own.

It's time then to enlist some help to finally bring it to life and to reveal it a little at time so as not get too badly pitch forked by the natives.

The QOR is growing! The QOR is coming! What is the QOR?

Part2: What is the QOR?

The Querysoft Open Runtime ( pronounced like core ) is an open architecture cross platform framework. It's open because it's open source and it's open because it's designed to be extended. Not just so that it can be extended but so that extending it is what its all about. Every QOR application is an extension of the QOR. Its architecture takes ideas from Aspect Oriented Design as well as Object Oriented Design and applies them to create a general purpose framework. It's a cross platform framework because it's designed to work across different compilers, different processors and different operating system. This is achieved by the use of aspect specific modules for compilers, architectures and operating systems which are interchangeable.

There are many other frameworks, many other cross platform projects, many other implementations of aspect functionality and many other languages some of which are supposed to give you Write-Once-Run-anywhere. The QOR is the only C++, cross platform, aspect oriented, open source, modular framework; until somebody writes another one. That means its also the best C++, cross platform, aspect oriented, open source, modular framework; until somebody writes a better one and believe me you'd have to be crazy to consider doing that.

The best thing about the QOR is that no-one should have to write a better one because its designed so they can fix the QOR instead and that should always be less work and more productive than creating another one from scratch. Not everyone will agree but then not everyone likes cake.

There can be no honest FAQ until people actually ask questions but here's a series of questions that you might ask and some brief matching answers.

Q. What's in the QOR?

The QOR design currently contains:

• CompilerQOR - The QOR compiler compatibility aspect
• ArchQOR - The QOR hardware architecture aspect
• CodeQOR - The QOR code services aspect
• CQOR - The QOR C library interface
• stdQOR - The QOR standard C++ library
• SystemQOR - The QOR operating system aspect
• UnitTestQOR - The QOR Unit testing aspect
• PosumQOR - The QOR Posix as classes library
• MonkiQOR - The QOR View library
• MammutQOR - The QOR Model library
• AppocritaQOR - The QOR Controller library
• BluefootQOR - The QOR Pipeline library

Along with additional libraries for specific OS, Compiler and Architecture support

These modules form an interdependent network of aspects and interfaces.

Q. Is the QOR finished?

No, that won't happen any time soon. The great advantage of an open ended project designed in part to extend the potential lifetime of software is that it can in principle go on forever. As of this writing the QOR contains over 250,000 lines of code in various states of correctness. The disadvantage of such a project is that with such a large scope it can go on forever without being finished.

Q. Can I buy it?

No, because it's free. You can have it as it gets put online but you can't pay for it or make anybody else pay for copies of it.

Q. Can I use it in a commercial project?

Yes. QOR code is not under a commercially restrictive GPL license so you can use it in your product and sell the product. You're still giving away the QOR part just charging for the rest. You don't have to supply your customers or anyone else with the QOR source code even if you modify it although it would be polite to do so.

Q. How is the QOR growing?

The QOR as a project is divided into Strata. These non chronological milestones specify what functionality a combination of components must supply to achieve them.

For example, for CompilerX support to be considered as at Strata-1 it's CompilerQOR component must be able to be used with any combination of other Strata-1 components to achieve the Strata-1 functionality. While CompilerX support might be at Strata-2 CompilerY support may still only be at Strata-1. This doesn't prevent either being used nor does it imply that CompilerY support is a lower or higher priority.

The Strata-1 specification is intentionally very simple:

The TwoForTea program must compile, link against only QOR libraries and basic compiler support code, run and return 42.

//Two for tea
int main()
{
    return 42;
}

Any 3rd party compiler support code should be open source, preferably with a QOR compatible, LGPL type, license. This ensures that every line of code that constitutes the final product is available for inspection. Decompilation is risk free and complete code transparency can be achieved.

Not all the QOR libraries are needed at Strata-1 and those that are are mostly very small. However a Strata-1 build can still contain a few thousand lines of code.

Nothing else is required to work for Strata-1, no floating point math, no exception handling, no RTTI and no library calls at all unless such things are required to build a working executable with the selected compiler on the selected OS and hardware

Strata-2 however precisely does require that any code that can be written without a library call should work. All the math support and other features that your compiler can build code for targeted at your hardware must be able to be added into main and produce correct results. Now that's much more difficult to write a test for but the specification itself is easy enough to understand. Anything that's tool supported valid code and doesn't call outside of itself must work.

Strata-3 adds the requirement that all Posix 2008 specified functions must be available and working with the selected combination of components... and so on.

Any given combination of components will meet the specification up to some Strata, often the maximum supported by the least able component.

Applications based on the QOR will be written to expect a Strata-n QOR. Any combination of QOR components that achieves Strata-n can then be used to support the same application providing it with immediately portability to a variety of hardware and operating system environments and the potential to transfer seamlessly to different tool sets for example for embedded usage.

Q. When is the QOR arriving?

In the way of these things the answer is both now and in the future. I'm not about to put 250,000 lines of code online all at once and expect anybody to dive in and just use it let alone contribute to it. Initially only Strata-1 compliant projects will be released which are mostly of interest to specialists in compiler compatibility, architecture support and system programming. These will be as stand alone as I can make them in order to support accompanying articles. However the QOR being what it is, a network of collaborating components, separating them entirely is not possible or desirable so there will be compromises and some building on previous work.

My intention is to present a series of articles on QOR components. Some will be very minimal indeed and others will probably go well beyond what's strictly needed to meet the Strata-1 specification. Along the way we'll solve a few problems perhaps open a few eyes and lay a foundation on which to build higher and better things. What happens after that will largely depend on the level of interest generated and my availability to do anything about it in between coding for food and eating to code.

I'll begin with CompilerQOR.

Q. What can I do to help?

You can join in with QOR development. If you think the whole idea is crazy but you like it you can help bring the QOR to life by contributing your expertise. If the QOR doesn't work with your compiler, on your hardware on your OS then there is at least one module missing. If it does then there is any and every kind of sub project you can think of available to work on within the QOR from assembly floating point routines to database access code. Everything has a place and everything that's already written will help you write more.

While it helps if your name is Igor it's not really necessary, especially if you have serious skills in non x86 assembly language, exception handling, or C++11 and don't expect to get anything more valuable than brownie points and acknowledgment for your work.

History

• Initial version - 03/02/2013.