> On 21 Apr 2016, at 01:12, Johnny Billquist <b...@softjar.se> wrote: > > > Where would you get the metadata from? And you have a lots of different types > of binary files, multiplied with a lot of different systems. You want to try > and figure out some system to handle all the variants? >
The guest OS tool creates and interprets the metadata. The only thing that is consistent across all of the guest OSes is that it tells the SIMH file server how many octets are going to be written to disk (the guest OS tool has to convert the actual word size into octets so that the data file is just a stream of bytes) >> The structure of the metadata file would depend on the host OS but SIMH >> doesn’t have to care - it just sticks the stuff in the file and it’s up to >> the guest OSes transfer tool to create/interpret it. > > It's up to whoever puts the file into that container/raw device/whatever to > make sure that the bytes also match up with the metadata, and the tool used > to extract the file, so that the final binary output becomes what was > expected. > Yes, exactly - the guest OS tools do this. The SIMH file server just writes the stuff to disk. Then if you really want to go all out, you can write some tools for the host OS to view the metadata in conjunction with the actual data. >> You could also write tools for the host OS to create/view these metadata >> files.. >> >> But it’s non-trivial and probably not worth the effort. > > Everything is always doable. The amount of work required, to just do > something that there already are tools for, seems excessive. Or if there > aren't any tools today, it's most likely because people did not find it worth > the effort. Meaning it probably still isn't worth the effort. I’m not saying it’s trivial or even worth doing, but it’s a fun intellectual exercise. Sampsa
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
