So I suppose for archives, I need a kind of data accessor of sorts. Actually, if all archives are shared and cached and with my current layout of them containing classes, resources and other such things might be cachable. I am going to add a bridge of sorts so that in the future I could potentially cache any kind of resource for example.
This would then mean that the Executable family of classes would be deprecated
and not used at all. So then this means that the archive finder takes the
sole responsibility of representing native classes and such.
just then need a native code returning method.
FSArchiveFinder would be better named as JAR instead. or FSJAR.
Likely it can remain the same. For other forms of binaries such as Palm databases then alternative means could be used for example.
Actually I need to branch the UI code off along with the standard interface code. The kernel does not truly need the UI to be a part of it, but only as a kind of add-on. If on graphical systems the console UI is not used, it would be a bit of a waste.
I can also make the kernel more modular and have the video console stuff just be a module that is available to the kernel. Filesystems and other such things could then just be attached to the module system. An implementation of the kernel would then implement module interfaces as desired. There could also be the possibility of non-standard modules also. Modules could also act as a base for the device IO and other drivers and such. Certain modules such as the console or filesystem would have a standard interface so that interfaces are not neededlessly duplicated and such.
Then the archive and executable format could somewhat be removed from the
kernel and be made a module instead. The kernel would also need to have an IPC
system with buffers so that processes may communicate with one another. Then
with the base IPC and module system, the kernel would be kept simpler. The
event system could also just be IPC from a driver to a specific process rather
than a direct event buffer and such. Then the archive stuff and other things
being out of the kernel would result in much simplification. I suppose for
programs which can be executed there would be a
KernelProcess setup which executes a given program.
The datagram communication system I suppose should be similar to something as if UNIX sockets and UDP were combined into one. Stuff such as network communications and filesystem read/write could be stored within the socket buffers for communication between processes. However, if I were to only permit two processes at a time to communicate with each other, that would simplicate the IPC process.
I do have to consider that streams and pipes would add overhead and such.
However, I can have a datagram packet which are a bunch of datagrams which
are cached to the kernel and re-used when a process needs it. So instead of
freshly allocating new
byte arrays, I just have a cached set of free
datagrams. If no free datagrams are large enough to fit the message then a new
one is allocated. When a datagram is finished,
close is called and the
datagram is placed into a queue so that it may be freed by the garbage
collector in low memory situations. For all datagrams they would have a source
and target process, so when a datagram is sent across processes (or even to
self) it knows the source of the message. One thing that I will need also are
ports similar to TCP/UDP so that datagrams have a specific attachment to some
kind of communication. I can also have multicast and unicast datagrams which
can be sent to multiple processes. When all processes have read the data and
closed the datagram then that data gram is placed into the free queue as
usual. I have to hide the byte arrays for security purposes however, because
otherwise it could be exploited by changing the data. Once a datagram is sent
it is no longer modifiable by a process. I can also have a connect interface
which attaches to another process to send and receive datagrams from. Then
listening sockets could listen for a specific process or from many processes.
So in essence, the kernel/VM would be a microkernel.
There will need to be services which act like host names to bind to, and then there would be a port number that can also be bound also potentially. There would have to be multiple bindings to a process and a general service search I suppose. For example there could be multiple input drivers which listen on the input event generator protocol for events such as keyboard input and such. The names could be removed however, where unique IDs are used instead, so a service and port are just 64-bit integers. This would reduce the need of strings and comparisons. I suppose that would be the simplest approach as it would save space and such. There could be standard IDs however for a given protocol. Also with the IPC interface, I can easily check all user input to make sure it is valid before being used.
My IPC would be asynchronous and I could allow for callback threads to be
created when a datagram is received for example. That would be a use for
drop priveledges of a thread to a given process. I could also have a gain
kernel power using a special object key for example, or basically try with
resources dropping and such. I would have to catch all exceptions and just use
a generic throwable because otherwise a thread could setup an async handler,
throw an exception with a crafted
toString(), which would then be executed
when the thread is running under the kernel. I suppose I would catch the
exception and either drop it, or close the datagram stream from the sending
end. I could have datagram sending have the ability to block to make sure the
other party read closed it. After a datagram is sent, it could just have a
send which returns immedietly and then a
sendAndWait which uses the Object
monitor methods as a callback to know when the other side has read and
handled the datagram.
Since I cannot disable suppression in
Throwable, this gives me a problem
since that method is
final, although cause and such are not. Due to this,
I need to guard all inter-process throwables so that they do not enter into
the kernel. However on the other side of the call, the throwable can be taken
out and then thrown in user-space. However, exceptions thrown in kernel code
can be sent to user-space, just not the other way around.
It would be slightly less complicated if I instead just used service numbers, where positive values are known services, negative values are process send but not receive, and zero values are mapped to the net available negative value. This would remove the complications caused by port numbers.
This means that datagrams for simplicity I need a reply mechanism which either uses the same datagram or finds a new one. For example, before a datagram is closed it can be request that a reply or more than one reply is made, potentially even a future reply if it cannot be replied to at this time. Future replies would be advanced but would complicate things.
Time to move the UI and stuff over to new places then.
Also the UI stuff being moved over means that say for example I want primitive support for OS widgets and menus, I can extend the base UI. I want the standard UI interface to support as many MIDP 3.0 widgets and such as possible. Although the console interface would be a bit ugly looking like this, regardless of whether the system supports raster graphics or not, I can instead support MIDP programs and applications with forms on any device. This is a far better solution personally for me.
Then this means for the swing interface, instead of using a console I can just create a number of Swing widgets for this. If say a console window is created for Swing I can do the same thing as I am doing already and providing a Swing based version of it. If I am running on an native system such as Windows where they provide the ability to create a console window, I will use that. Otherwise the console view would be emulated.
ac48d034864be4f46d143a4e25b0ef654fc9e148 has the event stuff if I
need it during deletion.
I suppose I should just implement the LCD UI MIDP stuff and then use that for the standard UI. Well actually that will not work at all. The LCD UI would have to use my classes, but I can have a common and very similar interface to make porting easier. The LCD UI code will just access the standard UI classes and such for work to be performed. What I need though is to implement a kind of inter-process objects where other processes can use objects of another process (the JVM is a single process anyway so it really does not make it difficult).
Actually, inter-process objects might be a bit complicated. They will have to be inter-process primitive arrays. For example, if there were an interpreter running on a Java ME (or J2ME) device, where Java ME lacks reflection, accessing IPOs would be complicated because the IPO could be some very interface dependent class. The interpreter would need to implement a bridge to access the IPO which would make it very nasty.
I would suppose for IPO I would have to limit it to the primitive array types, String, KIO classes, Kernel, and KernelProcess.
Sticking to the microkernel design with IPC, I essentially solved the issue I was going to have related to interpretation and such. I would have wanted the interpreter to call into the native kernel code normally, but that would be a really complicated issue (especially without reflection).
And with this new route, I only need to have a single launcher interface.
Thinking about it, with the boot finished flagging I can instead have the launcher initialization in common code rather than the implementation specific code.
Might be best if the IPC display manager were in seprated client and server forms since both of them might not be needed at the same time.
Actually, with the IPC for displaying, it is kind of like X11 in a way except limited to just a single process (since the JVM runs as one). Although there is a slight loss of speed it would be rather portable because I can easily hide the user interfaces and could actually make it entirely optional in certain situations.
So today I mostly refactored code, I had the UI for JARs listed and such but that was really ugly. Now I hope with this standard single interface for the launcher that it can handle the various differences in systems because it would rely on generic UI interfaces. Also when it comes to the UI and native interfaces, widgets may have to be freed when they are garbage collected. Thus, native user interface implementations must keep a reference queue handy if this needs to be performed in the code at all. Otherwise, if it is not done and the native UI does not perform garbage collection then there might not be enough resources to display anything (such as in Windows 98) or the system might just run out of memory trying to display so many widgets.