One thing to consider is locating the entry method and using that as the ELF's entry point. The ELF should be very easy to generate so to speak.


One issue with the ELF linker is that I need to know the size of the blobs being written to write the ELF header information. I really just need a single load address and such. I can malloc and setup my own stack.


The thing is that the string table is not known until after the end. Also having scanning code to check every method to see if it is the entry point would be very slow. So I suppose for the ELF that it would just load all of the binary data before placing it into memory.


Specials methods can be rewritten using special interfaces and such, but the rewrites could be ignored and such.


One thing I need to consider is that binaries which are output are going to need attributes such as the executable bit or otherwise. Another thing that would be needed is that basic assets would need to be potentially line translated (so that the repository default \n becomes \r\n for Windows and DOS). So the ZIP stream writer will need to handle these cases so that the ZIPs are correctly used on the given systems. This also means for systems such as Mac OS X, that I will need to create my own __MACOSX files.


The ZIP writer code should also be able to handle dates and such. Then also the ZIP reader should also handle such things too. Then this way things are better so to speak. The extra attributes could be used in the emulator since files will rely on being executable for example.


Looks like ZIP does not have any access mode information nor symbolic link. These appear as extensions in Info-ZIPs extra block, so I should use those also and support such things. Looks like I will want to use "ASi Unix Extra Field" which has everything I need.


I would probably rather have actual output right now, so I can just make a ticket for it and such. In fact, anything I need to TODO in general can just get a ticket. Fossil has tickets, may as well use them.