One thing is, should the interpreter just be an execution engine or should the kernel be associated with it so it may do things. I would suppose that it should just be an execution engine for the most part.


I believe the recording file should likely be in ASCII rather than binary, this way it is easier to look at for example. It could also be manually adjusted at the risk of causing desynchronization.


However, ASCII would make it less dense.


Before I go into the rerecording interpreter, I should instead write the standard interpreter first. The standard interpreter would be much faster to begin with anyway. However, once it is written I can write and implement the entire class library which will take some time. However, I have a base layout used for the rerecording interpreter.


Thinking about the UI code, I believe I will simplify it. Instead of having native widgets and such, I will just draw and handle events in a framebuffer or text console for example. The basic UI drawer will be very simple, but there could be the potential for custom UI drawers and such. So displays would be created, but there would then just be a plain framebuffer with my own drawing code. Then if an interface supports it, it can take all of the stuff within the framebuffer and provide an overlay drawing which makes it appear more native for example. So the drawers will be basically be just: simple, console, and native. So displays as before would be used and such. Widgets could be added to displays and displays could be made displayable on the screen also. The only issue would be menus and such on Mac OS and Mac OS X, however that case could be handled. Thinking about it however, menus would be purely handled by the native interface (unless it does not support menus). If menus are not supported and menus are used then a menu bar would appear at the top of the display.


So the native feel would only be created by a customized drawer or interface over the widgets. I would then have a consistent user interface across platforms.


This display interface may have to be exposed either via IPC or via __squirreljme. Having it under IPC would be cleaner for example. Due to the various differences in screen size across devices, I will need to potentially use a floating point based pixel layout. Likely just float however. The units I suppose would be either cm or mm. A display would be requested with a given amount in cm, so I suppose cm would be the most consistent when it comes to widget placement. When it comes to the deterministic interpreter, what it displayed on the screen must be deterministic. So this means that the UI manager would have to be a process which is interpreted also. When it comes to the deterministic interpreter, the idea is that system calls are recorded in the stream and their values are returned. So really the UI part can be somewhat native. However, separation would best be done. The launcher would have to run as an interpreted process. However, actual display surfaces which provide pixel level access could be created and exposed over __squirreljme. So instead, displays are actual drivers which may expose terminals or graphical displays. So instead of just IPC, drivers could be polled by any program running, then depending on their permissions they could interact with the driver. I suppose for a common sharing, the IPC and driver set could be merged together in a way. So an IPC socket would be created to a driver which would be provided by the kernel, in this case it would create a video display and use float cm to measure everything. Anything sent over the IPC in the standard interpreter would be passed as is. Under the rerecording interpreter the messages sent will be sent as is, but the received messages would be as they were recorded previously. So the kernel driver would act upon the client IPC but the client processes would completely just ignore anything that was sent back.


With no potential for pixels amounts and only cm amounts to be transferred, this means rerecord playbacks will generally appear the same varying on the resolution of the device. This means that the super massive 4K displays would be supported also (since they have a higher pixel density). Then for Palm PDAs, the high density displays will accordingly be handled also.


This means I must define the IPC interface in __squirreljme. Then the launcher would use this interface accordingly while it is interpreted itself. The launcher would have its own display, but it would be given the power to launch other processes. That could be handled by the IPC interface too, so in the event that the launcher is running on a rerecord with a differently ordered set of JARs with more or less, provided all the JARs are there with the given keys they would still be found.


The getResourceAsStream could also be done via the IPC interface too for simplicity.


Setting up of the launcher can be performed by the actual launcher code. Then the user interface can become a simple display server with the potential for widgets as described before.


Thinking about it, only the launcher would be run as a given process. What I need however is a callback which can be assigned to a kernel before it starts which initializes the display server socket that the launcher and normal programs would use for example. For simplicity the display will just have a single set of widgets to it which may be added for example. Although I should most likely have more complex scenarios. However, displays should only be locked to themselves and not others. Displays could be running as the server or there could be a client interface which is used.


One problem though is the difference in client and server IPC interfaces. I would have to duplicate both of them. However what I can do is have IPC have the ability to be used with a kind of alternative socket backend. If one is specified, instead of calling the statics which would equate to system calls, the others are used instead. This would then allow me to share the IPC client and server in __squirreljme yet have a variant which can handle being in the kernel. Then I can have a UIServer and a UIClient which use the sockets accordingly. Then UI elements would be bridged by a client and utilized by a server to display what the client desires in most cases. This would allow for just a single set of classes to be used. A server specific drawing interface could just read from a UIServer it hosts to display widgets.


What I need though is a good way to specify services which should be started by the kernel before code runs and such. The code may need to for example start the filesystem server or the UI server for example. Also the BootInterpreter class could also potentially be commonized into the launcher code. The launcher will need those details to launch applications anyway in the kernel. If the system specific stuff just concentrates on starting the launcher then I can have a single common handler for stuff such as the command line. So the launcher would be initialized in the executive environment. The launcher which is being interpreted or natively executed can then listen on an IPC socket which provides a launching service to run other programs and such. So the launcher would be given then command line arguments for parsing. It then looks at the classpath provides which were associated with the kernel. The class unit providers would have to be added as an argument that could be used. Another alternative is for the kernel to listen to a socket and then the first connection would be the launcher, once that is connected it would accept no other connections. This would then be the direct interface that the launcher uses to have the kernel start programs, UIs, and such. So it would act as an early boot interface of sorts. Then with it done this way, the launcher can remain a user-space process which does not have elevated powers. This would be far better in terms of security and stability. This would also mean that the kernel would be mostly just a pass through interface with thread and process management. This IPC bridge would then allow the launcher to easily be interpreted and would not require magical kernel interfaces to be implemented.


This then means that the launcher does not even need to depend on the kernel at all. It also does not need the class-path project either because the units which are made available are provided by the kernel.


Then this also means that command line handling is also associated with the kernel and that handles command line switches. This also means that for specific systems where there might not be a command line normally, it can now be specified in a general means. Then with this, the BootInterpreter class is not needed at all, Main will just initialize the kernel and then run the cycles on it.


Jupiter again shines in my window. This planet appears much.


If I sit up from laying, there is another light visible just above the horizon. That dot is Mars, then just above that to the left is Saturn but it is too faint to be seen.