This page will include the following, as I get around to them ; Contents.

(a) Introduction.
(b) Unique features.
(c) Implementation so far.
(d) Possible implementation methods.
(e) Format.
(g) How it works.
(h) What it does.
(i) What it can do. (enough of the technical stuff I think)

(a) Introduction.
The basic object, or what would form the `Kernel' (even though the system is essentially Kernelless) is an assembler, or cross-assembler. What it does is to read in a script file (called the VMS or Virtual Machine Specification) which contains information about the both the current computer, and the `ideal' or `simple' computer, and converts, quickly, from one to the other, effectively compiling, or assembling the program (there are no programs really though - everthing is an object, thus there is no `huge 1 meg programs' to load, compile and run, instead everything is made up of objects which communicate with each other).

Programs need not necessarily be written in assembler. With a better basic VMS assembler, programs may be written in Native C, and compiled at run time (everything is essentially compiled at run-time, but there are some additions to this rule).

The format of the assembler programs is also defined in the VMS (to a fashion), so different VMS' can be used simultaneously, with the assembler finding the one which matches the format of the file its trying to run. C and pascal programs may be run from the command line. Thus, instead of writing compilers , you would simply write a VMS for your language, and design an IDE (or not if there is already a good one out there) for the programmer. Compiling and running the program is as simple as sending it to the assembler, and perhaps giving reference to the appropriate VMS.

The VMS language/script file is an integral part of the system, and is thus itself Object Oriented. If you want to add a few of your own assembly instructions to the current VMS, you simple overlay another VMS with the additions. You instantly gain the features of the parent VMS. This is however covered in Part C of the overall design page (on VMS's) so I won't go into it more here.

(b) Unique features.

The most unique thing about the assembler (or perhaps just one of the unique things) is that it is Object Oriented to the core. When programs are assembled, they are left in an Object Oriented form, using Virtual Method Tables, and look ups for everthing. Even the Process Control Blocks should be Object Oriented. The good thing about this, though, is that, because its only compiled at run time, we can do a few tricks to speed up execution. For example, if an objects methods are simple/small enough, we can have the assembler embed them in the code which uses them. No calls required - programs can Grow, or shrink, depending on how fast the user wants the system, or each individual program, to run.

Code can (and should) also be stored in macro form - thus removing redundent code and data (data perhaps could be stored in macro form as well - examples are ; cosine/sine look up tables for graphics programmers - let the OS produce them at run time), compressing the stored code, and making it re-useable.

Code can also be stored in snippets - thus a method can have several embedded methods, which may be reused by other programs. A simple examples is a setpixel routine. ; First there is the address calculation. Then the pixel colour is put to that address. We may even include an initial step of loading a pointer to the screen.

Thus each bit of this code may be given a name, and another object/method may use any or all of the snippets of code. The above example might not be too interesting, but in effect, if an object uses .ZIP style compression, any other program may simply pull that out for its own use, including the ability to pull out only parts of the compression method, which are appropriate to its case. And none of this is in the eventual stored program - which has two main advantages. Firstly it will probably save space in the eventual program. Secondly, if a better/faster method of ZIP is installed, the program will either be unaffected, but most probably run faster, or use better compression.

I'm also thinking at this very moment of the idea of there being data in and data out for each program, and thus you could get a compressed program of 300K, but because your computer has better compressor installed, once that program is run, it could shrink itself down to 250K. Something like that - good idea though.

(c) Implementation so far.

This is unfortunately not how this has been actually implemented so far, but instead how I have decided/looked at implementing it so far. There are a lot of ideas in there, they could easily be lost or ruined by badly designed implementation, so I want to look at as many possible angles before going to the keyboard.