Will the QOR work on Android? Well clearly not at the moment it won't as it's barely struggling into life on Linux but in the long term the answer should be yes. There are two possible routes to take for project Marvin. The first is a monolithic QOR as a native behaviour which envisages the end user application being written in Java and using the QOR through JNI. The second is to provide the QOR as one or more native libraries which depend only on the Kernel as we do on other platforms envisaging applications being written as native executables in C++.
The first way is definitely more Android by the second means code will be directly portable from other platforms.
For the QOR Write Once Run Anywhere trumps such minor concerns as How hard is that? or Can we even do that? therefore option 2 must definitely be available. How much extra effort will it be to make option 1 available as well?
Who cares, it'll be fun!
The QOR now has an Ohloh page here https://www.ohloh.net/p/QOR
I have to admit that most of the motivation for filling in the form was to see how much they reckon it would cost to develop commercially and how much effort it represents. Albeit that their estimate was always going to be wildly inaccurate, 32 years still made me laugh and £1.7 million made me smile.
On more important matters, SanOS development is paused just at the moment while I go through a round of tooling upgrades. Strata-1 support for Visual Studio 2013 will follow shortly.... read more
The SanOS bootstrap working draft is completed. Binaries for the monolithic runtime and TeaForTwo test application can be built and installed although I had to go round the houses to do the install via a virtual floppy as my SanOS/VMWare networking isn't exactly working.
It doesn't get very far as yet as it has no way to allocate memory, doesn't in fact even talk to the kernel. That will be fixed shortly by the SanQAPI kernel abstraction layer. That too is coded but too rough to commit at present.
The design phase of the higher level SanQL library is looking good for giving us lots of shared semantics for the SystemQOR generic interface. SanOS being an x86 OS has a quite similar device tree in many ways to Windows so a common Device Manager interface might be an early target.
There are rumours of Curses availability for SanOS which if they prove true and I can get the source I will certainly want to make use of.
Finally thanks to some prompting from Raffa (thank you my friend) I've committed the Strata-1 source.
It did prove possible in the end to do without the ArchQOR JIT assembler at Strata-1 on Windows and this makes the project significantly smaller ~ 1000 files.
Sadly the latest Code Blocks seems to be broken or at least my installation of it is so I haven't been able to follow my usual migration path from MSVC builds to MinGW-GCC builds of the same source and then Linux-GCC builds at the same or similar GCC version. This will have to wait for now so I've only put the Windows Visual Studio 2010 Express Build projects online.
That build is working in full Debug and optimised Release flavours with UNICODE and Multi-byte configurations.
There are in fact two build projects, a monolithic build which builds the runtime as a single DLL and a modular build which builds the runtime as a collection of DLLs.
The idea is that the monolithic approach will be suitable for embedded targets, e.g. SanOS while the modular approach will be needed for desktop environments e.g. Windows where the OS support modules alone will be multi-megabyte.... read more
It's way too long since I put anything online but QOR development has not slowed let alone ceased. Recent focus has been on Strata-3 OS support and the foundations for the generic components of the framework. A whole menagerie of QOR libraries have started to develop covering MVC and platform support.
A pile of bug fixes and improvements have also gone in to lower level libraries, even 10+ year old stuff in CodeQOR.
The next step will be to get Strata-1 development online and properly hosted here.
I recently did a live demo of the CodeQOR AOP facilities in the office which went down well. This was done from a November 2013 QOR1 snapshot so it really should be ready to live. Now to fix those last few build dependency issues...
It looks like the inital ArchQOR article is going to have to contain the full x86 JIT Assembler not only to make a suitable article but because even at Strata-1 we just can't do without it. This is going to delay things somewhat but will produce a better outcome. Meanwhile persuing the principle that every compatability component should prove its worth at an early stage by supporting 2 or more targets, research into ARM assembler is continuing. For the article this will almost certainly be fudged and the 2 targets will be x86 and x64 unless things go a lot better in the near future.
The QOR intro article and one for CompilerQOR are submitted for review and will hopefully go live sometime next week. A little initial interest will probably be followed by 'I can't do much with that' which is fair enough, it's a small static version of one part of a larger whole but we all have to start somewhere.
ArchQOR will be the next step at least in cut down form.
The source code for the initial Code Project article on CompilerQOR is up at last. Well as they say you've got to get up to get down.
Just tickling the Source Forge stuff into life today and working through the necessary admin. Initially SF will just act as backing and download source for some articles on Code Project and associated code. Eventually full Strata-1 development will be hosted here.