This page is where I will collect some links and files relating to projects I've been a part of. Right now it's just software. I seem to be better at software than I am at most things.
This is all very rough around the edges, but there is a prerelease version of the MettaScript Editor and MettaScript Core for Java available here along with some preliminary documentation for ZVM (another component of the SDK, which is not available to the public yet).
I'm still in the process of preparing a proper release and documentation for my current project.
I figure I'm pretty good at programming, so I might as well build a triple-layer algebra-driven 64-bit multi-core operating system just to show off.
Okay, maybe I have slightly more sinister ambitions than just showing off, but it's not good for much else at this point. Until it becomes useful for it's true purpose, the meaning of the name will be a secret.
It's all very rough around the edges, but so far, the following things/technologies/ideas are supported:
[NOTE: These screenshots are of TSOS/HAL being edited and run in emulators under Ubuntu, so please don't confuse the content on the edges of the screen for my OS - mine's just the sketchy crap running in the middle, the pretty stuff is all Ubuntu.]
This is just a simple graphics test (it's running under QEMU in the yellow window), with serial output shown (in the purple window) and the demonstration "main" program (L2_Executive) being edited in the background...
(Graphics Test under QEMU with Serial Logging.)
This one is a slightly more recent graphical demo, featuring some (not-yet-interactive) GUI widgets...
(Early version of the GUI under QEMU.)
Here's a dump of (part of) the resource tree...
(Partial Resource Tree Dump under QEMU.)
Finally, the GUI is coming along...
(The HAL/L2 GUI running on HAL/L1 in VirtualBox, featuring the "HundScheisse" demo.)
And the GUI also runs natively on Linux...
(The HAL/L2 GUI running on Ubuntu using SDL2, featuring the "HundScheisse" demo.)
The kernel (Hardware Abstraction Layer/Level 1) is kind-of sketchy but it boots to 64-bit mode, initialises memory and CPU cores and launches a Linux-compatible (or, alternatively, Menuet64-compatible) application.
Mostly, what's missing compared to the Linux kernel are the wide variety of system calls and infrastructure for threads/processes and drivers - it can run a Linux-compatible "Hello, world!" program, but not one that relies on a full GNU C runtime, and the output isn't really handled in the same way.
While L1 is limited by design (as well as by time constraints), it's shortcomings make it easier to build high-level applications on top, since the majority of device drivers and software compatibility features can now be implemented directly within those applications instead of relying on weird kernel abstractions for everything.
So, L1 is somewhere between an exokernel, a hypervisor and a traditional kernel. It provides just enough abstraction to build powerful applications on top, but not enough abstraction to get in the developer's way.
Unlike Linux and Windows, applications running directly atop L1 have full control over the machine - they can even run in kernel mode if they want. However, unlike with traditional boot loaders and exokernels, the application running on top can be a normal Linux application - it can detect at startup whether it's running on L1 or Linux (or FreeBSD or Windows), and behave appropriately in either case.
The middleware (Hardware Abstraction Layer/Level 2) is the meatiest layer. What sets it apart from your average "toy OS" userland is that it's designed to work natively across multiple ABIs (i.e. operating system architectures) without recompiling. This makes L2 an ideal basis for cross-platform applications, which in turn makes L1 an ideal host environment for newly-developed applications.
The magic behind the scenes here is very simple: Most operating systems already support a variant of the same ABI anyway (known as "System V" or "Linux ELF"), but they differ in functionality and system call semantics. Given that the same executables can already be loaded and started on practically all operating systems (anything not made by Apple), and given that most systems are able to report environment variables and basic system information in very similar ways, it's absolutely trivial to detect the specifics at startup and behave accordingly.
Right now, HAL/L2 only supports L1 and Linux hosts, but the Linux support should be usable on FreeBSD and Windows 10 through their respective Linux emulation layers. Further developments may produce a layer more suitable to running in these environments. (macOS will probably never be supported in a binary-compatible way, but you could still easily recompile an L2-based application for it.)
HAL/L2 includes most of the functionality of the system: Device drivers, high-level languages, graphics rendering and so on. This layer is written primarily in Pascal (which is typically ideal for this kind of stuff), with legacy C code used internally (to avoid reinventing too many wheels) and a high-level system API exposed to Smalltalk programs.
Applications developed upon HAL/L2 are generally expected to be built into the platform - in other words, you fork the platform and turn it into a specific app, then if you want to deploy multiple apps together you merge the codebases. Applications can also be loaded at runtime and hosted on top of the platform (i.e. as extensions to whichever main app is actually deployed), but support for this is limited (i.e. no secure sandboxes are provided).
Without giving too much away, the high-level API and shell (Hardware Abstraction Layer/Level 3) are designed around conventional mathematical notation (currently named MettaScript). In other words, the system is programmed using simple algebra, not with a programming language/scripting language/command language. (In theory, MettaScript isn't really a programming language at all, but in practice it's equally capable.)
Although this layer is still very incomplete (and not yet integrated with the others), it's probably the most mature of the three. It already has an editor, compiler and runtime that support all of the completely-necessary features for basic math and programming work.
The syntax is fairly mature, and it comes close to record-level expressiveness (without going fully esoteric). The syntax sticks to tried-and-tested mathematical notation wherever possible (in particular, every operation is a binary operation, and all values are functions - there should be no element of the language that a school teacher hasn't already explained to you).
(MettaScript Editor running on Ubuntu.)
The major missing feature of the language right now is support for floating point math, something I'm not a big fan of myself, but that's clearly necessary for high-performance gaming and related application domains. The language is otherwise almost feature-complete, although the editor and compiler are both a bit buggy and the current runtime environments are limited (and slow). The only fully-working runtime at the moment uses a custom bytecode format and runs on Java, and it's only an implementation of the core language (without support for I/O, text processing, etc.).
I have a lot of what you might call "abandoned projects" or even "dismal failures", but I call them "successful experiments with minimal regard for scientific method".
I might fix and upload some more old stuff eventually... Maybe even my "proof-of-concept SkyNet implementation", but only if you're really unlucky. (Have patience. The apocalypse will come when it's ready.)
I'm listed as a casual contributor to Java-GNOME, having sent in a patch extending the Cairo and GDK support to allow per-pixel translucency in top-level windows. (AFAIK, this can be done in a cross-platform way with Swing now, but at the time that was very flaky.)
I also helped correct/enhance a number of (English) translations for some of the desktop applications for the Deepin GNU/Linux distribution. (Their desktop stack is very neat.)