Perhaps for the emulator I would have something simple. I just load the ELF somewhere in a given memory location and then just start interpreting it for the most part. I would need a common memory layout however and such, along with rules for alignment and other things.


Perhaps my emulator as it currently stands is a bit too complex. What I really need is just a way to emulate some binaries in a very simple fashion to just run the tests and the practice binaries and such.


My build system needs to find a way to determine if files were deleted within a source tree rather than just being modified. What I could do is have a file count so to speak.


So my emulator will just be very simple. It will load a binary and then start executing it so that tests can run for example. It would just be so I can get a basic layout of how a target system works and then I can also support whatever is needed by SquirrelJME. The emulator should be accurate enough to run programs but its not intended to be 100% accurate.


I could likely use a jit-base-mips which contains an enumeration of the variants that are available or similar. Although, it is not specifically required however. It could simplify some things in a few cases however.


For some reason, inequal strings are equal.


I will need some file system handlers, one that is generic and uses the native path system in a way. For the emulator, I can have a completely in memory virtual filesystem. When it comes to filesystems, I just need a backend which provides native access for example. Hypothetically this temporary in memory format could be used on real VMs. Another consideration is that the emulated filesystems could also be used too, although that could be a bit tricky.


I wonder if foo/../bar is the same as bar. And that is not the case.


I would say for simplicity when it comes to permissions and such that ACLs are used.


Databases in Palm OS could be handled and treated by SquirrelJME as resource forks using special names and such.